Orange Pi Zero Plus / H5 Chip

[kris777]

Orange Pi Zero Plus (H5 / 1000M ethernet )
Is a working Armbian system ? .....  It's probably new :-)

[chwe]

Maybe you should start a thread in the board bring up section. Where you point out pros and cons of this board and give some information about this board so that people don't have to google this before they can contribute to the discussion.  

 

Similar to @tkaiser support proposal for the rock64:

 

[tkaiser]

1 hour ago, kris777 said:

Is a working Armbian system ?

 

As with every other H5 device out there: no. H5 is 'work in progress', maybe starting with 4.13 this will change.

 

Besides that this is 'just another H5 board' and I think we'll support it anyway. There's already some information available here: http://www.cnx-software.com/2017/08/12/15-orange-pi-zero-plus-board-released-with-allwinner-h5-soc-gigabit-ethernet-wifi-and-spi-flash/ (I think the comparison with Plus 2 H5 is not the best once since I consider the Zero Plus simply a 'Zero' upgrade, replacing Fast with Gigabit Ethernet and crappy ok-ish Wi-Fi.

 

Status:

• no schematics released yet: http://www.orangepi.org/downloadresources/
• plans for such a 'Zero Plus' obviously existed since Xunlong started to ship their NAS Expansion board (see devices listed and date of this commit)
• maybe somewhere in this mess here there's a DT or sysconfig.fex hidden describing hardware features correctly? Don't care since I get headache trying to look through these repos.

Once schematics are available I would believe it'll take not that much time to add support (adjusting device tree settings and including 8189fs driver, everything else should be the same as with every other H5 device out there).

[fabieng83]

Just for information , 

i received that board , and the OS's on the Official website are even crapier than usual .

i tried debian , ubuntu and arch , and everytime the login password root/orangepi fail

 

tested with 3 different 2AMP 5v power supply and 2 SD cards .

[Dimdim]

That's odd, I got my Zero Plus a couple of days ago and had no problem logging in to either debian or arch (official image files) with the usual credentials (root/orangepi or orangepi/orangepi).

 

But I can't wait for a proper Armbian distribution for this board. I ended up using the one for the Orange Pi PC2 for the time being, even though I had to give up on the wi fi connectivity.

[drloop]

Hello everyone,

 

i got my H5 Zero Plus these days and found out that i have two different logins per Ubuntu and Debian, both Desktop images

 

- per tty login the combi root/orangepi worked for me

- per ssh it was orangepi/orangepi

 

sometimes putty/kitty works, sometimes i need to use WinSCP

[tkaiser]

Just created the wiki page for the device: http://linux-sunxi.org/Orange_Pi_Zero_Plus

[tkaiser]

To prepare next steps I booted with vendor OS image once (obviously no tuning at all for this board, it seems that's generic Allwinner H5 BSP stuff already used for Orange Pi PC 2 before, at least this is /boot/orangepi/OrangePiH5orangepi.dtb being decompiled).

 

Performance results here: https://pastebin.com/TZhEPrqs (64-bit kernel 3.10.65, settings limiting cpufreq to 1008 MHz and clocking DRAM at 624 MHz)

 

Then I thought I take FriendlyELEC's Xenial image for their NEO Plus 2 (since same voltage regulation, switching between 1.1V and 1.3V toggled by PL06 pin) but to no avail. IIRC they implement some board detection logic and I ended up with no cpufreq support but running at 816 MHz, DRAM clocked at 672 MHz: https://pastebin.com/8wEaPiUp (quick note wrt iperf3 tests: with Armbian IRQ affinitiy settings numbers improve from 844/922 Mbits/sec to 895/940 Mbits/sec so once we have voltage regulation configured correctly on this board and can exceed 816 MHz cpufreq full GbE saturation will be possible)

 

With BSP kernel and without heatsink this thing idles at 55°C according to sysfs so it now wears a heatsink (and all tests above were made with a fan running in parallel). 

[tkaiser]

And another update. I also tested quickly USB2 performance with Xunlong's NAS Expansion board. I had to update the JMS578 bridge firmware to get USB Attached SCSI working and now (still running with no voltage regulation at boring 816 MHz) it looks like this (still some small room for improvement once we can jump from 816 MHz to 1200 MHz):

With UAS                                                      random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     9759    10091     9672     9771     9783     9505
          102400      16    21267    21244    21282    21333    21332    21266
          102400     512    37297    37676    40738    40983    40983    37589
          102400    1024    37772    37933    40880    41180    41179    37991
          102400   16384    37017    38288    41635    41802    41621    38331

Mass Storage (prior to firmware update)                       random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    10492    10621    10655    10651     9462    10634
          102400      16    19206    21237    21273    21334    21327    21292
          102400     512    36758    36901    37398    37560    37567    36962
          102400    1024    37605    37660    38225    38400    38403    37572
          102400   16384    36389    37763    39923    40071    40085    37839

 

[tkaiser]

Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).

 

