CPU voltage control on 3.4 kernels and som OC

Decker · June 14, 2015

Hi, I was looking for ways how to speed up CPU for faster ethernet transfers and speed it down when idle. I would also like to control voltage.

I know that in mainline kernel you can edit this file

arch/arm/boot/dts/sun7i-a20.dtsi

and configure it yourself.

1)I would like to know where (if) you can control voltage somewhere for 3.4 kernel. I was unable to found any info.

2) in /boot/script.bin i found out parameter "dram_clk", I assume that you can change freq of RAM here. Somewhere I read (I think form tkaiser) that you can add 48MHz steps to CPU/memory. Why exactly 48MHz? That is very interesting for me. Some clock source/timer works in 48 MHz?

3)Two things little bit OT, I am sorry:

what is status of analog sound in mainline kernel? (I expect response like "never" or "do it yourself" , but maybe someone started already.)
Do igor's image use some kind of bananian-config or something like that?

Decker · June 14, 2015

1) second after posting I found out that in /boot/script.bin of 4.0.5 jessie build is this:

[dvfs_table]

max_freq = 912000000

min_freq = 720000000

LV_count = 7

LV1_freq = 1008000000

LV1_volt = 1450

LV2_freq = 912000000

LV2_volt = 1425

LV3_freq = 864000000

LV3_volt = 1350

LV4_freq = 720000000

LV4_volt = 1250

LV5_freq = 528000000

LV5_volt = 1150

LV6_freq = 312000000

LV6_volt = 1100

LV7_freq = 144000000

LV7_volt = 1050

As I said I am running 4.0.5. I do not have these speeds avaiable in 4.0.5.

Do I understand correctly that with this I can manualy set voltage in 3.4 kernels?

tkaiser · June 15, 2015

Do I understand correctly that with this I can manualy set voltage in 3.4 kernels?

For older kernels/u-boot you set the available cpu frequency/voltage settings in script.bin, prior to 4.0 there was no way to set it in mainline and starting with 4.0 you can modify arch/arm/boot/dts/sun7i-a20.dtsi to add additional operating points (if you understand what you're doing).

The 48 MHz cpufreq steps are a software thing to deal with the values you provide via sysfs (eg. settings /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq), This applies to 3.4 and maybe to mainline as well (just give it a try, use ondemand, modify scaling_max_freq, create some load and check scaling_cur_freq)

Do NOT adjust DRAM clocks unless you really understand what you're doing and don't even think about overclocking unless you really understand what performance implications cpufreq settings have for your specifig use case. In case you want to do number crunching then an ARM SBC is simply the wrong choice. So if you're after performance you chose the wrong hardware platform. For other use cases related cpufreq settings might do the difference and there's no need to overclock anything if these settings are adjusted appropriately (see for example NAS/fileserver stuff: http://forum.lemaker.org/forum.php?mod=viewthread&tid=15543)

BTW: Increasing voltages leads to a reduced lifespan of your device. Unfortunately I don't find the link any more but I read a developer discussion where they talked about slightly increasing the core voltages might lead to the SoC dying twice as fast.

Decker · June 15, 2015

Thank you for your answer.

Since I bought Banana to learn some Linux and hardware shit, "do not do it" (as your post suggests) would be a wrong way. I have it mainly to explore things that I did not meet in x86 platform. So please do not make this topic only "do not do it" but "how to do it, with "do not do it" at the end". Most of us are here to learn.

Please, elaborate on that 48MHz freq. I know where you put freq. of course, but these steps are somehow specific to arm. I would like to know WHY you do 48MHz steps. Why not 64? 32? 36? I think there will be some hardware thing, timer or something working in 48MHz so you can do only 48MHz steps or CPU can become unstable. In Bananian with kernel 3,4 (that means "NOT from Igor") I could change freq as I wanted and I did not respected 48MHz steps and it worked. But I am not sure if things were not slower...

I do not want to know how to manage voltage only for raising it, I want to lower it too. I know danger of both.

As kid has to fall on face to learn that using the front brake on a bicycle is not smart in high speed, burned banana pi is the best way to learn what you can, should or should not touch.

With RAM - thanks for the link, already read it. But it is good for others. I did not write that I am going to OC memory, again, I am here to learn and if I will change it, I will test it. And who told that I am not going to default after that? I want to learn how RAM speed on ARM effects on overall performance. Of course, I am not speaking only about freq.

Does anyone have answers for 2) and 3)?

Igor · June 15, 2015

In Bananian with kernel 3,4 (that means "NOT from Igor") I could change freq as I wanted and I did not respected 48MHz steps and it worked. But I am not sure if things were not slower...

My version of kernel 3.4 is not that much different (at least in this part) from the one in Bananian so I think this feature works equal. I am not 100% sure since I don't pay much attention - I pay attention to the main community Linux:

https://github.com/linux-sunxi/linux-sunxi

2 & 3

Status of mainline:

http://linux-sunxi.org/Linux_mainlining_effort

I don't use any extra configuration script except NAND / SATA / USB installer. The rest is either Debian/Ubuntu stock (keyboard, timezone, ...) or automatic (partition resize, SWAP) or done via .deb install (kernel switching, upgrade). I tend to have images as clean as possible.

