NanoPi NEO2 Development Board Powered by Allwinner H5 64-bit ARM Processor Sells for $15

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.

Support CNX Software - Donate via PayPal or become a Patron on Patreon
Subscribe
Notify of
guest
49 Comments
oldest
newest most voted
Youcef
Youcef
3 years ago

the same with onboard emmc will be perfect
(i know there is NEO AIR, but without ethernet)

Sander
Sander
3 years ago

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)

Theguyuk
Theguyuk
3 years ago

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.

tkaiser
tkaiser
3 years ago

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 @Jean-Luc Aufranc (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… Read more »

tkaiser
tkaiser
3 years ago

@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’) @Jean-Luc Aufranc (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… Read more »

Mindee
Mindee
3 years ago

@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.

dxin
dxin
3 years ago

Did you guys noticed that this thing has no HDMI and possibly headless, too?

tkaiser
tkaiser
3 years ago

@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… Read more »

tkaiser
tkaiser
3 years ago

@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?

Benjamin
3 years ago

@Mindee
Thats a bold assumption, given how PC2 has voltage regulation.

Sander
Sander
3 years ago

dxin :
Did you guys noticed that this thing has no HDMI and possibly headless, too?

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… 😉

tkaiser
tkaiser
3 years ago

Benjamin :
@Mindee
PC2 has voltage regulation.

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

memeka
memeka
3 years ago

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).

Mindee
Mindee
3 years ago

@tkaiser

The github source will be available within about 24 hours or earlier.

Thank you.

Willy
Willy
3 years ago

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… Read more »

tkaiser
tkaiser
3 years ago

@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).… Read more »

tkaiser
tkaiser
3 years ago

@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… Read more »

tkaiser
tkaiser
3 years ago

@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). @Jean-Luc Aufranc (CNXSoft) IMO kinda useless to speculate about Allwinner’s motivation/goals, especially here 🙂 But it’s obvious that they simple… Read more »

Theguyuk
Theguyuk
3 years ago

Friendlyelec may surprise a few Nas lovers yet ! 😉

tkaiser
tkaiser
3 years ago

@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… Read more »

Jon Smirl
3 years ago

@Jean-Luc Aufranc (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… Read more »

Theguyuk
Theguyuk
3 years ago

@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.

tkaiser
tkaiser
3 years ago

@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 🙂

tkaiser
tkaiser
3 years ago

@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?

Jon Smirl
3 years ago

@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.

Theguyuk
Theguyuk
3 years ago

@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. 🙂

tkaiser
tkaiser
3 years ago

Jon Smirl :
@tkaiser
Did they finally do this with the V3S?

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/

Willy
Willy
3 years ago

@tkaiser

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.

That’s even more true considering the limited RAM bandwidth 🙂

Sander
Sander
3 years ago

tkaiser :

Anyway: NanoPi NEO2 is now officially latest member in Armbian family: http://www.armbian.com/download/

Wow, that’s cool.

Is that a 64-bit Linux?

Sander
Sander
3 years ago

@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
tkaiser
3 years ago

Sander : Is that a 64-bit Linux? Sure, both Debian Jessie and Ubuntu Xenial fully support arm64 architecture so both kernel+userland for all our supported 64-bit platforms (started with S905, then A64, now H5) are 64-bit. We are not that crazy like eg. SinoVoip advertising crippled Raspbian images with an ARMv6 userland for their ARMv8 M64 Banana to totally ruin performance. BTW: On all those 64-bit Armbian images, armhf architecture is already added since we include the armhf Firefox/Iceweasel variants due to the 64-bit versions still being buggy. Useless on NEO2 but just as another rather perfect example: many people… Read more »

JotaMG
JotaMG
3 years ago

@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?

tkaiser
tkaiser
3 years ago

JotaMG : 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… Read more »

tkaiser
tkaiser
3 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… Read more »

CampGareth
CampGareth
3 years ago

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?

Sander
Sander
3 years ago

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.

tkaiser
tkaiser
3 years ago

CampGareth : I keep saying 512MB of RAM is an issue but is it really? 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… Read more »

CampGareth
CampGareth
3 years ago

@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… Read more »

tkaiser
tkaiser
3 years ago

@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’)

itchy n scratchy
itchy n scratchy
3 years ago

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!

tkaiser
tkaiser
3 years ago

@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… Read more »

itchy n scratchy
itchy n scratchy
3 years ago

@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.

Sander
Sander
3 years ago

I’ve received the NanoPi Neo2 today, and … what a beautiful package. And the Neo2 is very, very small.

Fossxplorer
Fossxplorer
3 years ago


Wow awesome stuff!

tkaiser
tkaiser
3 years ago


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)

theguyuk
theguyuk
1 year ago

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

Advertisements