So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD

 

       Test             BSP      Armbian

  std memcpy MB/s:     887.9      634.8
  std memset MB/s:    2037.9     1553.0
       7z comp 22:      1288       1234
       7z comp 23:      1344       1279
     7z decomp 22:      3296       3329
     7z decomp 23:      3215       3317
sysbench  648 (s):   14.4798    14.1447
sysbench  816 (s):   11.4151    11.2191
sysbench 1008 (s):    9.2395     9.0787
openssl speed aes:        identical

The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM

 

So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.

[pbezza]

Nice work tkaiser.

[Igor]

And updated wifi driver with fixed MAC address is coming later on to beta repository. 

[tkaiser]

Another update since I think we're running partially in a wrong direction. Last year we discovered that the small H3 boards with single bank DRAM configuration like NanoPi NEO or OPi Zero showed pretty low memory bandwidth and a tendency to overheat when DRAM has been clocked higher (especially there was a huge consumption/temperature jump when switching from 408MHz DRAM clock to 432MHz) and overall idle consumption on a NanoPi NEO variied by 470 mW only depending on DRAM frequency (comparing 132 MHz with 624 MHz back then).

 

That's why we set DRAM clockspeed to 408 MHz by default on the small Allwinner boards. Since I can't remember that we verified that with a H5 board yet I simply gave it a try and compared idle temperature of OPi Zero Plus with 408 MHz DRAM clock vs. 624 MHz: Less than 2°C difference. That's nothing. So I tested again with 624 MHz DRAM clock (but with Debian Stretch so forget about comparing sysbench results with anything above since different compiler --> different results): https://pastebin.com/4iM6DwJM

 

Memory bandwidth is a lot better of course and if we compare with H3 boards below we see that even single bank DRAM configs with H5's memory controller outperform the H3 numbers (the inner numbers are 32-bit memory configs and the outer 16-bit, it's the 'standard memcpy' value shown):

DRAM clock     NanoPi NEO      OPi Lite   OPi Plus 2E   OPi Zero Plus
408 MHz:       433.5 MB/s    594.8 MB/s    580.5 MB/s    634.8 MB/s
624 MHz:       484.8 MB/s    892.9 MB/s    905.5 MB/s    875.1 MB/s

Can users with access to other H5 devices please provide tinymembench numbers? Especially interested in OPI PC2 or Prime and NanoPi NEO2 or Plus2. It's as easy as

git clone https://github.com/ssvb/tinymembench
cd tinymembench/
make
./tinymembench

 

[willmore]

PC2: http://sprunge.us/jVAH

[tkaiser]

