5kft

He could compare the contents of "/sys/class/thermal/thermal_zone0/" on the two kernels, as well as the output of "cpufreq-info" across both.

@linuxjosef - could you run "screen", and run "sudo armbianmonitor -m" in one session, and "top" in another? It'd be interesting to see what is going on in terms of processes, and gauge the load and see if throttling is indeed working on your board.

Great, thank you! I've tested across my corpus of boards, they are all H2+/H3/H5 (Orange Pi, Nano Pi, etc.) They all worked great

Great! Could you try it off of the master branch? I fixed the thermal and cooling maps and a number of other patch errors related to the H6. (Note that the "current" branch is now 5.8 and "dev" is now 5.9.)

That was my original thinking, given that 5.7.y is EOL now... I'll go ahead and push my changes - current -> 5.8, dev -> 5.9. It would be great if someone could confirm H6 operation with 5.8 after this - I cleaned up all of this (it was messed up before), but I don't have an H6 board to test the changes with.

Makes sense. I'll keep my branch updated with the v5.9-rc versions, and then when v5.9 is released then the switch will be easy

I checked in a number of changes today into master that make it very straightforward to build sunxi w/kernel v5.9-rc2. I have created a v5.9 development branch for sunxi in my repo that contains the current changes necessary for v5.9: https://github.com/5kft/build/tree/v5.9-sunxi-development. With the base mainline changes in master now only a few changes are needed to support v5.9. With these changes, both sunxi and sunxi64 work in an initial state with v5.9-rc2. There are still some things that need some cleanup (e.g., there's a sound driver issue and a few other existing patches that need to be cleaned up/merged), but overall it seems to be at a very good initial working point now. From cursory testing of this on some NEO variants with several different Realtek-based USB Wi-Fi adapters all seems to work quite well. I originally encountered some serious problems with the AP6212 Wi-Fi adapter (tested on a NEO Air and NEO Plus2) where Wi-Fi communication would randomly hang or stop. I narrowed this down to the brcmfmac changes in this change in the kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47ec5303d73ea344e84f46660fff693c57641386. I haven't debugged exactly what the issue is - I'm guessing it's something to do with the SDIO reset changes that were added, or perhaps there is an incompatibility with these changes and the current AP6212 firmware we're using. However by reverting these specific changes to the brcmfmac driver back to the kernel v5.8.y version, the AP6212 Wi-Fi part works perfectly fine again, so I added a patch to revert the v5.9 changes to this driver. @Igor, @martinayotte - any thoughts as to when we might want to move sunxi-dev to v5.9? It's going to be in -rcX state for another month or so, so I'm not sure it makes sense to move from v5.8.y right away, but then again there's an appeal to being on the latest. Interested to hear your thoughts!

I went ahead and cleaned up the remaining problems for 5.8. I don't have an H6 board so I can't test the changes there, but I believe they should work fine (I did a rework of my previous thermal changes for H6 and re-applied on the new 5.8 base).

I haven't seen anything announced that 5.9 is LTS...where did you see this @Werner ? BTW, I messed around with this a bit (had to patch a few things), and a super quick test build looks promising: root@192.168.1.151's password: _ _ ____ _ _ _ | \ | | _ \(_) / \ (_)_ __ | \| | |_) | | / _ \ | | '__| | |\ | __/| | / ___ \| | | |_| \_|_| |_| /_/ \_\_|_| Welcome to Armbian 20.08.0-trunk Buster with Linux 5.9.0-rc2-sunxi No end-user support: built from trunk System load: 1.05 0.32 0.11 Up time: 0 min Memory usage: 14 % of 492MB IP: 192.168.1.151 CPU temp: 41°C Usage of /: 23% of 7.2G Last login: Fri Aug 21 15:28:22 2020 root@air:~# cat /proc/version Linux version 5.9.0-rc2-sunxi (root@8b25ad840cf6) (arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #trunk SMP Thu Aug 27 22:27:48 UTC 2020 root@air:~# cpufreq-info -c 0 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.30 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:89.62%, 648 MHz:0.97%, 816 MHz:0.08%, 960 MHz:0.08%, 1.01 GHz:0.08%, 1.06 GHz:0.05%, 1.10 GHz:0.02%, 1.15 GHz:0.04%, 1.20 GHz:0.04%, 1.22 GHz:0.02%, 1.25 GHz:0.02%, 1.30 GHz:8.98% (171) root@air:~# root@air:~# cat /sys/class/thermal/thermal_zone0/temp 32928 root@air:~# root@air:~# ls -al /boot/ total 31799 drwxr-xr-x 4 root root 1024 Aug 27 16:04 . drwxr-xr-x 18 root root 4096 Aug 21 15:28 .. -rw-r--r-- 1 root root 277 Aug 27 16:04 armbianEnv.txt -rw-r--r-- 1 root root 1536 Aug 21 17:57 armbian_first_run.txt.template -rw-r--r-- 1 root root 230454 Aug 21 17:57 boot.bmp -rw-r--r-- 1 root root 3895 Aug 21 17:57 boot.cmd -rw-r--r-- 1 root root 3967 Aug 21 17:57 boot.scr -rw-r--r-- 1 root root 188640 Aug 27 15:27 config-5.9.0-rc2-sunxi lrwxrwxrwx 1 root root 19 Aug 27 16:03 dtb -> dtb-5.9.0-rc2-sunxi drwxr-xr-x 3 root root 10240 Aug 27 16:02 dtb-5.9.0-rc2-sunxi -rw-r--r-- 1 root root 10116125 Aug 27 16:03 initrd.img-5.9.0-rc2-sunxi -rw-r--r-- 1 root root 0 Aug 27 16:03 .next drwxr-xr-x 2 root root 1024 Aug 24 09:16 overlay-user -rw-r--r-- 1 root root 4072041 Aug 27 15:27 System.map-5.9.0-rc2-sunxi lrwxrwxrwx 1 root root 23 Aug 27 16:03 uInitrd -> uInitrd-5.9.0-rc2-sunxi -rw-r--r-- 1 root root 10116189 Aug 27 16:03 uInitrd-5.9.0-rc2-sunxi -rwxr-xr-x 1 root root 7806728 Aug 27 15:27 vmlinuz-5.9.0-rc2-sunxi lrwxrwxrwx 1 root root 23 Aug 27 16:03 zImage -> vmlinuz-5.9.0-rc2-sunxi root@air:~#