tkaiser · June 15, 2015

In Bananian with kernel 3,4 (that means "NOT from Igor") I could change freq as I wanted and I did not respected 48MHz steps and it worked.

Please check youself. If you write 1100000 in scaling_max_freq and put some load on the board you will end up with 1056000 scaling_cur_freq (1056 MHz). Because the code only accepts increments of 48000 (for reasons unknown to me). Maybe the same applies to mainline kernel. But there the cpufreq code jumps between the different operating points defined in the .dtsi file.

Regarding "don't do this at home". I tend to write some warnings/disclaimers to this stuff since in my normal job I've to deal with large scale data corruption from time to time. And since other people that might come across this thread then think 'overclocking' is safe and risk their data I just want to point this out again and again.

One of the main 'problems' compared to x86 is that the SoCs we're talking about are so cheap that they won't be subject to an extensive QA or selection process prior to being sold. Settings that might work on your board will lead to silent data corruption on another board (applies to both undervoltage and overclocking scenarios). And since people also try to play RAID with crappy SATA port multipliers connected to their A20 based SBCs and store valuable data on it (and also confuse RAID with backup) some warnings are necessary

Regarding voltages and DRAM clock: In the first days of Cubietruck developers decided to set some entries in the dvfs_table based on experiences with their boards. In the meantime it became clear that for the majority of boards these settings led to undervoltage situations. Same regarding DRAM clock. LeMaker started with 480 MHz for the Banana Pi. And while that worked for their first batch of SBCs without errors later/different batches of boards differed so they decided to lower the DRAM clock speed to 432 MHz which should be considered a sane default.

Igor · June 15, 2015

Maybe the same applies to mainline kernel.

Mainline, currently (4.0.5) we have:

 available frequency steps: 144 MHz, 312 MHz, 528 MHz, 720 MHz, 864 MHz, 912 MHz, 960 MHz

tkaiser · June 15, 2015

Mainline, currently (4.0.5) we have:

 available frequency steps: 144 MHz, 312 MHz, 528 MHz, 720 MHz, 864 MHz, 912 MHz, 960 MHz

Yes, but I meant the increment in 48MHz steps. So I just tried it out myself (with kernel 4.0.4 and ready to overclock up to 1.2 GHz):

root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
144000 312000 528000 720000 864000 912000 960000 1008000 1056000 1104000 1152000 1200000 

root@bananapi:/# echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

root@bananapi:/# echo 1000000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
960000

root@bananapi:/# echo 1008000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
1008000

root@bananapi:/# echo 1009000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
1008000

root@bananapi:/# echo 1056000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
1056000

Same behaviour as with kernel 3.4. So the operating points available in kernel 4.0 or above are the equivalent to the former dvfs_table entries. They define a relationship between core voltage and clock speed but the actual cpufreq settings are still only possible in steps of 48 MHz. But what's different: Starting with kernel 4.0 thermal throttling is implemented on sun7i (A10/A20). If the temperature that will be read out from the thermal sensor inside the A20's touchpad controller exceeds defined values then the cpufreq driver will start to throttle. The temperature can be read out using the following code starting with 4.0:

awk '{printf ("%0.1f",$1/1000); }' </sys/devices/virtual/thermal/thermal_zone0/temp

Decker · June 15, 2015

Well, you are fast guys. Thank you very much for enlightening me!

Status of mainline:

http://linux-sunxi.o...inlining_effort

Very interesting, thank you.

I don't use any extra configuration script except NAND / SATA / USB installer. The rest is either Debian/Ubuntu stock (keyboard, timezone, ...) or automatic (partition resize, SWAP) or done via .deb install (kernel switching, upgrade). I tend to have images as clean as possible.

Yep, I thought that. Again, thank you for info.

Regarding "don't do this at home". I tend to write some warnings/disclaimers to this stuff since in my normal job I've to deal with large scale data corruption from time to time. And since other people that might come across this thread then think 'overclocking' is safe and risk their data I just want to point this out again and again.

Yes, you are right. It should be pointed out often, but I think that it won't help, since people will save family photos on F2FS on RAID 0 via crappy SATA multiplier and because network transfers will be slow they will overclock with the vision of better speeds. And because "in worst case it will just freeze", they dont care about warnings. And later something will go wrong and they will lose all family photos (joking, but lets say "some backups"), because it will not be possible to recover them. It is fight with wind mills. I think that everyone has to learn the hard way.

If the temperature that will be read out from the thermal sensor inside the A20's touchpad controller exceeds defined values then the cpufreq driver will start to throttle.

I would not even expect this, very interesting!

Please check youself. If you write 1100000 in scaling_max_freq and put some load on the board you will end up with 1056000 scaling_cur_freq (1056 MHz). Because the code only accepts increments of 48000 (for reasons unknown to me). Maybe the same applies to mainline kernel.

I will re-check myself later. It is possible that I made mistake last night, maybe I did not check if frequencies were changed, I do not remember, I was very tired. :-/

Thank you again for your time. All questions answered and I am smarter again.