Ok, switching from 408 MHz DRAM clock to 624 MHz on OPi Zero Plus (still cpufreq limited since DVFS not working, I'm running at 1008 MHz but can consider myself lucky since we've seen H5 boards that get instable at 1008 MHz with 1.1V VDD_CPUX for sure):

       Test             BSP    Armbian old   Armbian new

  std memcpy MB/s:     887.9       634.8        875.1
  std memset MB/s:    2037.9      1553.0       2252.7
       7z comp 22:      1288        1234         1515
       7z comp 23:      1344        1279         1637
     7z decomp 22:      3296        3329         3832
     7z decomp 23:      3215        3317         3768
sysbench  648 (s):   14.4798     14.1447      14.1378
sysbench  816 (s):   11.4151     11.2191      11.1106
sysbench 1008 (s):    9.2395      9.0787       8.9818
openssl speed aes:           almost identical

So once DVFS is working there will be another slight performance increase in a few weeks.

[guidol]

2 hours ago, tkaiser said:

Can users with access to other H5 devices please provide tinymembench numbers? Especially interested in OPI PC2 or Prime and NanoPi NEO2 or Plus2. It's as easy as

 

@tkaiser NanoPi Neo2 with debian stretch:

Linux nanopineo22 4.13.13-sunxi64 #214 SMP Thu Nov 16 01:52:21 CET 2017 aarch64 GNU/Linux
as attachment

 

NanoPi_Neo2_tinymembench.txt

[tkaiser]

1 hour ago, guidol said:

NanoPi_Neo2_tinymembench.txt

Thank you. Same numbers as with OPi Zero Plus at 408 MHz. I just prepared an u-boot variant that clocks DRAM with 672 MHz to let the OPi Zero run overnight memtester and tinymembench in parallel (I checked it at 624 MHz before with both mainline and BSP for at least half an hour and no memory corruption reported). Maybe you can give it a try too on a spare SD card? It's just installing with 'dpkg -i' and rebooting.

 

 

[guidol]

3 minutes ago, tkaiser said:

Maybe you can give it a try too on a spare SD card? It's just installing with 'dpkg -i' and rebooting.

My 2 NanoPi Neo are in the screwed NAS-Cases  They should have the case designed to swicth/remove the uSD...

but even when the case is open and the pcb out of the case you need a tweezer to get the uSD out

And the screws wouldnt be better with every open/close....

 

Is there a way to undo the .deb - so that I can test without opening the case?
I think about 2 .deb one to install the new u-boot and one to get the old one back until the faster one is tested as "stable" 

[tkaiser]

5 minutes ago, guidol said:

Is there a way to undo the .deb - so that I can test without opening the case?

Sure. Since I assume you're also running a 'nightly' here are the official u-boot debs (using 408 MHz): https://beta.armbian.com/pool/main/l/linux-u-boot-nanopineo2-next/

 

And here at the bottom are variants with 624 MHz and 672 MHz but testing is only useful with the latter since there's some safety headroom needed (so if 672 MHz works then choosing 624 MHz for productive usage would be an idea). But please be aware that this is reliability testing and crashes/freezes are to be expected if we're talking about worst case here. I've now two scripts running in parallel, the one for tinymembench looking like this:

root@orangepizeroplus:~/tinymembench# cat tinymembench.sh 
#!/bin/bash
while true ; do
	./tinymembench
done

 

[guidol]

1 hour ago, tkaiser said:

And here at the bottom are variants with 624 MHz and 672 MHz but testing is only useful with the latter since there's some safety headroom needed (so if 672 MHz works then choosing 624 MHz for productive usage would be an idea). But please be aware that this is reliability testing and crashes/freezes are to be expected if we're talking about worst case here.

Hmm  I installed the 672Mhz-orangepizeropluversion with --force-all on my NanoPi Neo2 - now after reboot he didnt get up anymore to ssh in

Now I have to unscrew the NAS... 

root@nanopineo22:/home/guido/uboot_test# dpkg --force-all -i ./linux-u-boot-next-orangepizeroplus_5.34_672mhz_arm64.deb
dpkg: regarding .../linux-u-boot-next-orangepizeroplus_5.34_672mhz_arm64.deb containing linux-u-boot-orangepizeroplus-next:
 linux-u-boot-nanopineo2-next conflicts with armbian-u-boot
  linux-u-boot-orangepizeroplus-next provides armbian-u-boot and is to be installed.

