41 41
Christos

Armbian for OrangePi PC2, AllWinner H5

Recommended Posts

Tried image, works very smoothly for a test image. I did notice, that frequency seems to stay at 1.3Ghz, but quickly drops down to 1.0Ghz with a bit of load (like scrolling).

 

Is this normal behavior ? Shouldn't cpu in idle sit at lowest possible frequency and only ramp when needed ?

 

As for stability testing; cpuburn-a53 is for stressing, what about testing for actual stability ? What app is the best for that ?

Share this post


Link to post
Share on other sites

As for stability testing; cpuburn-a53 is for stressing, what about testing for actual stability ? What app is the best for that ?

 

You want stability under stress, so...

Share this post


Link to post
Share on other sites

You want stability under stress, so...

i don't think cpuburn checks for errors, so it's useless on it's own beyond heating the board.

 

Would a custom script of x264 or something like that do the job ?

Share this post


Link to post
Share on other sites

i don't think cpuburn checks for errors, so it's useless on it's own beyond heating the board.

 

If you are not willing to help why don't you simply stop here instead of blowing up this thread with more and more pages full of useless conversation? As already said: it requires some time and will to contribute, 'fire and forget' doesn't work and always questioning any advice you get (from people that went already through this) is maybe also not the smartest move?

 

While cpuburn unlike other tools does not 'check' for errors it triggers them reliably since as soon as throttling jumps in cpufreq will be adjusted and this automatically tests through the different DVFS operating points (and if undervoltage occurs you get a nice kernel panic and stuff like that). But as ErwinH already said: Without reading carefully through the links provided it's just a waste of time...

Share this post


Link to post
Share on other sites

Given how information is scattered all over the place, it's no wonder noobs don't find appropriate information and thus ask on the forums.

After all, thats what forums are for.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Hm. Something is wrong with the OPP table anyway

 

 

analyzing CPU 3:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.24 ms.
  hardware limits: 792 MHz - 1.37 GHz
  available frequency steps: 792 MHz, 816 MHz, 864 MHz, 912 MHz, 936 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.08 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 792 MHz and 1.30 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 792 MHz (asserted by call to hardware).
  cpufreq stats: 792 MHz:77.05%, 816 MHz:1.07%, 864 MHz:0.00%, 912 MHz:0.21%, 936 MHz:0.00%, 960 MHz:0.21%, 1.01 GHz:0.00%, 1.06 GHz:0.00%, 1.08 GHz:0.00%, 1.10 GHz:0.00%, 1.15 GHz:0.23%, 1.20 GHz:0.00%, 1.22 GHz:0.00%, 1.25 GHz:0.00%, 1.30 GHz:20.85%, 1.34 GHz:0.00%, 1.37 GHz:0.38%  (34)

 

 

 

Looks like OPPs below 792MHz were not added

 

 

[    1.853650] core: _opp_supported_by_regulators: OPP minuV: 980000 maxuV: 980000, not supported by regulator
[    1.853658] cpu cpu0: _opp_add: OPP not supported by regulators (768000000)
[    1.853722] core: _opp_supported_by_regulators: OPP minuV: 970000 maxuV: 970000, not supported by regulator
[    1.853727] cpu cpu0: _opp_add: OPP not supported by regulators (720000000)
[    1.853775] core: _opp_supported_by_regulators: OPP minuV: 970000 maxuV: 970000, not supported by regulator
[    1.853780] cpu cpu0: _opp_add: OPP not supported by regulators (672000000)
[    1.853844] core: _opp_supported_by_regulators: OPP minuV: 970000 maxuV: 970000, not supported by regulator
[    1.853848] cpu cpu0: _opp_add: OPP not supported by regulators (648000000)
[    1.853895] core: _opp_supported_by_regulators: OPP minuV: 940000 maxuV: 940000, not supported by regulator
[    1.853899] cpu cpu0: _opp_add: OPP not supported by regulators (528000000)
[    1.853947] core: _opp_supported_by_regulators: OPP minuV: 940000 maxuV: 940000, not supported by regulator
[    1.853951] cpu cpu0: _opp_add: OPP not supported by regulators (480000000)
[    1.854017] core: _opp_supported_by_regulators: OPP minuV: 940000 maxuV: 940000, not supported by regulator
[    1.854022] cpu cpu0: _opp_add: OPP not supported by regulators (240000000)
[    1.854069] core: _opp_supported_by_regulators: OPP minuV: 940000 maxuV: 940000, not supported by regulator
[    1.854074] cpu cpu0: _opp_add: OPP not supported by regulators (120000000)

 

 

 

