ErwinH

The nightly releases for the sun8i boards still say kernel version 4.9.4 while the download says 4.10. Haven't checked all of the boards, but at least these are wrong: Orangepi PC Orangepi Zero

And I like to know what governor you're using, since that has some influence as well.

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

I think I can explain the reason why this happend. It's because during shutdown the cpu core voltage stays at the last setting before the driver was unloaded. The same reason why the u-boot failed at a reboot, the core voltage was to low when to run stable at the bootfrequency. In your case the voltage was high reaching thermal shutdown before the regulatordriver was loaded. The patch that enabled the regulatordriver in uboot should have fixed the thermal overheat at boot.

The highest frequency I was able to test and get a valid result was 1368MHz at 1400 mV. It ran a little over 95C.

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

I'm currently looking into it. Edit: There is a driver for SY8106A in mainline, so it should be simple.

Yup, I have a reproducable error when rebooting. If I lower the frequency and with that the core voltage it hangs on trying to boot MMC1. Either we need to increase the voltage when rebooting or add a driver to SPL that sets the correct voltage.

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!

The regulator should be lowered to 940000 indeed, but the Cooling table also needs some adjustments. Lets select all the entries for the warm and hot entry and limit very hot to the last or so 5 entries?

Your title says your an advanced member, and you are running a beta (should it even be named beta) image for a board that has a runnable image for 2 days. That would mean to me you've got the knowledge to find the information you need. Running stability tests got a lot of pitfalls and you need to be able to identify those to add any value to the results.

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.

I can rebase these commits on top of 4.10 if you like.

I used this u-boot with FEL, but you have to get the files by hand: You need the sunxi-spl.bin from the 32 bit version of the u-boot and the u-boot-dtb.bin from the 64 bit. sunxi-spl.bin is in the u-boot-sun50i/master/ folder if it isn't cleaned. This is my script to boot through FEL: #!/bin/sh UBOOT=u-boot-dtb.bin DTB=sun50i-h5-orangepi-pc2.dtb UIMAGE=Image DTBADDR=0x4FA00000 KERNELADDR=0x40080000 BOOTSCRADDR=0x43100000 BOOTSCR=boot.scr sunxi-fel -v -p spl sunxi-spl.bin \ write 0x44000 bl31.bin \ write 0x4a000000 $UBOOT \ write $DTBADDR $DTB \ write $KERNELADDR $UIMAGE \ write $BOOTSCRADDR $BOOTSCR \ reset64 0x44000 \

Great work! I'm curious what's the experience with my DVFS table. Hope it runs stable on all the boards!

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

Sure it can connect to every Orange Pi Board using a USB breakout. (At least I hope that's what they mean) and the USB A connectors are linked to 2 of the 10 GPIO outputs on the JMS568.

Based on this information: 3 Expansion Port OrangePi Zero has 3 UART ports. 2 on the 26 pin header and 1 on a separate header, used for debugging. If these UART ports are enabled in the kernel (using DTB or FEX file) you should be able to open them using /dev/ttyS0-2. You can easily test it by placing a jumper over the TX and RX pins and open the serial port. screen /dev/ttyS1 57600 When you type something you should see it in your console.

500mA should do, but you need a good power supply and more importantly a good micro usb cable since micro usb connector is a big reason for voltage drops causing instability. I'm running the board without WiFi or display without any problems, but increasing the load might give you issues. To make sure it isn't because of the power supply or the cable you can try the GPIO pins, which give you less voltage drop.

Yes you can power the board from GPIO pins, both the 13 pin and the 26 pin. For more information on the pinout: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero#Expansion_Port Combining 2 different power supplies isn't a good idea. See: http://www.tomshardware.co.uk/forum/309683-28-combine-rail-multiple-power-supplies#r2918555

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.

This is the longer 20 sec version, notice how the TX values stay consistent while the RX speed drops above RX Delay > 5. http://pastebin.com/04KeW1GX These values however seem a bit high: 114: 120091 19350724 554379 0 GIC 1c30000.eth Uptime: 17 min.