dpkg: warning: ignoring conflict, may proceed anyway!
dpkg: regarding .../linux-u-boot-next-orangepizeroplus_5.34_672mhz_arm64.deb containing linux-u-boot-orangepizeroplus-next:
 linux-u-boot-orangepizeroplus-next conflicts with armbian-u-boot
  linux-u-boot-nanopineo2-next provides armbian-u-boot and is present and installed.

dpkg: warning: ignoring conflict, may proceed anyway!
(Reading database ... 35468 files and directories currently installed.)
Preparing to unpack .../linux-u-boot-next-orangepizeroplus_5.34_672mhz_arm64.deb ...
Unpacking linux-u-boot-orangepizeroplus-next (5.34) ...
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/lib/u-boot/LICENSE', which is also in package linux-u-boot-nanopineo2-next 5.34.171118
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/lib/u-boot/platform_install.sh', which is also in package linux-u-boot-nanopineo2-next 5.34.171118
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/lib/u-boot/LICENSE.atf', which is also in package linux-u-boot-nanopineo2-next 5.34.171118
Setting up linux-u-boot-orangepizeroplus-next (5.34) ...
Updating u-boot on /dev/mmcblk0
root@nanopineo22:/home/guido/uboot_test# reboot

[EDIT] because I didnt know how to roll that back: I reinstalled the NanoPi Neo2 
45 minutes with Standard-Installation and some reconfiguration... I think I have to create a Checklist for installing
Music and NAS is running again.

[tkaiser]

12 hours ago, guidol said:

I installed the 672Mhz-orangepizeropluversion with --force-all on my NanoPi Neo2 - now after reboot he didnt get up anymore

 

