ErwinH

Ok, for all the "Buy cheap, Buy twice" fellows doing the necessary research only after they bought hardware here's a great (and the official) place to discuss the funny mismatch between expectations and reality: http://www.orangepi.org/orangepibbsen/forum.php?mod=forumdisplay&fid=67

It's unbelievable. 3 days ago I wrote in the thread you started to pollute with support questions: 'This is neither an announcement of Armbian support for this device nor anything a typical end user should play with'. So please do not disrupt development/testing efforts in the main thread and stay with your support talk here.
PSU: https://aliexpress.com/store/product/orange-pi-orange-pi-plus-Europe-Power-Adapter-5V-2A-Europe-Power-Supply/1553371_32281484383.html SD cards / getting started: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-authenticity

The patch is applied and should ne in the latest nightly.

I've sent a patch to enable the SY8106A driver in SPL.

I've sent a patch to enable the SY8106A driver in SPL.

Created a small tool that checks the stability of a range of frequencies using HPL. 
 
Simple clone the git and install libmpich-dev and you're good to go.
 
https://github.com/ehoutsma/StabilityTester
 
If you want to increase the load you can alter the HPL.dat and set the Ns to 10960, which is the maximum size you can run on a 1G device before swapping kicks in.
 
Edit: Don't be scared of high temperatures! High temperatures are good!

To check the stability of the board have a look at this post:             #91            
 
It has all the links to the info you need to check the stability of the board.

Created a small tool that checks the stability of a range of frequencies using HPL. 
 
Simple clone the git and install libmpich-dev and you're good to go.
 
https://github.com/ehoutsma/StabilityTester
 
If you want to increase the load you can alter the HPL.dat and set the Ns to 10960, which is the maximum size you can run on a 1G device before swapping kicks in.
 
Edit: Don't be scared of high temperatures! High temperatures are good!

Created a small tool that checks the stability of a range of frequencies using HPL. 
 
Simple clone the git and install libmpich-dev and you're good to go.
 
https://github.com/ehoutsma/StabilityTester
 
If you want to increase the load you can alter the HPL.dat and set the Ns to 10960, which is the maximum size you can run on a 1G device before swapping kicks in.
 
Edit: Don't be scared of high temperatures! High temperatures are good!

There are bits and pieces scattered. There is progress getting the board supported by Armbian, but nothing usable yet.

This is my first suggestion for a DVFS table for the H5.
&cpu0 { operating-points = < /* kHz uV */ 1368000 1400000 1344000 1400000 1296000 1340000 1248000 1280000 1224000 1260000 1200000 1240000 1152000 1200000 1104000 1170000 1080000 1160000 1056000 1150000 1008000 1100000 960000 1080000 936000 1060000 816000 1000000 792000 1000000 648000 970000 480000 940000 240000 940000 120000 940000 >; #cooling-cells = <0x2>; cooling-min-level = <0x0>; cooling-max-level = <0x13>; } I've taken the lowest working voltage and added 40mV to add margin for higher temperatures and fluctuations in the soc's/ boards.
 
When running test loads on the DVFS using xhpl and comparing these with the settings that I mentioned above using the performance governor I get the following result:
================================================================================ T/V N NB P Q Time Gflops -------------------------------------------------------------------------------- WR02R2L2 10240 256 1 1 285.51 2.508e+00 Using the Allwinner settings:
================================================================================ T/V N NB P Q Time Gflops -------------------------------------------------------------------------------- WR02R2L2 10240 256 1 1 314.57 2.276e+00 I've logged the temperature and the cpu frequency for both settings and giving me the following chart:
 

 
I didn't apply forced cooling but only passive cooling using a heatsink.
 
There still is quite a bit room for improvement, since the throttling kicks in hard, which doesn't seem correct. But it's a good start.

This is my first suggestion for a DVFS table for the H5.
&cpu0 { operating-points = < /* kHz uV */ 1368000 1400000 1344000 1400000 1296000 1340000 1248000 1280000 1224000 1260000 1200000 1240000 1152000 1200000 1104000 1170000 1080000 1160000 1056000 1150000 1008000 1100000 960000 1080000 936000 1060000 816000 1000000 792000 1000000 648000 970000 480000 940000 240000 940000 120000 940000 >; #cooling-cells = <0x2>; cooling-min-level = <0x0>; cooling-max-level = <0x13>; } I've taken the lowest working voltage and added 40mV to add margin for higher temperatures and fluctuations in the soc's/ boards.
 
When running test loads on the DVFS using xhpl and comparing these with the settings that I mentioned above using the performance governor I get the following result:
================================================================================ T/V N NB P Q Time Gflops -------------------------------------------------------------------------------- WR02R2L2 10240 256 1 1 285.51 2.508e+00 Using the Allwinner settings:
================================================================================ T/V N NB P Q Time Gflops -------------------------------------------------------------------------------- WR02R2L2 10240 256 1 1 314.57 2.276e+00 I've logged the temperature and the cpu frequency for both settings and giving me the following chart:
 

 
I didn't apply forced cooling but only passive cooling using a heatsink.
 
There still is quite a bit room for improvement, since the throttling kicks in hard, which doesn't seem correct. But it's a good start.

See the pastebin log.

Just did some tests seeing at what core voltage the board is able to function using Linpack to determine if there appear any errors when running at these speed/voltage combinations.
Here is the log:
http://pastebin.com/0z3FhfkU
 
The maximum core frequency my board is able to function is: 1368 MHz but it needs at the very least 1380 mV, at 1370mV it fails the Linpack benchmark test. You need a good cooling solution if you want to run these speeds. I needed to add a heatsink plus a large airflow using a tunnel with 3 4x4x4cm High speed fans.
 
If you compare these findings with the recommendations there appears to be some room for improvement:
 
; lv1: core vdd is 1.30v if cpu frequency is (1104Mhz, 1152Mhz]
; lv2: core vdd is 1.26v if cpu frequency is (1008Mhz, 1104Mhz]
; lv3: core vdd is 1.20v if cpu frequency is (816Mhz, 1008Mhz]
; lv4: core vdd is 1.10v if cpu frequency is (648Mhz, 816Mhz]
; lv5: core vdd is 1.04v if cpu frequency is (480Mhz, 648Mhz]
 
I hope this information will help in creating an optimal DVFS table for the OrangePI PC2.

They are doing a much better job listening to the customers. 
 
My second Zero also includes a SPI flash chip on the back.

To get cpufreq-info, temperature and throttling you need a kernel that has the patches for these drivers. The beta currently is still build with a kernel that doesn't have these patches. You can build your own kernel / image which do include these patches. https://github.com/megous/linux
 
I've build my own image with this kernel and it's running nicely, with throttling, temperature/cpufreq readout and btrfs. When these patches either get mainline, or integrated in the armbian build system for the beta the One/Zero boards can run 4.9 kernel as well.

To get cpufreq-info, temperature and throttling you need a kernel that has the patches for these drivers. The beta currently is still build with a kernel that doesn't have these patches. You can build your own kernel / image which do include these patches. https://github.com/megous/linux
 
I've build my own image with this kernel and it's running nicely, with throttling, temperature/cpufreq readout and btrfs. When these patches either get mainline, or integrated in the armbian build system for the beta the One/Zero boards can run 4.9 kernel as well.