Edit:

regulator-min-microvolt = <1000000>;

so the regulator can't go lower than 1V and all OPPs that reference <1V are discarded.

Share this post


Link to post
Share on other sites
regulator-min-microvolt = <1000000>;

 

So we need 'regulator-min-microvolt = <940000>;' instead?

 

@ErwinH: Did you test the board with these lower OPP too? Eg. by adjusting cpufreq through sysfs and then running cpuburn-a53 on each available cpufreq at least for a few minutes? Something like that:

echo 120000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
cpuburn-a53 & 
for i in $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies); do
	echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
	sleep 600
done
pkill cpuburn-a53

Share this post


Link to post
Share on other sites

so the regulator can't go lower than 1V and all OPPs that reference <1V are discarded.

 

 

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?

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

 

Thank you for the tool!

 

Here are my results. I had a fan blowing directly to the SoC (no heatsink yet) just to let it run at highest possible frequency without throttling.

 

 

root@orangepipc2:/home/benhjamin/StabilityTester# ./stabilityTester.sh
Testing frequency 792000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 816000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 864000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 912000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 936000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 960000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 1008000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 1056000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 1080000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 1104000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 1152000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument

Testing frequency 1200000
Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument
Cooling down: 54123

Done testing stability:
Frequency: 792000	Voltage: 1000000	Success: 1	Result:        0.0048034
Frequency: 816000	Voltage: 1000000	Success: 1	Result:        0.0048034
Frequency: 864000	Voltage: 1040000	Success: 1	Result:        0.0048034
Frequency: 912000	Voltage: 1050000	Success: 1	Result:        0.0048034
Frequency: 936000	Voltage: 1060000	Success: 1	Result:        0.0048034
Frequency: 960000	Voltage: 1080000	Success: 1	Result:        0.0048034
Frequency: 1008000	Voltage: 1100000	Success: 1	Result:        0.0048034
Frequency: 1056000	Voltage: 1150000	Success: 1	Result:        0.0048034
Frequency: 1080000	Voltage: 1160000	Success: 1	Result:        0.0048034
Frequency: 1104000	Voltage: 1170000	Success: 1	Result:        0.0048034
Frequency: 1152000	Voltage: 1200000	Success: 1	Result:        0.0048034
Frequency: 1200000	Voltage: 1240000	Success: 1	Result:        0.0048034

 

 

Share this post


Link to post
Share on other sites

I would say that adding a driver to the SPL is more reliable since it would work in case of a kernel crash. Some boards like Cubietruck already use I2C in SPL to communicate with the PMIC.

Edit:

 

 

Done testing stability:
Frequency: 648000       Voltage: 970000         Success: 1      Result:        0.0048034
Frequency: 672000       Voltage: 970000         Success: 1      Result:        0.0048034
Frequency: 720000       Voltage: 970000         Success: 1      Result:        0.0048034
Frequency: 768000       Voltage: 980000         Success: 1      Result:        0.0048034
Frequency: 792000       Voltage: 1000000        Success: 1      Result:        0.0048034
Frequency: 816000       Voltage: 1000000        Success: 1      Result:        0.0048034
Frequency: 864000       Voltage: 1040000        Success: 1      Result:        0.0048034
Frequency: 912000       Voltage: 1050000        Success: 1      Result:        0.0048034
Frequency: 936000       Voltage: 1060000        Success: 1      Result:        0.0048034
Frequency: 960000       Voltage: 1080000        Success: 1      Result:        0.0048034
Frequency: 1008000      Voltage: 1100000        Success: 1      Result:        0.0048034
Frequency: 1056000      Voltage: 1150000        Success: 1      Result:        0.0048034
Frequency: 1080000      Voltage: 1160000        Success: 1      Result:        0.0048034
Frequency: 1104000      Voltage: 1170000        Success: 1      Result:        0.0048034
Frequency: 1152000      Voltage: 1200000        Success: 1      Result:        0.0048034
Frequency: 1200000      Voltage: 1240000        Success: 1      Result:        0.0048034

 

 

 

