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