NanoPi NEO 2 development board is an update of NanoPi NEO with a quad core 64-bit Allwinner H5 processor + 512 MB RAM, Gigabit Ethernet, and an extra audio header, which can be a great little board for headless application since there’s no video output. FriendlyELEC ask me whether I wanted to review to board with some of their NanoHATs add-on boards, and while I asked for NanoHat PCM5102A audio board and NEO Hub which I intended to use with Grove modules from my Wio Link Started Kit, I get a bit more than expected, as the company included sets of NEO 2 boards and accessories, NanoHATs, two serial debug board, and their BakeBit Starter Kit with several Grove modules to play with.
Since I have so many things to look at in this first post, I’ll just describe the hardware, assemble it, quickly check the paper documentation, and give some of my impressions about the kit I receive.
Let’s start with NanoPi NEO 2. It’s super tiny, as exactly the same forum factor as NanoPi NEO, except for the low profile Ethernet jack.
The bottom side comes with Allwinner H5 processor SoC, and Samsung K4B4G1646E-BYK0 DDR3L memory (512MB), while the top of the board features Realtek RTL8211E Gigabit Ethernet Transceiver. The board just has four ports/connectors: a micro SD slot, a micro USB port for power, a USB 2.0 host port, and an RJ45 connector.
There are also two headers (2x 12 pin + 12x pin) for I/O just like for the first NEO board, as well as an extra 5-pin header for audio on the right of the 4-pin UART header. The audio header is also present on NanoPi NEO v1.3 board, but not the older boards. See pinout table for details.
Each package with the board also includes a Quick Start Guide describing the board, and explaining how to use the company’ Ubuntu Core + Qt image. As you can see from the photo above, the boards also make great paper weights, but I’m sure you’ll find something more interesting to do with them… 🙂
I also get a heatsink + thermal pads + screws and nuts kit, not included by default. Installation is very easy. First remove the two protective plastic sheets on the blue thermal pad, place it on Allwinner H5 processor, and then add the heatsink on top and secure it with the screws and nuts. Just make sure you orientate properly without covering the IO pins.
I did that for both, and checked possible combinations for those who want to build NanoPi NEO (2) farms. The first combination is to place the boards in opposite direction, and then use some spacers (mine were not suitable) to hold both boards in place as shown here.
The configuration above takes the less space, however, you may want to have all Ethernet ports on the same side, and the low profile Ethernet jack allows for a more compact design compared to what was possible with NanoPi NEO.
This takes about 5 x 4.5 x 4 cm, so if we round that up you could have 1 meter x 1 meter x 4.5 cm deep cluster with 800 NanoPi boards (3,200 cores). You’d just have to find out how to power and cool it down… The 512MB memory might limit use cases for clusters. FriendlyELEC also sells an acrylic case for 8 board clusters.
The main use case for NanoPi NEO (2) board is probably IoT and electronics projects, so I soldered the two headers which are provided with the board (inside the package).
First I thought I made a mistake when I installed the heatsink first, but actually the nuts help keep the headers in place while soldering, so I did not have to use a sponge to push the headers while soldering, as I normally do.
NanoPi NEO 2 boards are now ready. So let’s checkout the two add-on board I got: NanoHAT PCM5102A audio board with Texas Instruments PCM5102A audio stereo DAC, stereo audio output via RCA connectors, and an IR receiver, as well as NEO Hub (aka NanoHAT Hub) with 12 Grove connectors (I2C, Digital I/O, Analog Inputs, UART) compatible with Seeed Studio offerings.
NEO Hub also includes an unpopulated SPI header.
The NanoHats sit on top of NEO (2) board, and you can still connect the UART to TTL debug board if you need to access the serial console. NanoHat PCM5102A also comes with 2x RCA to 3.5mm female jack to connect headphones or speakers.
Since NanoHats includes male headers, it’s also possible to stack them.
In some ways, NanoPi NEO (2) and NanoHAT are the more powerful equivalent of Wemos D1 Mini and shields based on ESP8266, and I really like the design of both solutions.
If you already own some Seeed Studio grove modules, you just need the NEO Hub, but Bakebit Starter Kit appears to be a nice way to expereriment with all sorts of sensors, LEDs, and servo.
There are twelve modules in total: 2 LED modules, an LED bar, on OLED display, a button, a joystick, a buzzer, an ultrasonic sensor, a servo, a potentiometer, a light sensor, and a sound sensors. The kit includes two detailed user manuals: one in good English, one in Chinese.
The first part explains the features and interface for each module with a Wiki link, and latter on you have some easy projects with source code leveraging the NEO hub and some of the modules.
You can also access the documentation online.
FriendlyELEC boards may be slightly more expensive than Shenzhen Xunlong’s Orange Pi boards, but documentation appears to be clearly a step or two ahead, and they have an ecosystem of modules that’s currently lacking on Orange Pi boards.
Some price info about the kit I’ve received:
- NanoPi Neo 2 board – $14.99
- Heatsink set – $2.97
- NanoHat PCM5102A – $9.99
- NEO Hub – $12.99 (Not needed if you buy Bakebit Starter Kit)
- BakeBit Starter Kit – $29.99
You’ll need to add shipping, but it’s normally only a few dollars extra for registered airmail. You’ll find additional accessories by scrolling down on NanoPi Neo 2 page on FriendlyARM store. The next step will be to install an operating system, which will be FriendlyELEC’s Ubuntu Core + Qt image, or Armbian nightly build, in order to do some basic tests and run benchmarks like I did for NanoPi NEO, and following up on that I plan to write an extra post reporting on my experience playing with NanoHat PCM5102A and Bakebit Starter Kit.
Continue reading:
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
512MB is a problem for me with these 64b CPUs. 64b makes everything bigger which consumes more memory. My application just fits in 512MB on 32b, it won’t run in 512MB on 64b. I have not measured accurately since there is a lot of variability, but everything seems to get about 30% larger.
@Jon Smirl
Why not using a 32-bit userland then? Or the older H3 NEO instead (most people won’t need Gigabit Ethernet on these small gems anyway)?
BTW: a slightly larger NanoPi NEO Plus 2 is also ready but FriendlyELEC chose to fix some software issues first (but they told us it’s ok to already spread the news): https://forum.armbian.com/index.php?/topic/3576-nanopi-neo-2/&do=findComment&comment=28100
An excellent alternative to FriendlyELEC’s heatsink when using the various NEO in a metal enclosure are 15x15mm copper shims and thermal glue.
@Jon Smirl
Hi John pity you cannot use the 1GB NanoPi A64 Allwinner A64 board.
Friendlyelec are not like Orange pi, Friendlyelec actually talk to customers and reply to emails. I would recommend you email them John and discuss your needs or the any market need you see. I have always found them polite, informative and honest, IMHO.
Two more hints for hardware tinkerers: FriendlyELEC has also another nice NEO companion using an MEGA328P providing Arduino compatibility and also supported by BakeBit library: http://wiki.friendlyarm.com/wiki/index.php/Matrix_-_UNO_Dock_for_NanoPi_NEO
And then H2+, H3 and H5 have one real hardware PWM available — some information here: https://forum.armbian.com/index.php?/topic/3886-pwm-on-h3-and-h2-with-mainline-kernel/ (not yet with H5 supported due to H5 software support still being a moving target so there it’s currently necessary to patch DT individually)
@cnx How long did shipping take?
I ordered one at FriendlyElec 10 days ago, and I wonder how long shipping will take: the usual 2-3 weeks, or shorter, or longer … ?
I second this, it has always been a pleasure to exchange with them. They not only talk with customers but also listen, accept advises and design suggestions. It’s one of the most open hardware designers I’ve seen to date.
@Sander
All dev samples that arrived so far (not only) from FriendlyELEC were shipped with DHL Express and I would assume that’s the same with review samples. You might better check the usual forums for shipping experiences 🙂
@Willy
To be fair: the same applies to a few other board makers (most notably Olimex: they blog about new products as early as possible to get community feedback and improve designs regularly based on this feedback. I also prefer their 100% OSHW commitment). Though with some vendors communication is sometimes somewhat devious and/or asymetric (Xunlong being amongst them 🙂 )
What I really like at FriendlyELEC is that they publish the stuff they have always asapissimo (be it schematics, BSP sources or hardware manuals from chip vendors) and that they care both about details and software. On a related note: FriendlyELEC’s CEO emailed us two days ago that they now also want to officially support mainline kernel with their H3/H5 boards. While all the real work has been done by awesome linux-sunxi community already this is still a step in the right direction since that means their internal devs do not waste their time with Allwinner’s BSP any more but can focus on making all their ‘ecosystems’ (there’s not only BakeBit but also ‘Matrix’) work with mainline too. I hope we can convince them to provide their code in a way that users do not have to use their OS images (for various reasons).
Almost forgot: it’s also great that they take CE/FCC certifications seriously and there’s an European distributor so we’re able to use these boards in commercial projects 🙂
@john smirl why not building an armv8 32bit armbian for your needs?
Seems cool for my new project!
@Theguyuk
We bought a bunch of BananaPI M64 — A64, 1GB RAM, Ampak wifi. emmc. They are just for a limited number of test systems and development. We made a batch of 20 of our custom A64 PCBs. They mostly work but have things that are broken.
For our specific purposes the NanoPi A64 board is missing emmc and Bluetooth. Bluetooth could easily be fixed by swapping to a RTL8723BS module (maybe 10 cents more). No emmc is a bigger issue. We are running embedded Android which causes the memory constraint.
I’d like to give H5 a spin, but I need the right board (and the H5 Android 6 SDK). Only reason H5 is interesting is to get another USB port.
I do really wish Allwinner would switch off from the Mali-4xx line and move to something that supports OpenCL. OpenCL we’d use, these Mali-4xx GPUs are useless to us. Of course if they double the chip price when switching GPUs that’s not good.
@Sander
Most review samples are sent by courier so it take 2 to 4 days. When I order things for myself it usually take 2 weeks over airmail, although I had one package that took two years… 🙂
@Jon Smirl
The only H5 Android SDK I know of is mirrored here (but still at 5.1): http://filez.zoobab.com/allwinner/h5/
And there are some rumours about two new 28nm SoCs with Midgard GPU (no idea which generation) to be released this year: A63 and A6X.
@tkaiser
Allwinner A63 is more than a rumor as Allwinner had some marketing materials about it at CES 2017 @ https://youtu.be/764m8ngRroA?t=6m40s . Not many details yet. 16 nm process.
@cnxsoft
Thanks, so both A63 are A6X are already covered by marketing material. If I understood correctly the Allwinner guy stated ’16nm at the end of the year’ which would match the information from linux-sunxi IRC (A63/A64X being 28nm and 16nm based new SoCs next year). And seconds later he said A63 would be 16nm though available in Q2/2017. Still wondering what ‘PDDR2/3’ might be and ‘Ultra Quad-Core’ 😉
@Jon Smirl
I suspect the thing about Mali 4xx is they are affordable and for SoC aimed at TV displays very affordable.
In better world people would combine ideas about the best features for a affordable SBC going forward and either crowd fund it or publish the spec free, much like the open software movement.
You would need a means to ensure there is legitimate demand too. Oh well just a dream.
That tears it, definitely gonna have to buy some of these and stack them. Been checking the memory usage of ceph which I was always concerned about, actual reserved memory from one 2TB OSD (disk) is 80-120MB. 512MB of host RAM will do I reckon, but 1GB would be safer.
@CampGareth
Well for your cluster use case the ‘traditional’ Ethernet jack here becomes a mess since most of the space needed will be wasted for Ethernet cabling. A solution where a bunch of SoCs could be interconnected to a switch IC through RGMII (avoiding even external GbE PHYs) would be preferable IMO. And also SoCs that are more suited for this stuff (eg. Armada 3700 capable of 2.5GbE, SATA and PCIe).
Anyway: since you’re thinking about USB2 storage in case you didn’t already notice: Pine Inc has plans to release a cluster board for their SoMs soon using a RTL8370M Switch + 9 x RTL8211E for the individual SoPine (I believe it’s slightly delayed since currently they focus on getting their PineBooks in stock).
@tkaiser
I’d totally forgotten that chip exists and looking back on it with new RAM requirements the ESPRESSObin is mighty tasty, thanks! Easily got capacity for 2 drives, won’t bottleneck on IO, plays nice with a standard PC PSU. I think it comes out to within $10 of the price of 2 x nanopi neo 2s after microSDs, shipping etc?
As nice as board to board networking would be you could just get a cheap 5 port switch, 1 upstream and 4 downstream. Inter-board communication’s fast and as for upstream, in a NAS situation you’re limited by USB 2 so having the bandwidth for 3 boards at full pace seems okay to me. Commodity with its economies of scale beats custom solutions every time, that said I’ll keep an eye out for the Pine cluster.
@CampGareth
Well, unfortunately adoption of IEEE 802.3bz (check nbaset.org) starts rather slowly (especially switches) while some SoC can make use of 2.5GbE for quite some time (the older Armada 38x support up to 3 x 2.5GbE via SGMII, the Armada 3700 only 1 but only one is used this way on the ESPRESSOBin). I guess the ESPRESSOBin is more or less Marvell’s reference design for Armada 3700 based routers and in such a storage cluster setup you might want to benefit from the SoC’s interfaces exposed differently. Ouch, off-topic again 🙂
Slightly back on topic: IMO NEO 2 and NEO Plus 2 with their Gigabit Ethernet make a great small NAS in addition to what they’re supposed to do primarly: IoT controller thingie. Some tasks (eg. backing up a Mac with TimeMachine) won’t saturate Gigabit Ethernet anyway but will be bottlenecked by Fast Ethernet. Such a backup benefits from low latency (GbE) but will not be limited that much by storage bandwidth so in fact a NEO 2 with a good USB-to-SATA bridge will perform as fast as any beefy x86 box (but the latter wins of course when it’s about restore and desaster recovery). But I doubt this device class can perform when it’s about being a Ceph Node based on ‘performance best practices’ you find on the net.
Just received mine today. They’re impressively small. They look much smaller in your hand than on the screen 🙂 The photo with Jean-Luc’s fingers at the top gives a good idea. To get a reference, 40×40 is the size of the small fans we used to place on top of the 486dx4 CPUs 2 decades ago, but here you don’t have a fan but a 10 times more powerful computer. Or it’s the size of 3 ESP-12 modules or 1.5 Wemos-D1 or half the surface of a GL-Inet. for those wanting more modern references. Really fun! Not booted yet…
Small update, I assembled one of my boards, took the armbian image I had for the orangepi pc2 and it booted fine. I noticed the CPU was running at 408 MHz and could up it to 816 by setting the cpufreq_hack in the boot environment. I could even enable the stock 1008 MHz frequency by writing 0x80001410 to the second register in boot.cmd.
I found that the board is quite capable regarding the network performance. I could push 965 Mbps of HTTP using large objects (1 MB) and about 860 Mbps using small ones (20 kB) at 1008 MHz. At 816 MHz, it’s more 920 and 800 Mbps. At 408 MHz, it’s about 730 Mbps peak. But that’s quite correct.
I checked the RAM performance. I’m measuring about 55ns per 64-bit word (4 consecutive 16-bit reads) with the stock kernel, and 41ns with the Armbian 4.10 kernel. I don’t know what changes, maybe the DDR3 timings. I didn’t notice stability issues, though in my case I wouldn’t care since I’m going to use it as a network test companion for my laptop. With the enclosure it fits nicely in the laptop’s bag.
By the way, the stock kernel is a 3.10.65-based BSP showing 1/3 of the 4.10 network performance. So I think most users will directly install the Armbian image here. I have no idea whether it’s missing any feature or not compared to the stock kernel for such a machine.
The micro-usb power supply usually is an issue but the board is not power-hungry (it doesn’t have a display output) so that instead makes it quite convenient. At 1008 MHz in idle it draws 200 mA (1W). When emitting 965 Mbps of traffic, I see it climb to 400 mA (2W) and 460 mA (2.3W) with small objects (more CPU intensive). And it draws 510 mA (2.55W) when running openssl speed -multi 4 rsa2048 (which is the one I use to stress my other boards). So I’m confident regarding the power stability via the micro-USB cable.
I’m realizing that the enclosure could be thinner if made in aluminium serving as a heat sink. But for this the USB connector would need to be a low profile one too.
Overall I’m very satisfied, this board will be convenient for my network testing activities and it doesn’t risk to get scratches like many other ones thanks to the enclosure, whose size clearly is not an issue. I don’t need the orangepi-pc2 anymore (and it already managed to lose its heatsink in my bag, no place to put a screw, that may be a hint that it doesn’t like me) :-).
Worth noting that until very recently the only software for this board was their own outdated version of Ubuntu (15.10) though FriendlyArm have confirmed a newer version will soon be available. The current nightly builds of Armbian though not guaranteed – seem to work (16.04) and my script is now working with this to create the usual collection of programs running on the NEO2 including Apache/PHP, SQLITE, Node-Red, MQTT, Webmin and much more.
Unfortunately most users neither care about kernel (and countless bugs and security vulnerabilities fixed) nor settings (thermal/THS/throttling settings, squeezing the max out of the hardware — in Armbian that’s the prepare_board function in /etc/init.armhwinfo for example currently not taking care of H5 so there’s still room for improvement). And it’s not just users but unfortunately board makers too, most of them also don’t care about both (FriendlyELEC being one of the few exceptions here). But they’re somewhat doomed since they’ve H5 boards now with audio pins exposed that lack support in mainline kernel at least for H5 now.
Since they said they’re focussing on mainline kernel now for H3/H5 I had some hope their kernel dev would start to add the missing audio drivers for mainline kernel but it seems they prefered to waste developer’s time again on this BSP crap based on most recent commit messages in their h5_lichee repo 🙁
@willy
Ah, almost forgot: cpufreq scaling should work out of the box on NEO 2 with Armbian’s nightly image and also on the OPi PC 2 but there’s an I2C accessible voltage regulator the kernel driver wants to talk to so that might be the reason that the Armbian image for OPi PC 2 shows weird behaviour on NEO2 and seems to need boot environment hacks.
If you want to use an Armbian image ‘on the wrong board’ with mainline kernel better add the missing .dtb and then it’s just a small addition to armbianEnv.txt to point the boot script to the correct device tree:
Funny update: I compared a NodeJS benchmark running on an arm64 distribution one time with NodeJS binaries for arm64 (64-bit) and with armhf (32-bit): https://github.com/nodesource/distributions/issues/375#issuecomment-290412647
Memory ‘consumed’ while running the benchmark is 663MB (arm64) vs. 363MB (armhf). That’s rather huge especially given that benchmark numbers are more or less the same. Obviously this was not running on NEO 2 (512MB only and therefore a swapping candidate with these workloads) and most probably I’m doing something wrong 🙂
Thanks, but I looked for such a dtb and could’t find it, I guess my image was a bit old and I have to update it. There were only 3 of them in the /boot directory (one of them being opi-pc2). Sorry if I’m vague, I’m speaking from memory.
Regarding the fact that most users don’t care, you’re right. I should have said “most careful users will switch…”.
Don’t bother, that was just this, it’s present after an upgrade.
Thanks!