NanoPi NEO is a cool little board, and I’ve been using it with Armbian as a 24/7 MQTT + Domoticz server for several weeks without any issues so far. FriendlyElec has now an update with NanoPi NEO2 featuring Allwinner H5 quad core Cortex A53 processor instead of Allwinner H3 Cortex A7 processor, a faster Gigabit Ethernet connection, and a new audio header.
NanoPi NEO2 specifications:
- SoC – Allwinner H5 quad core Cortex A53 processor with an ARM Mali-450MP GPU
- System Memory – 512 MB DDR3
- Storage – micro SD card slot
- Connectivity – Gigabit Ethernet (via RTL8211E-VB-CG chip)
- USB – 1x USB 2.0 host ports, 1x micro USB OTG port, 2x USB via headers
- Expansion headers
- 24-pin header with I2C, 2x UART, SPI, PWM, and power signals
- 12-pin header with 2x USB, IR pin, I2S
- 5-pin audio header with microphone and LINE out signals
- Debugging – 4-pin header for serial console
- Misc – Power and status LEDs
- Power Supply – 5V via micro USB port or VDD pin on headers.
- Dimensions – 40 x 40 mm
One of my reader (Willy) also noticed they included a low-profile Ethernet jack that was asked by some. The company provides an image based on U-boot + Ubuntu Core, as well as hardware and software documentation on their Wiki. That’s not the first Allwinner H5 board we’ve seen, as Shenzhen Xunlong introduced Orange Pi PC 2 at the end of last year, but NEO2 is the first H5 board in such as small form factor.
Software support for H5 was not quite that good last November, but now Armbian community has released nightly builds for Orange Pi PC 2 based on Linux 4.10, which do seem to work fine for headless operation, but there’s little hope to have Mali drivers, hardware video decoding, and HDMI audio output support any time soon. None of those should matter for NanoPi NEO2 since it does not come with any video output ports, and I’d expect Armbian images to be released for the board soon.
NanoPi NEO2 is sold for $14.99 + shipping together with 2×12 and 1×12 headers directly on FriendlyARM website. Note that the heatsink is not included by default, and depending on your target application you may want to spend the extra $2.97 to add the heatsink + thermal pad to your order.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
the same with onboard emmc will be perfect
(i know there is NEO AIR, but without ethernet)
Ah, with GigE, with Armbian, and a good Wiki-page. Nice!
I checked, and shipping to the Netherlands is 5 USD (China Post-Group 3)
Wonder if it stays pin compatible with the NanoPi Power dock and Uno dock. I know from email with NanoPi they are aware of need to improve software.
Quick comparison with Orange Pi PC2: 1368 MHz cpufreq vs 1008 MHz, less memory bandwidth due to single bank configuration here.
More details: https://forum.armbian.com/index.php?/topic/3576-nanopi-neo-2/&do=findComment&comment=27536
@cnxsoft: ‘hardware video decoding’ shouldn’t be a problem since the video engine in H5 is compatible to the older SoCs. This is just a matter of ‘someone has to spend some time to do the work’. Since H3 and H5 are pin compatible I would assume we see a lot of ‘board upgrades’ soon. Adding software support for these new boards is pretty easy now that awesome linux-sunxi community did all the relevant work already (dealing with early stage boot loaders, ARM trusted firmware and porting H3 drivers to H5).
BTW: Armbian images for H5 devices currently only support mainline kernel (4.10 at the moment) while vendor OS offerings from both Xunlong or FriendlyELEC are based on Allwinner’s smelly BSP (3.10.65 kernel and broken DVFS, maybe that’s the reason FriendlyELEC decided to forget about any voltage regulation on this board since in Allwinner’s outdated kernel voltage switching doesn’t work anyway — funnily community’s mainline kernel drivers do work here, though only on boards with adjustable voltage regulator like OPi PC2)
@tkaiser
I used the info on OpI PC2 on Armbian website:
So I guess than means the first one should be feasible, but the last two are harder ?
@Sander
Unfortunately they don’t include a Micro USB cable in this set unlike with a few other NanoPi. So it’s strongly recommended to add the $2 for one of FriendlyELEC’s cables since they have a very low resistance and you don’t risk powering/undervoltage problems (though as usual NanoPis can also be powered through the 4 pin ‘debug header’)
@cnxsoft
Well, ‘will not be fixed anytime soon’ just means that people shouldn’t ask for it. Unfortunately most of the few active Armbian devs aren’t that interested in display/audio stuff so we need to wait until upstream kernel devs add drivers (eg HDMI audio) to be integrated. But there is some progress eg. OPi PC2 has working HDMI display output (though simplefb and not accelerated by any means). Regarding video decoding with mainline kernel last year Free Electrons’ Florent Revest demonstrated that Cedrus is useable together with kernel 4.8 so I would assume it’s just a matter of time until this will work here too.
And IIRC situation with Mali seems also to be better since for Mali450 there seem to be useable BLOBs for aarch64 around (but I might remember totally wrong, 3D acceleration is something I normally ignore). Time will tell.
Regarding Armbian OS images for NEO2: 20 minutes ago I commited a small change limiting max cpufreq here to 1008 MHz and setting CLI_BETA_TARGET=”xenial:dev” — so if everything works correctly in a few hours a directory called nanopineo2 will appear automagically on dl.armbian.com with an Ubuntu Xenial image using kernel 4.10 and u-boot 2017.03 (‘nightly build’ and as such 100% untested 😉 )
@tkaiser
The difference between H3 & H5 is H5’s VDD-CPUS, VDD-CPUX are marked TBD(To Be Decided), Please refer to the chapter 5.2 in H5 datasheet. We assumed Allwinner H5 dont’ support adjustable voltage.
Did you guys noticed that this thing has no HDMI and possibly headless, too?
@Mindee
Hmm, when looking at pages 682 and 683 we’re talking about same ratings as for H3 (1.5V absolute maximum, 1.4V max recommended). TBD (‘to be done’ in my understanding) appears on page 685 when it’s about ‘Maximum Current Consumption’, something Allwinner obviously not yet measured/provided?
Anyway with Allwinner’s legacy kernel voltage regulation is broken with H5 (it seems the relevant Github issue has been deleted by the guy doing software for Xunlong) but we as community did some testing with H5 on OPi PC2 using the I2C accessible SY8106A voltage regulator. It obviously works since @ErwinH managed to reach even stable 1368MHz@1.4V with appropriate cooling.
To be honest: the fixed 1.1V on your NEO2 are IMO not a real disadvantage especially given that you don’t add a Micro USB cable to the NEO2 kit (maybe you should overthink that since undervolting NEO2 due to average/crappy cables could be an issue for many users)
@Mindee
BTW: github.com/friendlyarm/h5_lichee.git is still empty and I did not manage to download h5-lichee-20170307.7z from your Baidu share. Can you please fix that?
@Mindee
Thats a bold assumption, given how PC2 has voltage regulation.
Well, CNX wrote “None of those should matter for NanoPi NEO2 since it does not come with any video output ports” … so, yes, I had noticed that… 😉
Only with community developed mainline kernel (simply applying Ondrej’s patches for H3 devices from last year to H5 kernel branch) and not Allwinner’s own BSP kernel 😉
Found it again in the meantime: https://github.com/OrangePiLibra/OrangePi_H5SDK/issues/6#issuecomment-267737736
GPU indeed won’t matter (for this board, but not other H5 boards), but VPU might matter – e.g. if you wanna do a media server with transcoding, or add a webcam (usb or ip) and encode the stream.
PS: mali drivers are very easy to add, assuming you have a binary blob that works with the board (e.g. the hikey driver from malideveloper website, or if sunxi has a binary driver from the older kernel, it would work here too).
@tkaiser
The github source will be available within about 24 hours or earlier.
Thank you.
I really find this one interesting for a lot of headless stuff. Based on my observations on Opi-PC2 I expect it not to heat much, and in the end having a very small, inexpensive, low-power 64-bit board with gigabit support is very interesting for a lot of use cases in network monitoring, testing as well as to place single-function devices on a home network (DNS+DHCP server, USB NAS, VPN end point, proxy, reverse proxy, etc). For this price you can have a lot. You can easily connect this to a cheap manageable 5-port switch and have a 4-port gigabit firewall as well once you enable VLANs. So there’s a lot of potential in this tiny board which comes with a nice balance of features, size and cost. I really like it and I think it will soon replace my aging dockstars since it has 4 times the amount of RAM and of cores.
@Willy
Agree with most of your comments but not regarding thermal expectations. Xunlong’s OPi PC2 is just another great example for a PCB design where the ground plane acts like a gigantic bottom heatsink. Not possible on smaller boards like NanoPi NEO/Air or also OPi Zero. So expect higher temperatures here but fortunately max cpufreq on NEO2 is limited to 1008 MHz anway so heat won’t be that much of an issue even under full load. For headless operations max cpufreq of 1008 MHz vs 1368 MHz doesn’t matter at all (but lower memory bandwidth partially for some use cases).
BTW: this NEO2 is IMO currently the best companion for Xunlong’s NAS Expansion board even if pin header positions don’t fit and small wires are necessary to combine both designs. The ‘NAS HAT’ uses 2 JMS578 USB-to-SATA bridges that are superiour compared to the average bridge used in USB enclosures since it supports:
– UAS: http://linux-sunxi.org/USB/UAS
– SAT/SMART: https://en.wikipedia.org/wiki/SCSI_/_ATA_Translation
– even TRIM https://en.wikipedia.org/wiki/Trim_(computing)
@Willy
Quick addendum regarding generated heat since related with consumption. When linux-sunxi community developed sane DVFS settings for H5 (OPi PC 2 in this case) we again used an optimized Linpack benchmark to do stability testing. This version using NEON optimizations was already helpful with A64 and H3 before. It generates a pretty heavy load on the SoC and throws errors when the CPU cores are fed with a voltage too low.
One Armbian user now measured consumption in this mode walking through all available cpufreq steps: https://forum.armbian.com/index.php?/topic/1748-sbc-consumptionperformance-comparisons/&do=findComment&comment=27583
So at 1008 MHz it’s ~2.3W above idle consumption while at 1368 MHz it’s already 6.1W above. From this point of view feeding H5 on NEO2 with 1.1V max makes a lot of sense given the limited situation with heat dissipation. And for headless use cases the theoretical performance difference between 1.0 and 1.36 GHz is simply negligible.
If Allwinner is interested in that market they should really start making processors for headless applications without display interfaces, VPU or GPU, and just the processor, USB, and I/Os, and some versions with Ethernet and/or SATA.
@memeka
In fact in github.com/OrangePiLibra/OrangePi_GPU is Mali450 stuff lying around that could work from a technical point of view with Allwinner’s smelly 3.10 kernel but lacks a proper (any to be more precise) license so you end up with distribution issues and no one right in his mind will touch BSP code base anyway (in mainline kernel Mali integration makes not that much sense today since underlying prerequisits are still WiP, all we have there now are simplefb display drivers).
@cnxsoft
IMO kinda useless to speculate about Allwinner’s motivation/goals, especially here 🙂
But it’s obvious that they simple re-use IP blocks in various SoCs, as @memeka pointed out VPU (video engine) support could be crucial even on headless designs since Cedrus supports both HW accelerated video decoding and encoding and in general being not that innovative is sometimes ‘key to success’. Take the newest ‘Foundation innovation’ RPi Zero W for example: the SoC used on all Raspberries up to RPi 3 (VideoCore IV) is a 2011 design, the specific CPU core (ARM1176JZ) is from 2003. What’s the result? Mature software support in the meantime. Same with Nextthing’s CHIP based on A13 (R8): by choosing an old hardware design they ran in less software issues.
Anyway: I doubt Allwinner could ship cheaper ‘special purpose’ SoCs when re-designing them (and IMO with Allwinner it’s all about cheap), it also doesn’t hurt that much to ignore/deactivate specific SoC engines and to be honest: the reason why we’re already able to run latest mainline kernel on H5 boards is just that Allwinner fortunately re-used IP blocks from both H3 and A64 here.
Friendlyelec may surprise a few Nas lovers yet ! 😉
@Theguyuk
Well for people able to browse through the commit history of github repos and lookup config bits here and there… there are no surprises any more since approx 2 hours. From a software point of view (mainline kernel+u-boot) it looks easy now that kind souls from linux-sunxi community also added eMMC support upstream (though for A64 and not H5 — IIRC there’s a difference regarding the 2nd MMC controller on A64, no idea whether that applies to H5 too).
Anyway: since community did the job already ‘board upgrades’ from H3 to H5 aren’t that much of an issue any more and there’s no need to fiddle around with Allwinner’s BSP (and especially buggy/insecure 3.10.65 kernel)
@cnxsoft
Headless SOCs
A smarter way to do that is to leave in the 2D video hardware which costs almost nothing, but then add more peripherals which share the display pins. Most NXP chips do this. If you use them in a headless system you gets another dozen peripherals or you can hook up a LCD panel. Doing it this way makes the SOC support more use cases. I’ve asked AW to do this without any success.
AW does need to get with current times and start including USB3.
One neat side effect of sharing the display pins is that you can put a FPC connector on the PCB. Then either plug a display into it, or stack an expansion board with peripherals on it and use an FPC cable to access the expanded peripherals.
@tkaiser
Hi Tkaiser
If you like helping others with software and not to only interested in OrangePi . Then maybe, only maybe! a polite email conversation with Friendlyelec might be worthwhile. I cannot comment beyond that , It is not my place or liberty to do so.
@Theguyuk
LOL, care to remember that it was Thebragger who divulged products he shouldn’t talk about? http://www.cnx-software.com/2017/03/01/friendlyelec-nanopi-m1-plus-allwinner-h3-board-adds-gigabit-ethernet-wifi-bluetooth-and-an-8gb-emmc-flash/#comment-539721
FriendlyELEC and us (linux-sunxi and Armbian community) are constantly in contact via email and github issues, they send out developer samples and listen to suggestions. The last 4 officially announced FriendlyELEC boards were fully supported by Armbian weeks before dev samples arrived and I hope this will remain the same in the future 🙂
@Jon Smirl
But isn’t that exactly what LicheePi Zero for example is doing? 40 pin FPC connector you can either attach a display to or various add-on boards?
@tkaiser
Did they finally do this with the V3S? I don’t work with it. It is a good scheme, it costs almost nothing to implement and they should do it for all of their chips.
For example it would be nice to take mass produced tablet PCBs and use them without displays. The FPC would then give access to SPI, I2S, I2C, etc.
@tkaiser
Lol Hi tkaiser
Your assumption is wrong, the board I spoke of was openly disclose by FriendlyElec in a forum. Hence how I knew of it. No underhand at all. 🙂
I checked data sheet (from Nov 2014 so it’s an old design anyway) and nope, I was wrong. LCD is 24 pins and just a few of them are multiplexed so developer Zepan simply added other signals to the 40 pin connector 🙂
Anyway: NanoPi NEO2 is now officially latest member in Armbian family: https://www.armbian.com/download/
@tkaiser
That’s even more true considering the limited RAM bandwidth 🙂
Wow, that’s cool.
Is that a 64-bit Linux?
@myself: the nightly Armbian for this board is 64-bit indeed … wow.
usr/bin/perl: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=98dedd8770d6a5a002221bd42c0af6aa77c9fa89, stripped
@tkaiser
“We are not that crazy like eg. SinoVoip”
Yes, you are, when you’re mixing armhf with arm64 you know you are downgrading performance, right?
Huh? It’s an arm64 userland with the ability to install armhf packages (Debian’s Multiarch feature available since Wheezy). While firefox:arm64 is constantly crashing firefox:armhf runs flawlessly. Which one is performing better? Or do you claim that once I execute ‘dpkg –add-architecture armhf’ the whole arm64 OS installation slows down?!
Regarding the SinoVoip example that’s totally different: They have a 64-bit ARMv8 board but provide OS images relying on a 32-bit ARMv6+VFP userland (‘armhf lite’ or something like that, compiler switches suitable for an ARM CPU generation from 15 years ago!)
@JotaMG
Found it: https://forum.armbian.com/index.php?/topic/751-rfc-support-cortex-a53arm64/&do=findComment&comment=12462
Running stupid sysbench pseudo CPU benchmark with compiler settings for ARMv6+VFP with GCC 4.9 results in 52.2640s execution time while the same hardware with same settings and same benchmark just compiled for ARMv8 with GCC 5.4 results in 3.2562s. That’s just 16 times faster by allowing software to make use of modern CPU features! And you get that for free just by taking care of the userland you provide (now imagine RPi 3 being not limited to Raspbian’s ARMv6 packages: would finish this sysbench stuff in less than 3 seconds).
BTW: No idea which userland FriendlyELEC uses with their NEO2 Ubuntu images. If it’s their usual rootfs then it’s 32-bit/armhf/ARMv7 ‘optimized’ and will run a bit slower/inefficient on ARMv8 H5 (sysbench is a really bad example since this pseudo CPU benchmark does only prime number calculations and this can be done with ARMv8 compiler switches magnitudes faster)
I am definitely going to have to pick up some of these and the NAS add-on boards for testing. I keep saying 512MB of RAM is an issue but is it really? It’s certainly less than optimal and will need some settings tweaking but will it work and more importantly will it work better than the old x86 server I keep kicking around where the NIC’s the bottleneck?
OK, OK … I’ve ordered one.
I don’t think I really need one, but ARM64 ánd GigE ánd Linux mainline ánd Armbian … that’s just perfect.
Well, if storage is the bottleneck (USB2 Hi-Speed without RAID definitely is) then you get higher ‘client to NAS’ write speeds as long as the amount of data fits into RAM before it gets flushed to disk. With only 512MB DRAM files as large as ~350MB might be saved with ~80MB/s and later it drops down to storage speed (~40MB/s with good USB-to-SATA bridge), with 2GB DRAM you might be able to store up to 1.8GB with 80MB/s.
As soon as many small files are involved it doesn’t matter that much and read speeds usually aren’t affected since the data has to be fetched from storage anyway so this is always the bottleneck except when the data has been stored moments before and is still present in filesystem buffers/caches (that’s what DRAM is used mostly for on headless systems).
One exception would be the use of performant RAID modes, H3 is personally tested with +120MB/s using RAID-0 and 3 SSD, with H5 it will be the same and another nice feature of these cheap Allwinner chips is that we’ll soon be able to transform the OTG port into a real USB host port since on these SoC’s USB PHY0 is connected to two different real USB controllers, by default connected to musb (OTG and ‘host emulation’ mode) but by changing a register it can also be routed to an own 4th EHCI/OHCI controller pair (do a google search for ‘Add dual-role OTG support for Allwinner H3’ and ‘Icenowy’ for details).
USB RAID sounds as stupid as it normally is but we use some small GbE equipped boards at some clients with 3 USB thumb drives each combining mdraid10 with btrfs RAID 0 providing ~110GB storage each at NAS read speeds of ~75MB/s outperforming the big NAS boxes they replaced (syncing graphics stuff to homeworkers or remote studios in a more intelligent way)
@tkaiser
I’m an idiot, forgot to mention this is for Ceph, you might remember me from my interest in the OPi+2E (and subsequent trouble as redhat dropped armhf support, they provide armv8 packages only). Ultimately I had disappointing performance from my old x86 box (top speed of 30-40MB/s) but couldn’t nail down the cause due to all the layers. I’m hoping multiple simpler boxes will be easier to trouble shoot, like latency’s a killer for Ceph and I had 4 cores trying to handle 8 heavy threads with plenty of IO through a single RAID card. Should be better with 4 cores and 1 controller for 1 drive.
That x86 box had 48GB of RAM so you’d expect writes to have been better but nope.
@CampGareth
While I still wouldn’t implement storage clusters on nodes without ECC DRAM (just due to having a lot of servers in our monitoring system and many of them report recoverable single bit errors from time to time — without ECC you get just data corruption you’ll realize way too late or a crash from time to time) your Ceph approach looks like a great way to teach yourself active benchmarking skills (just do a web search for ‘active benchmarking’ and the name of one of my personal heroes: ‘Brendan Gregg’)
Just because i still didnt get a clue how far support for h5 now really is after reading here and over at the armbian forum…
If id like to buy a board now for generic tinkering and maybe to also play with libreelec (not the main purpose) would you recommend an H3 or an H5 based board?
Thanks for suggestions!
@itchy n scratchy
Easy, most H3 mainline patches could be re-used with H5 so support with mainline kernel is advanced (though forget about camera and display stuff — @jernej wrote an HDMI driver for u-boot so now basic display output is there with kernel 4.10 or above but nothing useable together with any sort of video/graphics acceleration). I doubt anyone from community will ever touch Allwinner’s H5 BSP so with H5 you’re stuck with vendor OS images (ask Xunlong or FriendlyELEC or maybe even those crazy Bananas) or mainline kernel with Armbian at the moment.
In other words: the older the SoC, the better the support and OpenELEC is currently only available for H3 devices thanks to @jernej again.
Related news: soon there will be a NEO Plus 2 available: https://forum.armbian.com/index.php?/topic/3576-nanopi-neo-2/#comment-28100
And there also will be a ‘NanoPi M1 Plus 2’ (H3 exchanged with H5, everything else the same). FriendlyELEC told us today that it’s ok to spread the news in the meantime.
@tkaiser thanks for explanations.
Maybe i better forget about h3/5 for anything else than electronics tinkering with mainline. Else maybe a CHIP with cedrus for further experimentation 🙂 or ill stay with my lame foundation controlled rpi3.
I’ve received the NanoPi Neo2 today, and … what a beautiful package. And the Neo2 is very, very small.
NanoPi NEO 2 kit with metal enclosure and OLED display -> http://www.friendlyarm.com/index.php?route=product/product&path=85&product_id=189
@cnxsoft
Wow awesome stuff!
@cnxsoft
Result of ‘metal enclosure and OLED display’: 2 USB host ports not useable and none of the GPIO pins can be used. What’s the use case for such an expensive thing?
Still hoping for a rev 2 NAS board for NEO2 that makes use of the OLED display, the buttons, improved heat dissipation (if the case is made of aluminium then use a copper shim to connect H5 to the case) and a power design that allows the use of 2.5″ and 3.5″ disks (it’s just providing 12V on three pins of the SATA power port)
Friendlyelec are listing a NEO2 Complete Starter Kit in their latest products, but not sure why.
The 1GB model is sold out, and the kit uses the aluminum case as heatsink.
https://www.friendlyarm.com/index.php?route=product/product&product_id=189