Adrian Cable

You are (very genuinely) welcome!

@Igor - I have just put a few thousands on your account. Can I therefore kindly a request a withdrawal of the "you don't care" part of the above? Thank you.

Any more details so this is actionable by the community? Version/commit numbers of u-boot for working vs. non-working would be a great start on the way to a git bisect.

This sounds very interesting. Care to share some more? Thank you!

We have a commercial product running on Armbian based on the OPi Zero platform. We occasionally get reports from customers of intermittent connectivity, which (looking at the dmesg log on affected devices) manifests itself as something that looks very much like the up/down syndrome reported here. In this case we advise customers to purchase a cheap switch (e.g. https://www.amazon.com/NETGEAR-5-Port-Gigabit-Ethernet-Unmanaged/dp/B07S98YLHM/ref=sr_1_3?dchild=1&keywords=4+port+switch&qid=1614793487&sr=8-3) and put it between our product and their existing switch or router. We have found this always resolves the issue. We still don't understand the cause, but at least we have a workaround (albeit not a perfect one).

Igor, sure, happy to suggest PR/changes. Can you tell me what user behaviour you are trying to guard against? I wasn't aware of any user-alterable parameters in htop that could cause it to crash. Thanks!

From Armbian 20.08 onwards, I observed that htop loses its settings (e.g. show userland threads, process sort order) every boot. This is equally odd and frustrating, and until recently I had no idea what was happening to make this so. Then I discovered the cause - this script: /etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx And indeed, on every reboot, it overwrites htoprc with some default settings. And I have tried but not succeeded to understand the intention was behind a decision to not allow users on SBCs to persistently change .htoprc any more. Can anyone add any context? Struggling to see how this makes sense, so any insight is valuable. Thanks!

Issue still persists unfortunately with Armbian 20.11, which does have an updated U-Boot (v2020.10). Still scratching my head on this, and welcome any thoughts anyone may have. Thank you!

Hardware: Orange Pi Zero 512MB LTS (several different devices), bench power supply, good SD card - everything working good at all clock speeds from 480MHz upwards (all the way up to 1.4GHz even, with a heatsink). ffmpeg encode, stress-ng etc. are all fine. Specifically, the board is rock solid at 960MHz. What I want to achieve: take the U-boot for OPi Zero, and rebuild with an adjusted config to achieve a faster boot time, by replacing CONFIG_SYS_CLK_FREQ=480000000 with CONFIG_SYS_CLK_FREQ=960000000. (Does anyone know why the standard Armbian build is set to boot at such a low clock speed?) Starting point: I can successfully build U-boot from the Armbian sources (using Armbian's orangepi_zero_defconfig), write to SSD using nand-sata-install, and boot. It works fine. So there is nothing wrong with my build process, or my ability to reproduce the base configuration. What goes wrong: when I adjust CONFIG_SYS_CLK_FREQ=960000000, the board fails to boot. It freezes a few seconds into booting the kernel, with the UART output normally just stopping around here: [ OK ] Started Armbian memory supported logging. Starting Journal Service... [ OK ] Started Raise network interfaces. Occasionally I will get some kind of error: [ 6.871890] BUG: Bad page state in process sed pfn:546e2 So it appears that, in addition to adjusting the CPU frequency, I need to adjust something else to make it all work. Does anyone know what needs to be done? Thanks!

5kft - just to confirm - I rolled back my hack and added your new DTBO compiled from your patch commit. All works great, on H2+. You might also want to add a note in README.sun8i-h3-overlays. -Adrian

Looks great to me!! Thank you! -Adrian

5kft - my bad about the overlay prefix. Checked on my build and you're right. I think I got confused previously because the DTB files for OPi Zero do indeed start with sun8i-h2-plus not sun8i-h3. So here are the results from openssl speed -multi 4: 1. The CPU gets very hot indeed! See attached pic. 2. It doesn't crash. 3. It completes just fine, ending ... Got: +F5:18:384:34.665335:0.028847 from 3 Got: +F5:19:384:35.294118:0.028333 from 3 Got: +F5:20:512:26.047904:0.038391 from 3 Got: +F5:21:512:27.372627:0.036533 from 3 Got: +F5:22:253:486.600000:0.002055 from 3 Got: +F5:23:448:105.500000:0.009479 from 3 Got: +F6:0:253:Ed25519:1240.400000:431.900000 from 3 Got: +F6:1:456:Ed448:198.400000:99.700000 from 3 OpenSSL 1.1.1d 10 Sep 2019 built on: Mon Apr 20 20:23:01 2020 UTC options:bn(64,32) rc4(char) des(long) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-8NbErV/openssl-1.1.1d=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 So I vote to include 1.368GHz. -Adrian

5kft - your patch looks good except I would also consider adding the settings for 1368MHz. In my testing (basically stress -c 4 -n 600) the CPU temperature (OPi Zero 512 LTS) peaks at about 90 degrees C ... no crashes ... this is the real temperature (measured with FLIR) not the broken thermal readout register. Of course when overclocked by ~ 200MHz there might be significant variation in stability between boards. But I say: let people try themselves and have fun if they want. Also, I believe you need to add to sun8i-h2-plus as well as sun8i-h3, to cover the OPi Zero (which is my platform). -Adrian

5kft - this is great. If you have something you would like me to test on H2+/H3, happy to do so. -Adrian

Werner - that's a great idea! In case you or others want to test as well, here are my corrected lines in the DTS for the OPi Zero: opp-1104000000 { opp-hz = < 0x00 0x41cdb400 >; opp-microvolt = < 0x13d620 0x13d620 0x13d620 >; clock-latency-ns = < 0x3b9b0 >; }; opp-1200000000 { opp-hz = < 0x00 0x47868c00 >; opp-microvolt = < 0x13d620 0x13d620 0x13d620 >; clock-latency-ns = < 0x3b9b0 >; }; opp-1296000000 { opp-hz = < 0x00 0x4d3f6400 >; opp-microvolt = < 0x13d620 0x13d620 0x13d620 >; clock-latency-ns = < 0x3b9b0 >; }; opp-1368000000 { opp-hz = < 0x00 0x518a0600 >; opp-microvolt = < 0x13d620 0x13d620 0x13d620 >; clock-latency-ns = < 0x3b9b0 >; }; Running now at 1.368GHz and hasn't crashed. I'm going to try stress etc. and see what happens. -Adrian

Werner - so I guess the question I really wanted to ask was: why does the DTB for the Orange Pi Zero include CPU frequency settings that request voltages above 1.3V from the regulator, which it doesn't allow? If I edit the DTS to reduce the regulator voltages from the "disallowed" values down to 1.3V, the higher frequencies seem to work. I can't comment on stability. But if they are unstable, why not remove those frequencies from the DTB completely, rather than leave them in with invalid regulator voltages? -Adrian

Hi - I have been using Armbian buster stable on Orange Pi Zero for the past 12 months, starting with 5.92 last August and going up to 20.05.7 today. In all of these versions, clock speeds above 1.008GHz are unavailable, despite the board supporting 1.104GHz, 1.2GHz, 1.296GHz and 1.368GHz. They are not listed in armbian-config, cpufreq-set is unable to set them, and dmesg includes lines like: [ 10.030991] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 10.031017] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 10.031305] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 10.031322] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 10.031589] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 10.031610] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 10.031883] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 10.031902] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000) Then: /sys/devices/system/cpu/cpufreq/policy0# cat scaling_available_frequencies 480000 648000 816000 960000 1008000 My understanding is OPi Zero has only two regulator settings: 1.1V and 1.3V. So, not surprising if the DTB is trying to set the regulator to 1.32V or 1.4V things don't work. But why is this happening? What am I missing? How do I use these frequencies on Armbian buster stable? Thank you so much! -Adrian