Edit 2: You don't need a SYxxx regulator driver, just one I2C write to set the voltage and maybe an I2C read to confirm that it was set, but you'll need a H3 compatible I2C controller driver if it is not present already.

Share this post


Link to post
Share on other sites

I would say that adding a driver to the SPL is more reliable since it would work in case of a kernel crash. Some boards like Cubietruck already use I2C in SPL to communicate with the PMIC.

 

 

I'm currently looking into it.

Edit: There is a driver for SY8106A in mainline, so it should be simple.

Share this post


Link to post
Share on other sites

My PC2 ran 24 hours of cpuminer on four cores. No crashes, no syslog entries that indicate anything is wrong. Temps 70-75C. Clock speeds 1056/1080MHz. Hashes between 3.2 and 3.3KH/s. No heatsink. No fan. Board in a slightly enclosed space with no additional airflow enhancements. Image from 20170127.

 

I'll reboot to the new kernel and try xhpl and/or Linpac.

Share this post


Link to post
Share on other sites

Clock speeds 1056/1080MHz. Hashes between 3.2 and 3.3KH/s. No heatsink. No fan.

 

Very nice :)  As a comparison: With Pine64 I got 3.9 khash/s at 1296 MHz (with heatsink and IIRC 2 fans). So performance of CPU cores in A64 and H5 is identical but Xunlong did again a great job regarding heat dissipation. Pine64 also uses the ground plane as heatsink but if I remember correctly I got these values on my Pine64 without heatsinks: http://linux-sunxi.org/File:Testing_throttling_and_performance_behaviour_on_Pine64.png

 

@willmore: Would be interesting sometimes later to compare with Pine64 (can't do myself due to both boards in a test setup a few hundred km away). But now stability testing through different DVFS operating points is more interesting. Would be great to let something loop through all available cpufreqs as outlined in #129 above and test with cpuburn-a53, cpuminer and ErwinH's stabilityTester.sh (after applying latest fixes from build system to also walk through the lowest operating points)

Share this post


Link to post
Share on other sites

@tkaiser: Of course. I have a Pine64 as well. I'd be glad to run any testing on it that you'd like. I haven't had it up and running in a while, so I may need to run a few updates to get it current.

 

What particular setup would you like me to test?

 

Oh, my Pine64 also does not have a heatsink--it, like the PC2 are completely stock.

 

I'm very impressed with both the PC2 and the work that all of you have done to get armbian running this well on it this quickly. Thank you.

Share this post


Link to post
Share on other sites

What particular setup would you like me to test?

 

For now as already outlined just the DVFS stuff for OPi PC2. And if there's some time later you might try out cpuminer with identical 'environmental' conditions as OPi PC2 just to get an idea how efficient both board designs are regarding heat dissipation through the lower BGA side using the board itself as huge heatsink. But for me personally current status with H5, OPi PC2 and the other announced new devices (mainline kernel, +1.3GHz available, GbE working, count of USB2 ports, price including shipping) means almost every A64 design is already 'dead'/uninteresting now. So there's no need to rush with such comparisons :)

Share this post


Link to post
Share on other sites

@zador.blood.stained

 

It looks that the latest builds (Ubuntu desktop) give a very good result and stable operation as tested with my own DSP application here.

 

Tried a few reboots and had no issues, though I see some strange reporting in the tty console

         Unmounting /var/log...
[FAILED] Failed unmounting /tmp.
[  OK  ] Unmounted /run/user/1000.
[  OK  ] Unmounted /var/log.hdd.
[FAILED] Failed unmounting /var/log.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Stopped target Local File Systems (Pre).
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Stopped Create Static Device Nodes in /dev.
[  OK  ] Started Unattended Upgrades Shutdown.
[  OK  ] Reached target Shutdown.
[   82.195445] reboot: Power down
INFO:    PSCI Affinity Map:
INFO:      AffInst: Level 0, MPID 0x0, State ON
INFO:      AffInst: Level 0, MPID 0x1, State ON
INFO:      AffInst: Level 0, MPID 0x2, State ON
INFO:      AffInst: Level 0, MPID 0x3, State ON
ERROR:   PSCI system shutdown: still alive ...

And this is where it stops but the message is strange to me.