So 5.7 has gone EOL...should we consider switching -current to 5.8 and -dev to 5.9-rc? How much work is left to be done for 5.8? I've been running 5.8 for a few weeks now on all of my boards and it works great. However I don't have an H6, and I think there are still some patch issues with the H6...?

Wireless drivers that have a dependency on cfg80211 require that cfg80211 and all of its dependencies be built into the kernel as well. I.e., you can't build this wireless driver into the kernel ("=y") if cfg80211 is built as a module ("=m").

Very nice work! Since I've been messing with the overclock overlays of late, I just dropped them in and everything works great (initial testing on a NEO2), including thermal management. dmesg seems clean as well! Seems super solid with cursory testing so far

I'm not deeply familiar with those boards, but in doing some really quick checks it looks like indeed the hardware doesn't provide any means to get more voltage to the CPU, which means they wouldn't work... Yes, I've found in testing that it appears that the H2+/H3 can be pushed harder than the H5... I tested 1.3GHz on a couple H5s and couldn't get them stable above 1.2GHz (some other ones are fine, however). My OPi Zero has no issue, however...it's interesting. Also, note that with the way I created these overlays the passive cooling maps work properly, which means that the boards will clock down at the appropriate temperature thresholds, improving stability. You'll note that while your board clocked to 1368MHz early on, it spent the bulk of its time at 1200MHz due to thermals. This is good - it provides stability and will allow the board to clock to the maximum when it can.

Done! https://github.com/armbian/build/commit/91156f11922c00227211d1d765512f09b6398d1a verbosity=1 bootlogo=false console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 cpu-clock-1.368GHz-1.3v rootdev=UUID=84d54d78-1a45-4366-9776-2fa013e0e1e6 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.37 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.37 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:89.25%, 648 MHz:0.49%, 816 MHz:1.19%, 960 MHz:0.01%, 1.01 GHz:3.74%, 1.06 GHz:0.01%, 1.10 GHz:0.86%, 1.15 GHz:0.01%, 1.20 GHz:0.82%, 1.22 GHz:0.01%, 1.25 GHz:0.73%, 1.30 GHz:0.01%, 1.37 GHz:2.89% (287)

Could you try running "openssl speed -multi 4" to completion at 1.3GHz (it takes quite a while), and let me know what happens? If it survives, I'll look at adding 1.368GHz Also, cpuburn-a7 is a useful stability test as well - clone https://github.com/ssvb/cpuburn-arm, and just compile it and run it. Be sure to watch your CPU temps when using these. I just did a full build for the Orange Pi Zero, and the overlay prefix is "sun8i-h3": root@orangepizero:~# cat /boot/armbianEnv.txt verbosity=1 bootlogo=false console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 rootdev=UUID=83d54d78-1845-4266-9776-2fa013e0e1f6 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@orangepizero:~#