Alexis - this looks to be like a "normal" (non-LTS) board. I think your CPU temperature really is around 73 degrees, which sounds normal to me for 100% load on 4 cores. For me, on the LTS board, in the same scenario, I get a reading around 40000 (i.e. 40 degrees C). Unless I've misunderstood, I think an offset is (at least roughly) enough.

What's the correct reporting to channel to get this into the queue to get worked around in Armbian? I understand that the "root cause" is probably on the board side, but we do have a number that increases monotonically with temperature and should be usable once we figure out the slope and offset. Great for everyone's feedback on this issue here, but it isn't clear if this forum gets the issue in front of the right eyes to be addressed in a future version of Armbian. Does anyone know how this process works?

Interesting. Now what would be nice is if we could set an offset of 27 degrees C at runtime. I note that there is: /sys/devices/virtual/thermal/thermal_zone0/offset However something like this seems to have no effect: echo 27000 > /sys/devices/virtual/thermal/thermal_zone0/offset; cat /sys/devices/virtual/thermal/thermal_zone0/temp Any ideas what the correct syntax is and/or if writing to offset has any effect? -Adrian

@yoq - this is extremely interesting - thanks for your work on this. It seems that there is an offset of about 27 degrees C that needs to be applied on the LTS boards. Of course, I guess we don't know the slope is right either, but from my own experiments it seems that the error is simply an offset. The next problem is that I'm not sure how we can detect that the OPi Zero board we're running on is an LTS board, and adjust the offset parameter accordingly. All the boards return a HW string of 'Xunlong Orange Pi Zero' whether they are LTS or not. Do you know how/if it's possible to detect this in software, and then adjust the returned offset? I suppose this would need to be implemented in sun8i_thermal.c. -Adrian

