Adrian Cable

  • Content Count

  • Joined

  • Last visited

About Adrian Cable

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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
  4. 5kft - this is great. If you have something you would like me to test on H2+/H3, happy to do so. -Adrian
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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?
  10. 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
  11. @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
  12. @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.
  13. @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
  14. 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