Please select To the mobile version | Continue to access the desktop computer version

OrangePi

 Login            
 Register            
Search
Hot search: orangepi
Author: bronco

RPi-Monitor for H3

[Copy link]
 Author| Post time 2015-11-29 02:44:12 | Show all posts
A final note: As can be seen easily in the graphs above (and that's what RPi-Monitor is made for! ): when using Xunlong's default settings, performance governor and a display connected we already reach insane 54°C when the SoC is idle and does exactly NOTHING.

With sane dvfs settings with connected display we reach the same temperature under full load when running with 480 MHz and do not exceed 65°C at 1.2 GHz. That's 54°C while being idle (doing nothing) with wrong dvfs settings vs. 65°C being fully utilised @ 1.2 GHz with sane settings (or 54°C idle vs. 43-44°C idle). So even if the voltages can not be adjusted that low it makes perfectly sense to use additional operating points to let the SoC run at sane voltages when being busy and especially when idling (what's the case most of the times).
 Author| Post time 2015-11-29 02:56:17 | Show all posts
hojnikb replied at 2015-11-29 02:43
So, i've gotten an idea for auto undervolting...

Lets say you want to achieve the lowest stable vol ...

As already said: I started to prepare something like this prior to arrival of the 1st OPi PC -- see below. The goal is to walk through all possible combinations, adjust settings, exchange script.bin, reboot and test again.
Thanks to you I discovered that my setup was crap (headless) and you've also take into account that one H3 behaves like this and another like that (you can read in the linux-sunxi archives about stuff like this when they started a few years back with Cubieboards and rolled out a few voltage settings that worked reliable on all dev's boards but not in the wild). So stable settings here and there should be compared and sane voltage adjustments (increase) applied. But what we know right now is simple: Even if we don't decrease voltages to the minimum it already helps defining a few additional OPPs (and limiting cpufreq to 1.2 GHz) for H3 based Orange Pis to solve many of the thermal/stability issues users suffer from.

Still work in progress and that's just a really early stub (to get the idea what's different when you want to have a script run unattended over hours with lots of reboots in between):

  1. #!/bin/bash
  2. #
  3. # dvfs-check.sh
  4. #
  5. # This script needs a fex file suitable for sunxi-3.3/3.4 kernels containing dvfs operating
  6. # points and starts to test lower voltage settings for each specified cpufrequency by
  7. # continually decreasing the voltage in steps of 20mV until cpufreq-ljt-stress-test reports
  8. # the first error.
  9. #
  10. # Since the whole attempt requires modifiying script.bin and restarting afterwards the script
  11. # has to be called from /etc/rc.local (or as a daemon when distros are used that don't know
  12. # rc.local). Logging and error reporting happen to syslog.
  13. #
  14. # Add prior to "exit 0" in /etc/rc.local: /path/to/dvfs-check.sh &
  15. #
  16. # prerequisits:
  17. # - ensure that [/media]/boot gets mounted (/etc/fstab)
  18. # - ensure that script.bin is the right place to write otherwise adjust in the script
  19. # - ensure that $PATH contains the location of fex2bin, cpuburn-a7 and cpufreq-ljt-stress-test
  20. # - install RPi-Monitor with the appropriate H3 template
  21. # - a master fex file ${MyFex} points to that contains LV entries in usual order: LV1 being
  22. #   the highest clockspeed and decreasing from then on

  23. # Results:
  24. #
  25. # The file specified in ${MyResults} should contain for every specified cpufreq a single
  26. # line containing all tested voltages tab separated. The first voltage that leads to errors
  27. # will be marked with "-FAILED"

  28. export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  29. MyFex="/Users/tk/Documents/Projekte/aktuell/Mini-Server-Buch/Orange Pi PC/dvfs test/basis.fex"
  30. MyScriptBin="/boot/script.bin"
  31. MyResults="/Users/tk/Documents/Projekte/aktuell/Mini-Server-Buch/Orange Pi PC/dvfs test/results.txt"
  32. MyCommandFile="/Users/tk/Documents/Projekte/aktuell/Mini-Server-Buch/Orange Pi PC/dvfs test/next.test"

  33. Main() {
  34.         if [ ! -f "${MyCommandFile}" ]; then
  35.                 # start from scratch
  36.                 export LastFreq=0
  37.                 export LastVoltage=100000000
  38.                 NextFreq=$(GetNextCpuFreq)
  39.                 NextVoltage=$(GetNextVoltage)
  40.                 echo -e "${NextFreq}\t${NextVoltage}" >"${MyCommandFile}" || (logger -t "dvfs-check" -s "Could not write command file ${MyCommandFile}. Exiting"; exit 1)
  41.                
  42.                
  43.                 logger -t "dvfs-check" "Preparing $(( ${NextFreq} / 1000000 ))MHz@${NextVoltage}mV test"
  44.         fi
  45. } # Main

  46. GetNextCpuFreq() {
  47.         # This function walks through availabe dvfs entries in the fex file and chooses the next
  48.         # one compared to $1
  49.        
  50.         # walk through defined dvfs operating points from lowest freq to highest
  51.         grep "^LV._freq" "${MyFex}" | sort -r | while read ; do
  52.                 set ${REPLY}
  53.                 CPUFreq=$3
  54.                 if [ ${CPUFreq} -gt ${LastFreq} ]; then
  55.                         echo -n ${CPUFreq}
  56.                         break
  57.                 fi
  58.         done
  59. } # GetNextCpuFreq

  60. GetNextVoltage() {
  61.         # this function tries to get the next voltage setting to test for cpufreq $1
  62.         if [ ${LastVoltage} -eq 100000000 ]; then

  63. } # GetNextVoltage


  64. Main