@Craig St George - it is confusing because both the LTS and non-LTS boards have the same screenprinting on the PCB (Orange Pi Zero 1.4 or 1.5). The temperature read-out is correct for the non-LTS boards, but broken on the LTS boards. Looking at /etc/armbianmonitor/datasources/soctemp, it seems to be an offset problem. The LTS boards under-read by somewhere between 30 and 40 degrees C. I'm not sure what the correct channel to report this is, so the Armbian devs can look into it. Not sure if posting in this forum gets this issue in front of the right eyes or not.

@Werner - are you saying that you get correct thermal readouts with armbianmonitor on OPi Zero LTS? I definitely don't! Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 11:21:33: 480MHz 0.05 8% 4% 4% 0% 0% 0% -737°C 0/4 11:21:38: 480MHz 0.05 8% 4% 3% 0% 0% 0% -495°C 0/4 11:21:43: 480MHz 0.04 6% 4% 2% 0% 0% 0% 2.2°C 0/4 11:21:49: 480MHz 0.04 7% 4% 2% 0% 0% 0% 474°C 0/4 11:21:54: 480MHz 0.04 8% 4% 3% 0% 0% 0% -11°C 0/4 11:21:59: 480MHz 0.03 7% 3% 3% 0% 0% 0% 2.4°C 0/4 Everything works fine for me with the non-LTS boards. -Adrian

Hi - I can also confirm that the thermal readout is broken on OPi Zero LTS, for all kernels (4.19.62, 5.3.x, 5.4.x). If anyone has found a fix, please share! -Adrian

Hi, I'm having issues with an unreliable HW watchdog on the Orange Pi Zero. I am using the standard Armbian kernels (tried 4.19.62, 5.3.x, 5.4.x - all the same) and have nowayout=1: [ 4.328286] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=1) I'm feeding /dev/watchdog every 2 seconds. Superficially it works, for example, if I do the following the WD triggers after 16 sec and the board reboots: echo c > /proc/sysrq-trigger However I am finding that in other crash scenarios, the WD reboot sometimes happens and sometimes does not. For example, with a forkbomb :(){ :|:& };: about 70% of the time the WD reboots the board, but 30% of the time the board stays crashed and the WD never reboots it. (I've confirmed that the forkbomb does stop the watchdog feeder, so the WD should trigger a reset.) I have to do a hard power cycle to get it to boot again. Has anyone else had experience with an unreliable watchdog on these boards? Any more insight or fixes? -Adrian