Just reporting it FYI.

 

OOOOoooops!!

As I was typing this message and left the board at its current setting (turned off supposedly), it sudenly rebooted by its own and reached 132 degrees!!

I had the tty already connected and this is the remaining output

U-Boot SPL 2017.01-rc1-g5df570f-dirty (Jan 27 2017 - 13:53:59)
DRAM: 1024 MiB
Trying to boot from MMC1NOTICE:  BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):cd7fa48
NOTICE:  BL3-1: Built : 13:53:22, Jan 27 2017
NOTICE:  PLL_CPUX: 90001410
INFO:    BL3-1: Initializing runtime services
INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9


U-Boot 2017.01-rc1-g5df570f-dirty (Jan 27 2017 - 13:57:55 +0200) Allwinner Technology

CPU:   Allwinner H5 (SUN50I)
Model: OrangePi PC 2
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

HDMI connected: Setting up a 1920x1080 hdmi console (overscan 0x0)
hdmi enabled
In:    serial
Out:   vga
Err:   vga
Net:   phy interface7
eth0: ethernet@1c30000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
1768 bytes read in 176 ms (9.8 KiB/s)
## Executing script at 4fc00000
Boot script loaded from mmc
91 bytes read in 148 ms (0 Bytes/s)
24310 bytes read in 263 ms (89.8 KiB/s)
4222403 bytes read in 437 ms (9.2 MiB/s)
11261960 bytes read in 659 ms (16.3 MiB/s)
## Loading init Ramdisk from Legacy Image at 4fe00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    4222339 Bytes = 4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 49bf9000, end 49fffd83 ... OK
   Loading Device Tree to 0000000049bf0000, end 0000000049bf8ef5 ... OK

Starting kernel ...

Loading, please wait...
starting version 229
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
[    2.403476] thermal thermal_zone0: critical temperature reached(132 C),shutting down
done.
Begin: Will now check root file system ... fsck from util-linux 2.27.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1
/dev/mmcblk0p1: clean, 184517/954720 files, 1211259/3811232 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.
[    2.751503] thermal thermal_zone0: critical temperature reached(132 C),shutting down
[    2.939899] reboot: Power down
INFO:    PSCI Affinity Map:
INFO:      AffInst: Level 0, MPID 0x0, State ON
INFO:      AffInst: Level 0, MPID 0x1, State ON
INFO:      AffInst: Level 0, MPID 0x2, State ON
INFO:      AffInst: Level 0, MPID 0x3, State ON
ERROR:   PSCI system shutdown: still alive ...


At that stage I unplugged the power..

 

hope this info helps

Share this post


Link to post
Share on other sites

@tkiser Okay, so I'll run the script from #129 and record temps? Or just run it and see if the machine fails in some way?

 

Please keep an eye on actual cpufreq ('sudo armbianmonitor -m' in another shell) since without a heatsink testing through the upper DVFS operating points is pointless. This is more about the lower ones and as soon as throttling jumps in you can stop the test.

Share this post


Link to post
Share on other sites

yeah, i had the same issue when i bumped up Ns to 8192. Frequencies above ~900Mhz simply reach throttling points before stress test is complete.

Have to rig up a heatsink and a decent fan to properly test all of them (btw, can frequencies even go above 1300Mhz ?)

Share this post


Link to post
Share on other sites

Did another build with latest commits.

 

Non-booting problem again.

Latest commit that was working ok was commit dc6f9d9, with commits after that it stopped booting properly and go into endless reboots.

Share this post


Link to post
Share on other sites

Have to rig up a heatsink and a decent fan to properly test all of them (btw, can frequencies even go above 1300Mhz ?)

The max frequency is probably limited in /etc/default/cpufrequtils

 

OOOOoooops!!

As I was typing this message and left the board at its current setting (turned off supposedly), it sudenly rebooted by its own and reached 132 degrees!!

I had the tty already connected and this is the remaining output

Hm. Critical temperature is set to 110°C, and I noticed these PSCI messages too when shutting down, but I usually cut the power right after shutdown.

Share this post


Link to post
Share on other sites

Works for me

 

For you it was already working from the start.

If you remember there was the pullup issue for some..

 

 

 

P.S.

 

I'm performing another build, just in case something went wrong before..

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
41 41