5kft

Members
  • Content Count

    195
  • Joined

  • Last visited

About 5kft

  • Rank
    Elite member

Recent Profile Visitors

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

  1. 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...
  2. 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...
  3. 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
  4. 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.
  5. Done and done https://armbian.atlassian.net/browse/AR-285 Thanks for doing the testing!
  6. @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.
  7. I just pushed a patch with the test changes for this to my local repo: https://github.com/5kft/build/commit/b75929e99f67a5d628bc031a1c4e73ab287c7df7. This patch is against the "sunxi-current" target. I can make a PR for this change, but again I don't have an H6 board to test any of this on, and I'd rather not do a PR until we know it works. Also, I'm not sure what the appropriate critical temperature is for the H6, so in this patch I left it at 105C just like for the H3/H5. It'd be great if you could give this a try on your OPi1+. You should be able to change directory to "/sys/class/thermal/thermal_zone0", and see the six new trip points. To test these changes on my H3s and H5s, I used "armbianmonitor -m" in "screen", with both "stress" and the appropriate "cpuburn" for the architecture (see https://github.com/ssvb/cpuburn-arm). The reported CPU clock rate should change appropriately when the temperature passes the various trip points. If this works I'd be happy to submit a PR for this change.
  8. Unfortunately I don't have any H6 boards, so I've never looked into this for the H6... However I just took a quick look at the DT include "sun50i-h6.dtsi" (in ".../arch/arm64/boot/dts/allwinner/") and it appears to be missing the same thermal-zones definitions as needed for the H3 and H5 to throttle down: thermal-zones { cpu-thermal { polling-delay-passive = <0>; polling-delay = <0>; thermal-sensors = <&ths 0>; trips { cpu_hot_trip: cpu-hot { temperature = <80000>; hysteresis = <2000>; type = "passive"; }; cpu_very_hot_trip: cpu-very-hot { temperature = <100000>; hysteresis = <0>; type = "critical"; }; }; cooling-maps { cpu-hot-limit { trip = <&cpu_hot_trip>; cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; }; }; }; If someone were to want look into this, I would suggest creating a patch containing the appropriate changes like I did for the H5 and see if it works for the H6 (at least if I had an H6 I would try this first...) E.g., see https://github.com/armbian/build/blob/master/patch/kernel/sunxi-current/update-correct-h3-h5-thermal-zones.patch. I hope this helps!
  9. Fixed! I marked this as Done (both sunxi-current and sunxi-dev, tested on both for H5 and H3)
  10. @Igor - I just checked in a new patch that fixes the thermal throttling issues (see https://github.com/armbian/build/commit/cc55d03a7b306e80f6fae1e16de1942af5fe9701). I have tested it extensively on the H5 (Nano Pi NEO2 Black) and throttling works great now. Example run after several minutes of "cpuburn-a53": The new patch includes the same changes for the H3, and I tested on an Orange Pi Zero H2+ with no heatsink, using both "stress" and "cpuburn-a7", and it works great. Here's an example run using "cpuburn-a7":
  11. Yes, that's it! The "cooling-device entries" map to the CPU clock frequencies to use - this is what makes it clock down and cool off. With these missing, it's just going to overheat and hit critical...
  12. I wouldn't think that would be the case... I would really need to refresh my memory on this area, but in doing a quick check of the DTs it seems that the cooling maps are much smaller/simpler than they were previously (?) - e.g., thermal-zones { cpu_thermal: cpu-thermal { polling-delay-passive = <0>; polling-delay = <0>; thermal-sensors = <&ths 0>; trips { cpu_hot_trip: cpu-hot { temperature = <80000>; hysteresis = <2000>; type = "passive"; }; cpu_very_hot_trip: cpu-very-hot { temperature = <100000>; hysteresis = <0>; type = "critical"; }; }; cooling-maps { cpu-hot-limit { trip = <&cpu_hot_trip>; cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; }; }; }; IIRC, there used to be more passive trips that would keep the CPU cooler earlier before hitting critical, weren't there? I was thinking of going to go back in time and look at some older ones to compare...I figure starting there might help provide some insight.
  13. @Igor - in case this is helpful, might this be fixed for the Duo2 by making the same/a similar change like I did for the R1? See my change here: https://github.com/armbian/build/commit/88023e0eccbf25c8a22d6365d20d9bc4df78003b. I believe the Duo2 uses the same power circuit as the R1. By adding the correct regulator entry for the MP2143DJ then the correct CPU clock values will be used. (I didn't make this change originally as I don't have a Duo2 to verify the changes on.)
  14. Totally agree!! There are faster/more powerful boards, but the NEO form-factor is super nice - the Plus2 is awesome as it has eMMC + Wi-Fi, and the Black is awesome because of the eMMC socket and variable-voltage regulator (allowing up to 1.4GHz operation), and perhaps most importantly the tiny 40mm^2 size. Their small metal cases for all of these are super nice as well. I only hope that they continue with the tiny form-factor with the replacements...!!
  15. Given that all of these platforms are showing the same issue, it seems likely that you may have a hardware issue with the board...?