Copy the Code




1

Threads

116

Posts

666

Credits

Senior member

Rank: 4

Credits
666
Post time 2015-11-29 03:07:18 | Show all posts
Edited by hojnikb at 2015-11-29 03:09

Great to see you're already working on it

With great devs and community, we can extract a lot from this tiny, cheap board
 Author| Post time 2015-11-29 03:43:21 | Show all posts
hojnikb replied at 2015-11-29 03:07
Great to see you're already working on it

With great devs and community, we can extract a lo ...

Scusa, but I'm no dev at all (but I hope you didn't refer to me) and the devs that will do the real work won't care that much about the goals the 'community' here seems to be interested in (2D/3D and video HW acceleration and..... CHEAP).
Currently there exists no community around the H3 SoC. It's just the overclocker camp here.

The H3 looks somewhat promising for IoT stuff (when underclocked) and that's it. In the consumer area we're experiencing the shift from 32 to 64 bit in 2016 (for no reason, since nearly all of the devices can't benefit at all from '64 bit') and next year no one will even remember H3 (not even Steven -- just kidding ).

I hope Steven will follow the dirt-cheap route and designs a board that makes the most out of H3. Less external components as possible and being able to be fed by passive PoE directly. Would be the perfect wired IoT board if the price is ok.

4

Threads

52

Posts

284

Credits

Intermediate member

Rank: 3Rank: 3

Credits
284
Post time 2015-11-29 04:51:55 | Show all posts
Edited by makama80 at 2015-11-29 16:02

@bronco: there is certainly a more formal community around the H3: have a search for H3 on this linux-sunxi.org-page and please look at denx.de. Also look at https://lkml.org/lkml/2015/10/27/538. Do I need to say more?
So the H3 is on the radar for U-boot and mainline kernel.

Progress for mainline Linux kernel will always be slow: these allwinner chips were / are intended for Android. Actually we are lucky these boards boot Linux at all.
Even for the A10 / A20 Linux mainline kernel progress is still being made. So when the 64 bit mega-quadzilliumcore with even more GHz's you mention above will arrive in 2016 on SBC's, you will come across the same issues over again you are mentioning everywhere in this forum.

1

Threads

116

Posts

666

Credits

Senior member

Rank: 4

Credits
666
Post time 2015-11-29 17:26:40 | Show all posts
H3 is a great and capable settop box chip. I mean, that thing can decode 4k@h.265 while costing a few $ at most.
 Author| Post time 2015-11-29 20:24:18 | Show all posts
makama80 replied at 2015-11-29 04:51
@bronco: there is certainly a more formal community around the H3: have a search for H3 on this linu ...

I know this 'community' since I contribute there regularly. In my opinion the H3 is great for IoT and other low-end stuff but for my normal use cases the A20 is still superiour and I still hope, that Allwinner releases next year an A20 successor with 2 more cores (then also produced in a 28nm process so this chip could be clocked at up to 1.2GHz like the H3).

The H3 is a rather slow SoC made for cheap devices due to its internals (Ethernet/USB PHYs, no need for PMIC/PMU) with some enhanced capabilities (h.265 decoding within Android) but it really shines when underclocked (then it's still a bit hot but rather energy efficient and due to the 4 cores you can play with 'latency vs. performance'). The good news: All the heat/stability problems this forum is full of are self-inflicted by choosing dumb dvfs settings and can be resolved by refraining from overvolting and using a few more sane dvfs table entries.

If you're happy with frying your device even when idle keep on doing so. It's a bit weird but who cares

0

Threads

6

Posts

173

Credits

Registered member

Rank: 2

Credits
173
Post time 2015-12-23 07:08:41 | Show all posts
Hello bronco,
thank you for your effort in this cpu overvoltage and overclock "problem". This thread you've started is mandatory reading. Because I don't want to fry my OPi, I realize using some of sane setting mentioned here:
http://www.orangepi.org/orangepi ... &fromuid=333892

I've just received OPi PC. So far I installed Debian and correct cpu voltage and freq as are in this post 38#
Right after RPi-monitor installation, system shows 54°C. So not complete iddle. Will try testing more with  cpuburn-a7 and cpufreq-ljt-stress-test tomorow. Need to install this first. I have OPi without radiator yet.
Let me know if you interested for testing some other values. I can do it before I mount radiators on chips.

1

Threads

4

Posts

86

Credits

Registered member

Rank: 2

Credits
86
Post time 2015-12-23 15:03:37 | Show all posts
I have a OPi 2 that I wanted to use as a stable headless file-server but with all the thermal issues I just put the card away and moved on to other platforms. I don't care about 2d/3d since the system is headless, so I'm going to attempt to put the suggestions in this thread to use and try the card again. Is there anything I can do to help with the testing? I'm going to try running dvfs-check.sh with one of the loboris mini images. (I'm a novice but I'm trying to learn so any tips are always welcome.)

0

Threads

6

Posts

173

Credits

Registered member

Rank: 2

Credits
173
Post time 2015-12-23 22:44:38 | Show all posts
1st test with cpuburn OPi PC without radiator and I didn't succeed. When OPi is iddle (480MHz@1V) temperature is ok. Around 41°C, but immediately after cpuburn is started (1200MHz@1,3V) temp is raised over 80°C and after few minutes I have lost one core. Ambient temp was 18,5°C and OPi was headless. I don't really understand why OPi PC is announced as 1,6GHz capable device. I will try to play with some undervolted settings later.

This post contains more resources

You have to Login for download or view attachment(s). No Account? Register

x
You have to log in before you can reply Login | Register

Points Rules

Archiver|Mobile edition|Darkroom|OrangePi En ( 粤ICP备14086627号-2

2020-11-24 12:22 GMT+8 , Processed in 0.035268 second(s), 20 queries .

Powered by Discuz! X3.2

© 2014-2015 orangepibbs en.

Quick Reply To Top Return to the list