kris777 Posted August 13, 2017 Posted August 13, 2017 Orange Pi Zero Plus (H5 / 1000M ethernet ) Is a working Armbian system ? ..... It's probably new :-)
chwe Posted August 13, 2017 Posted August 13, 2017 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 Posted August 13, 2017 Posted August 13, 2017 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). 1
fabieng83 Posted August 28, 2017 Posted August 28, 2017 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 Posted September 9, 2017 Posted September 9, 2017 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 Posted November 10, 2017 Posted November 10, 2017 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 Posted November 15, 2017 Posted November 15, 2017 Just created the wiki page for the device: http://linux-sunxi.org/Orange_Pi_Zero_Plus 1
tkaiser Posted November 15, 2017 Posted November 15, 2017 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). 1
tkaiser Posted November 15, 2017 Posted November 15, 2017 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 Posted November 16, 2017 Posted November 16, 2017 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. 4
Igor Posted November 17, 2017 Posted November 17, 2017 And updated wifi driver with fixed MAC address is coming later on to beta repository. 3
tkaiser Posted November 17, 2017 Posted November 17, 2017 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
tkaiser Posted November 17, 2017 Posted November 17, 2017 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. 1
guidol Posted November 17, 2017 Posted November 17, 2017 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 2
tkaiser Posted November 17, 2017 Posted November 17, 2017 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 Posted November 17, 2017 Posted November 17, 2017 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 Posted November 17, 2017 Posted November 17, 2017 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 Posted November 17, 2017 Posted November 17, 2017 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. 1
tkaiser Posted November 18, 2017 Posted November 18, 2017 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 Posted November 18, 2017 Posted November 18, 2017 Orange PI Zero Plus2orange pi zero plus2.txt
tkaiser Posted November 18, 2017 Posted November 18, 2017 24 minutes ago, DEHN.IO said: Orange PI Zero Plus2orange 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 Posted November 18, 2017 Posted November 18, 2017 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 Posted November 18, 2017 Posted November 18, 2017 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 Posted November 18, 2017 Posted November 18, 2017 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 Posted November 18, 2017 Posted November 18, 2017 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... 1
tkaiser Posted November 18, 2017 Posted November 18, 2017 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 Posted November 18, 2017 Posted November 18, 2017 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 Posted November 18, 2017 Posted November 18, 2017 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.
Recommended Posts