Adrian Cable

  • Content Count

    23
  • Joined

  • Last visited

About Adrian Cable

  • Rank
    Member

Recent Profile Visitors

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

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