My bad. I totally overlooked that the above u-boot version requires an OS image with DT for Orange Pi Zero Plus already present (and that's only the case on self-built images or latest nightlies built yesterday or later). Sorry for the hassles!

 

@willmore In case you want to give it a try then please only try it out based on this nightly. Test scenario with 672 MHz DRAM clock is to run endlessly tinymembench and memtester in parallel (works here since 12 hours without problems, I'll later add a pillow to the setup just as I did yesterday when running the same stuff with BSP to ensure SoC and DRAM temperatures are 95°C or above).

[Piv Klit]

Orange PI Zero Plus2

orange pi zero plus2.txt

[tkaiser]

24 minutes ago, DEHN.IO said:

Orange PI Zero Plus2

orange pi zero plus2.txt

 

Can you please provide output from 'armbianmonitor -u' too? Just to be sure since it looks like your DRAM is clocked with 672 MHz and we added a slight downclock 2.5 weeks ago (most probably only part of the beta repository yet).

[Piv Klit]

Edit: it´s = Welcome to ARMBIAN 5.34.171119 nightly Ubuntu 16.04.3 LTS 4.13.13-sunxi64, not 5.34.171117

http://sprunge.us/VAaN

[tkaiser]

12 minutes ago, DEHN.IO said:

ARMBIAN 5.34.171117 nightly Debian GNU/Linux 9 (stretch) 4.13.13-sunxi64   

http://sprunge.us/VAaN

 

Strange. The output neither reflects 'DEFAULT_OVERLAYS="usbhost2 usbhost3"' set in the meantime, nor DRAM being clocked down to 624 MHz and there's also 'nand-sata-install.log: Thu Oct 12 10:03:09 UTC 2017: Start nand-sata-install.' included.

 

O, wait. I just tried it again on my OPi Zero Plus now that cpufreq scaling is back (that happened yesterday after some updates after a reboot and now after new updates + reboot everything is back again) and now tinymembench shows with 672MHz:

 standard memcpy                                      :    925.3 MB/s (0.6%)
 standard memset                                      :   2564.2 MB/s

Ok, looking at tinymembench numbers is useless if we not also know cpufreq settings when the test was running...

 

 

[Piv Klit]

Actually the sytem is ARMBIAN 5.34.171119 nightly Ubuntu 16.04.3 LTS 4.13.13-sunxi64. my mistake

Are there any other test I should run ?

[tkaiser]

27 minutes ago, DEHN.IO said:

my mistake

 

Doesn't matter, that's what the '### Installed packages' entry is for

 

27 minutes ago, DEHN.IO said:

Are there any other test I should run ?

Since I don't understand what's happening on your installation I don't think so. You're running off eMMC, there's no SD card present, the boot environment doesn't look right and there's an older nand-sata-install.log lying around. I would need to understand this first...

[tkaiser]

6 hours ago, tkaiser said:

I'll later add a pillow to the setup just as I did yesterday when running the same stuff with BSP to ensure SoC and DRAM temperatures are 95°C or above).

 

Ok, that was most probably not the best idea. I set up a monitoring script running in a screen/SSH session and that ended like this after 3 hours testing below a pillow:

ok 91.5°C
ok 90.3°C
ok 91.4°C
ok 92.4°C
ok 92.4°C
ok 90.6°C
ok 92.3°C
ok 90.9°C
ok 92.2°C
ok 91.8°C
ok 92.6°C
ok 91.6°C
ok 93.0°C
ok 93.4°C

(parsing memtester's nohup.out for 'fail' and reporting SoC temp every 3 minutes). Then reporting stopped, I burned my fingers (since I forgot that I cooked the whole setup, NAS Expansion board I power Zero Plus through included), then I had to realize that the SD card died

 

Anyway: This ran since yesterday at 672 MHz without memtester reporting memory corruption, any objections to use 624 MHz now for OPi Zero Plus and also NEO2 and NEO Plus2?

 

@zador.blood.stained: you set DRAM clockspeed for OPi PC 2 and Prime to 648 MHz. @Icenowy IIRC yesterday reported in linux-sunxi IRC that she had problems at this clockspeed and needed to go a little lower. Should we use 624 MHz here too?

[zador.blood.stained]

35 minutes ago, tkaiser said:

@zador.blood.stained: you set DRAM clockspeed for OPi PC 2 and Prime to 648 MHz. @Icenowy IIRC yesterday reported in linux-sunxi IRC that she had problems at this clockspeed and needed to go a little lower. Should we use 624 MHz here too?

If we notice any strange issues (data aborts mostly since they are obvious in dmesg) then we should lower it, but in the IRC log I see that 672 is bad and 624 is good so I would like to bisect this further . Again, if we want to force some fixes upstream we should do a more definitive test on several boards.

[tkaiser]

5 minutes ago, zador.blood.stained said:

If we notice any strange issues (data aborts mostly since they are obvious in dmesg) then we should lower it

 

Why are we trying to use 672 or 648 MHz in the first place? Since there's somewhere a value in a 3.10 DT or sys_config.fex that gets ignored by BSP anyway?

 

6 minutes ago, zador.blood.stained said:

but in the IRC log I see that 672 is bad and 624 is good so I would like to bisect this further

 

Hmm... https://irclog.whitequark.org/linux-sunxi/2017-11-17#20573274; -- I can only see that 672 is bad, while 576 and 624 are good. But most probably I missed something...

 

7 minutes ago, zador.blood.stained said:

if we want to force some fixes upstream

 

I don't want to force any fixes upstream since IMO that's just a waste of time. The submitted numbers there are the result of copy&paste gone wrong and no one cares. We wasted one and a half year ago an insane amount of time to test through these issues and it should be common sense that 672 MHz are not reliable. This testing doesn't happen 'upstream' (the only time it happened the results were easy to interpret: stay away from 672 MHz since it will cause issues on some boards) and submitters prefer 'performance' over reliability.