In case 1.3GHz isn't stable for you, I've added a 1.2GHz/1.3v overlay ("sun8i-h3-cpu-clock-1.2GHz-1.3v.dtbo") to sunxi-current (https://github.com/armbian/build/commit/e5cca8692fbe89f356e6acc5701ef8ac6c699f7e). I tested it on an H3 board: analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.20 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.10 GHz, 1.20 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.20 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:97.58%, 648 MHz:0.31%, 816 MHz:0.01%, 960 MHz:0.02%, 1.01 GHz:0.01%, 1.10 GHz:0.02%, 1.20 GHz:2.06% (149)

@Adrian Cable - I made the changes for sunxi-current and pushed to the repo: https://github.com/armbian/build/commit/b2adb2935b4dcee57c982a1447de8cf75760dd2a. This change adds a new boot overlay for the sun8i-h3 that enables a maximum of 1.3GHz at a CPU core voltage of 1.3v. If you use this overlay, I strongly recommend you try driving the board hard to ensure stability (e.g., "stress --cpu 4", etc.) Historically on most of my boards the maximum I could push to was 1.2GHz at 1.3v, which is why I added a 1.2GHz overlay for the H5 (and I could only get to 1.368GHz w/a 1.4v core voltage). I can do the same for the H3, but am short on time atm. I'll also add this overlay to sunxi-legacy as well, but I won't be able to get to this later. I tested this on one of my H3 boards w/a max CPU voltage of 1.3v: /boot/armbianEnv.txt (note the addition of "cpu-clock-1.3GHz-1.3v" to the "overlays=" line): verbosity=7 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost0 usbhost1 usbhost2 uart1 cpu-clock-1.3GHz-1.3v rootdev=UUID=3ad712a7-75cb-4ac1-8cfa-dbb67df8f239 rootfstype=f2fs extraargs=net.ifnames=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u After booting with this overlay, from "cpufreq-info", w/everything else at the defaults, maximum clock rate is now 1.30GHz: analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.30 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:96.94%, 648 MHz:0.35%, 816 MHz:0.04%, 960 MHz:0.03%, 1.01 GHz:0.03%, 1.06 GHz:0.02%, 1.10 GHz:0.02%, 1.15 GHz:0.03%, 1.20 GHz:0.02%, 1.22 GHz:0.01%, 1.25 GHz:0.01%, 1.30 GHz:2.50% (253) Please give this a try and let me know how it goes If 1.3GHz is unstable, I'll try to expedite adding the 1.2GHz overlay as well.

Because the opp table in the DTs are common and used for all H3/H5 boards, not just your specific OPi Zero. The CPU regulator voltage defines the maximum clock rate available, specific to each board. Actually this behavior is completely correct - it's how the CPU clock system is defined. You do not want to make a general PR to increase the default clocks for lower voltages here because this will introduce instabilities across all other AW-based boards (!). There is a very easy way to enable this, however - you can use an overclock overlay. I created a few of these a couple of years ago; see this thread for more information: Now I just noticed that this patch apparently didn't make it over to the new sunxi-current branch (5.7); I'll fix this. I also used the H5 prefix for this - I haven't tried it on an H3, but given the common opp table it should work. I'll take a look at cleaning this up now for sunxi-current and will post back.

@Igor, @lanefu - In testing sunxi-current on the NanoPi R1, I found a problem with the maximum CPU clock frequency not being properly limited; the R1 by default was getting overclocked, which led to instability. The problem occurred because the VDD CPU regulator fix I made previously (now in sunxi-legacy) didn't make it to sunxi-current. I've made the fix in sunxi-current and have pushed it to build and have confirmed that this corrects the issue (see https://github.com/armbian/build/commit/fbaf7562c05c841036b45ec1c22575684759834).

Hi @dolphs, I've checked in an updated patch for this here (in a test branch): https://github.com/5kft/build/commit/86ad3c26c9f4835cd97e223223c72f0464173848 I can't build 5.8 (obviously) nor actually test this (I don't have an H6-based board), but I've confirmed that this patches the current megous orange-pi-5.8 head cleanly...

Hi @dolphs, thanks for all of your work on this area! Question: would you have your work available somewhere - I could try taking a quick look to see what the situation might be...

To bring this thread up to date - somewhere along the line the DTs dropped the correct trip list and cooling maps...I checked in fixes for this for the H3, H5, and H6 about a month ago (see https://armbian.atlassian.net/browse/AR-244 and https://armbian.atlassian.net/browse/AR-285). All seems to work well now

It looks correct - see https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/adjust-default-dram-clockspeeds.patch. u-boot was switched to v2020.04 back in April, which would account for the size difference.

Done and done https://armbian.atlassian.net/browse/AR-285 Thanks for doing the testing!

@Werner - thanks! Great news - it looks like it is working! For comparison, would it be possible for you to test this without these changes and see how it goes? That could help inform as to whether these changes should be checked in as-is.