Several years ago, FriendlyELEC launched NanoPi NEO board with Allwinner H3 quad-core Cortex-A7 processor followed by NanoPi NEO2 upgrading to the Allwinner H5 64-bit Arm Cortex-A53 processor. Both boards target low-cost headless applications with I/O headers, USB and Ethernet, but while the NEO2 comes with Gigabit Ethernet, NEO SBC only features 10/100M Ethernet.
The company has now been working on a new family of boards called ZeroPi that’s very similar to NanoPi NEO boards, but they do not come with any I/O headers, and the first ZeroPi board features Allwinner H3 processor, and Gigabit Ethernet.
ZeroPi specifications with highlights in bold or stricken-through showing differences against NanoPi NEO:
- SoC – Allwinner H3 quad-core Cortex A7 @ 1.2 GHz with an Arm Mali-400MP2 GPU
- System Memory – 256 or 512 MB DDR3
- Storage – MicroSD card slot, unmounted SPI flash
- Connectivity – Gigabit Ethernet via Realtek RTL8211E PHY
- USB – 1x USB 2.0 host ports, 1x micro USB
OTGport,2x USB via headers - Expansion headers – None
- Debugging – 4-pin header for serial console
- Misc – Power and status LEDs
- Power Supply – 5V/2A via micro USB port
or VDD pin on headers.
- Dimensions – 40 x 40 mm
I’ve also added NanoPi NEO board for comparison, and we can see ZeroPi design looks much simpler, so it may end up costing the same or maybe less despite the extra Gigabit transceiver chip.
The company may have figured out most people don’t actually use the I/O header on NanoPi NEO, so they designed a board targeting USB (storage) and wire networking, with the option to boot from the network (without microSD card) via the SPI flash, which hopefully they’ll offer as option without people having to solder their own.
ZeroPi is likely software-compatible with NanoPi NEO so beside Friendlycore (Ubuntu Core) and OpenWrt images provided by the company, Armbian should also be supported.
The board has not launched yet, and I got all information from the Wiki. [Update: The 512MB RAM version of ZeroPi board is sold for $12.99 on FriendlyELEC store where you’ll also find accessories such as a $4.99 metal enclosure].
[Update 2: The board is $10.99 if you purchase with crypto-currency on OpenBazaar]
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
Why would they remove the OTG capability? That makes no sense!
Indeed, installing a software serial port on micro-usb is almost the only way to reconfigure the network when you lost access to the device, without having to open the box. I really do not understand the motivation to remove the functionality which only requires to route two wires to the SoC :-/
Wouldn’t a rescue button make more sense for that? If you mount a 16MB SPI NOR you can put u-boot in there and a kernel + dt + initramfs FIT that you can trigger via GPIO so you can boot up to a rescue system.
That’s still really not convenient. Quite frankly, you never know accurately in what state it’s supposed to be in this case. When you mess up with a config, you need a shell. The button is fine to totally erase a config and restart from scratch but that’s not always what you want just to fix a netmask in a conf.
>When you mess up with a config, you need a shell.
Which is why you check the GPIO and boot a known working self contained setup with dropbear etc from a FIT and then you can do whatever is needed to make it bootable again. If it’s in SPI NOR the sd card can be totally broken an it’ll still work. I.e. if the rootfs is unmountable and needs to be fsck’d before you can even boot again you can do that without disassembling anything.
If you wanted to go really crazy you could set a bit in some non-volatile register, like one of the spare bits in the RTC, as a boot success flag and use that to automatically trigger booting the rescue FIT after a reboot.
I perfectly understood what you meant and I still disagree, for having been been using precisely this on many devices. This only works for large scale device deployments for which you write the recovery procedure in the manual, it does not work with hardware that you accumulate on your desk because each and every such machine uses a different IP address, a different login, a different password etc. It always takes ages to figure the right one. The machines i have in my computer bag which do work like this have a sticker on which I write the default address, login and password for this precise reason. And sometimes I have to disassemble one to access the serial port, or I decide that I won’t waste my time on it and use another one. Really it’s a pain. The theory sounds good, the practise is painful.
I use this all the time with boards on my desk. Having a working all in one image is super handy because you can just as easily boot the image via TFTP and even serial from your u-boot SPL if your board get’s really bricked.
Just to be clear, *all* my images work this way. I’m really talking about not remembering what IP was setup last time, and what’s the recovery IP & credentials for each board, which leads me to write all these on the devices with stickers. There’s no one-size-fits-all here, because depending on the network you’re in when you start working with your board, you’ll setup a different recovery address during development.
That’s how most consumer class and IoT devices actually WORK. You may disagree, but it’s perfectly fine- most aren’t going to do what you’re talking to once the device is in service. If people would QUIT presuming **THEIR** use cases are the only valid ones, things would end up being better overall.
(Hint: You’re talking an exposed hackable USB serial edge. For a product that isn’t just a hackable device, this is quite the BAD IDEA. See above rant for what needs to be said here…)
Read what I wrote, I precisely mentioned that this is OK for the production phase when the procedure is written in a manual. I was talking about the developer’s use case, having to deal with numerous boards all with different addresses, networks and credentials.
>OK for the production phase when the procedure is written in a manual.
You don’t need a manual. You literally press a button during reset to tell u-boot to boot an alternative working OS image with the tools you need to fix the primary one. If you’re using Debian you can have SSH recovery in it’s initramfs. This isn’t a fringe thing..
>having to deal with numerous boards all with different addresses, networks and credentials.
That’s why you have your rescue system come up with a known IP address, IPv6 link local addresses are predictable as long as you don’t enable privacy extensions, and have your common SSH public keys trusted by the rescue image so you can log in using that. If you want you could add avahi to the image and have the board spam the network with it’s presence that way too.
> That’s why you have your rescue system come up with a known IP address
Which is the address you write in the product’s manual I was speaking about when you sell it to consumers.
Type any common product name on google and it auto-completes with “default address” and “default password”. There’s a reason for this, users simply don’t know what default address a device uses when in recovery mode because not two devices use the same. When you do it with your own boards on your desk, you think that you’ll always set up the same IP address. I’ve been used to use 192.168.0.200 for this for several years, until some coworkers started to use the same recovery images and to consider the recovery mode the normal way to access an unconfigured device (like I did as well), resulting in 2 or 3 such addresses always being present on the network. Also some devices have different default settings in their u-boot and you figure that this u-boot cannot save to flash you you’re forced to use their factory settings (e.g. gl-inet), sometimes they even see the interfaces in a different order (many marvell-based devices). And using different networks to access u-boot and your recovery image is also a pain. So I stand by what I was saying, recovery button + fixed address + procedure written in the manual is fine for the final product but a pain for hacking. I vastly prefer the console for this.
>Type any common product name on google and it auto-completes with “default address”
IPv6 Link local addresses are based on the MAC address. So they are constant as long as you have a fixed mac address which is true for sunxi if you have your DTS setup correctly.
>default settings in their u-boot
By having a rescue image you can boot allows you to totally skip u-boot and any issues it has. I.e. if you need WiFi to get online you’re SooL with u-boot but you can create an image that boots and starts hostap with buildroot.
>And using different networks to access u-boot and your recovery image is also a pain.
Again, you totally bypass u-boot. u-boot reads the GPIO in your bootcmd and loads the alternative image if the GPIO is active. Once the image boots you can ssh in, mount your rootfs and fix anything you need to. You can even pivot into it and restart init to see what happens on boot.
>final product but a pain for hacking. I vastly prefer the console for this.
A buildroot based FIT image I can tftp onto a board is literally the first step to doing any work on a new board for me. Don’t get me wrong you need a console initially anyway but this is very much part of your development toolkit. For boards with storage you can’t remove like eMMC it’s a must have because flashing images in u-boot is a pain in the ass.
For a final product the whole thing would be totally automated and would reflash firmware based on NVRAM flags etc and that isn’t what I’m suggesting at all.
IPv6 LL might possibly be a solution to the IP address conflict I talked about (which is the main problem with fixed addresses). For multi-port machines it would even allow to plug all interfaces and figure which one works. I just haven’t tried. But just FYI my images are way simpler than what you describe. I do have a recovery kernel which contains its own rootfs with the required tools including sshd (dropbear) on a fixed address, that is loaded when nothing else works, but that’s just to avoid going to the lab and plugging the serial cable, and for use in field, for emergency situations when users don’t have serial cables. For tests and/or RMA we still prefer the serial console. Now for the rest of the system, the whole image fits into an initrd and only the config is loaded from the flash. The system boots with a working default config (thus it’s fine if the flash isn’t found), and we can force this mode using a button. This is where the IP conflict arrives, as everyone uses the default address, or a hung up machine somewhere rebooted in this mode and took it, so you often have to play with “arping” and “arp -s” to force your way through one of them. In the end, the console is way simpler. But I keep the idea of the IPv6 LL addr at hand, and will experiment with this. This combined with lldpd could possibly make a workable alternative.
IPv6 LL is a godsend really. If you don’t have something like bonjour spamming the network the only real alternative is to scan the network until you find what you’re looking for and if you try to do that in an iOS app for example you will probably get dinged by Apple. Apple’s homekit stuff actually requires IPv6 and IPv4 auto ip presumably to avoid the situation we have with consumer routers etc setting a default IPv4 address on factory reset.
Tools for doing dev and tools for shipped products seems to be getting mixed up in this.. I was only really talking about the dev situation.. but for a shipped product unless you trust the consumer leaving serial, JTAG etc enabled seems to be asking for trouble. Asking for some “security researcher” to get out their usb uart and then announce they totally owned your product type trouble.
In IoT the trend seems to be to disable everything in production units and then for failure recovery you either have two copies of the whole system with NVRAM flags/button selection to allow a roll back or you have a recovery setup with fixed version of the software embedded into that can reflash the firmware if need. I’ve shipped both but I prefer the first option as roll back doesn’t actually involve messing with the flash and potentially making things worse.
From the purchase link with metal case, case shows OTG ?
Because they reused the same enclosure as for NEO board.
Because the OTG on the H3 is…twitchy. If you knew anything about it, it’d make a lot more sense.
The fact that it works well enough for some users is already a good reason to keep it. And if it’s so unstable, then it could have been nice to at least leave the traces exposed for an optional connection, or even better, routed to a CH340 (or CH330 if space is scarce) connected to the inside serial port. This would at least make the console available outside. Some users would possibly even be fine if they had to install the chip themselves.
The board now appears on the site. It’s at $12.99 and with 512 MB RAM, versus $14.99 for a similarly sized NEO LTS one.
Has somebody found any use of the mali on such a board? Aside from dark silicon, that is.
5V VDD and GND is on the serial port header beside RX and TX.
So the board maybe powered also from this header (did work on the NanoPi Neo) 😉
We seem to have hit a plateau with these boards. If you need cpu *power* without a display then the RK3308 seems like the way to go now. If you don’t need much CPU power and your application is small we should be able to build tiny cheap boards with a Cortex A7 by now.
Well, the A35 definitely is not what will bring you CPU *power*. Even according to ARM themselves it’s only 6% faster on integer than the A7. I’d say it simply should be seen as the most suitable replacement to switch to ARMv8 with no performance compromise while saving a little bit of power. But yes, we’re circling around the same CPUs. I suspect that A7 and A53 will have been the most sold cores in history!
Outside of the Cortex-M lineup, perhaps. As code transitions more and more towards aarch64, though, CA34 and its eventual successors might take the leadership there.
>Well, the A35 definitely is not what will bring you CPU *power*.
>Even according to ARM themselves it’s only 6% faster on integer than the A7.
I didn’t mean relative to the A7 really. I was really speaking in relation to something like a teensy or other mid-range MCU board you’d use for similar headless projects. And you want the A35 because you might actually have a chance at running it full speed without constantly getting throttled.
If you just barely need to run Linux and don’t care too much about the speed of it then a single core Cortex A7 is cheaper (Cheapest with integrated memory so far is $2.5) and you can probably get down to 25mm x 25mm for everything if you really try.
OK then, and I indeed agree when it’s vs an MCU. Now I tend to classify my needs like this :
– very small code and very low power (i.e. lazy way to replace several discrete components) -> AVR
– less responsive but slightly smarter with wifi capability => ESP8266/ESP8285/ESP32
– generic low-performance proxy/ssh box : A35/A53/A55
– solid performance (cpu/ram/io) at good efficiency : A72+
– topmost performance : core-i7
This also means I’m not seeing anymore a generic use case for an Atom or Celeron. There could be niche ones though (e.g. performance/cost which tends to be slightly better on low-end Celerons than A72 if you don’t care about a 4 times larger board, or when you need multiple SATA connectors, eventhough it’s not true anymore since NanoPI M4’s 4xSATA hat).
>– very small code and very low power (i.e. lazy way to replace several discrete components) -> AVR
Here I prefer the low power STM32s. Mainly because debugging is a lot better and you don’t have to suffer with the 8 bit issues.
>– less responsive but slightly smarter with wifi capability => ESP8266/ESP8285/ESP32
IMHO anything with network connectivity should have an MMU and TLS, DNS etc libraries that aren’t horrific. This is the space for the single core Cortex A7 I wrote about. The ESP32 is cheap but you can get a complete Cortex A7 based 1080P IP camera for $4-5. The chips on those when bought in single quantities are ~$2.5 for a 800MHz Cortex A7 with 64MB of DDR2. If you can make a whole camera for $4 surely you can use that same chip and strap it to the back of an AP6212 with an SPI NOR and have something that doesn’t cost much more than the ESP32 boards but is better in almost every way except maybe real time latency. I’ve built a ethernet version of such a board and a wifi one is in progress. It’s totally possible.
>– generic low-performance proxy/ssh box : A35/A53/A55
The espressobin is the only thing I would bother with here. It’s slow as crap but the IO is fairly good.
>– topmost performance : core-i7
With an NVidia GPU that’s IMHO the best setup you can have for getting stuff done right now. If you can get past the stupid RGB LEDs generic gaming parts give you a lot power for your money.
>This also means I’m not seeing anymore a generic use case for an Atom or Celeron.
Stuff like local gitolite, apt-cache, NFS and so on. Just being able to have a proper NVMe SSD makes the experience far better.
“a complete Cortex A7 based 1080P IP camera for $4-5” — where is this, I can hardly believe it as the camera module alone is a few dollars already.
I think you probably expect a camera in case but I meant a complete camera as in the module.. modules like this are $4-5:
https://item.taobao.com/item.htm?spm=a230r.1.14.120.2e2f773aYaucNZ&id=560907427849&ns=1&abbucket=8#detail
Guest; which A7 is $2.5 with memory on the chip? – thanks
https://item.taobao.com/item.htm?spm=a230r.1.14.14.48bc2e0eOugbem&id=590023270313&ns=1&abbucket=8#detail
Don’t such designs have a limit? At $12..99 and no gpio you get close to budget TV box at $20, although they don’t have gigabit ethernet.
On large volume use $12.99 does save dollars thought.
And at no volume for this price you don’t want to fight for weeks with a tv box, trying to reverse their schematics from a bogus device tree just to try to boot a mainline kernel on them. Not to mention how annoying it is when it’s rockchip-based with their horribly complicated process and images.
is Sunxi a lot better barring GPU etc, I only need H2+ for non-multimedia stuff, does H2+ have industrial-quality-level parts(temperature range ,etc for industry usage, instead of home consumer toys)
I don’t think you’ll find anything even remotely close to industrial quality from Allwinner unfortunately. There’s a reason you find these SoCs in the cheapest consumer devices. Rockchip and Marvell are way more serious in this regard. For Amlogic I don’t know yet, they seem to have stopped lying about their frequency, this is already a good sign. Now honestly board vendors will often be more important than the SoC vendor, so you’d first need to evaluate how serious they are before going industrial.
Allwinner did start to make some of its popular product line ‘industry/military-quality’ ready:
https://www.cnx-software.com/2018/06/01/allwinner-t2-a20-industrial-grade/
https://www.cnx-software.com/2018/05/06/allwinner-unveils-a40i-a40pro-and-a60i-a60pro-industrial-military-grade-processors/
it’s just that no such version from H2+/H3 yet
“The company may have figured out most people don’t actually use the I/O header on NanoPi NEO”
I don’t know about that. The NEO is a classic IMHO because it’s just about the most economical Linux device out there to interface between ethernet and peripherals like sensors, relays, etc. I think the reason Friendly sell so many of the NEOs is because people do actually use the GPIOs.
Also, on the ZeroPi, if they bumped the ethernet up to Gigabit, shouldn’t they have also bumped up the USB to 3.0? That would make it more appealing, IMHO.
I have a NanoPie NEO2 (“it’s great, it really is, it’s true”) … it’s always (as an ARM64 server), and I’ve never used any I/O header
for exactly the same configuration, plus 2MB SPI flash with Wifi, though H2+/100Mbps for cpu/ethernet, Orange Pi zero LTS seems more attractive to me, I don’t need a 1Gbps for this board and H3 vs H2+ is not a big deal either. NanoZeroPi with a case is $18 before shipping, while Orange Pi Zero LTS will be $12.6
Good point, but I wonder about Orange Pi build quality and reliability though.
I ordered a few for a testing, I’m betting on that “LTS” name … it may carry some quality info there since it’s “LTS”?
Low quality. Only certain boards are assembled in western factories such as RPi zero in GB.
Being assembled in western factories doesn’t imply better quality, it only implies higher costs. You can have excellent quality from eastern factories, it just depends what factory you rely on.
4 years ago there was another ZeroPi 🙂
https://www.cnx-software.com/2015/10/06/zeropi-is-an-arduino-raspberry-pi-compatible-motor-control-board/
I’ve got 4 NanoPi boards and the main issue for me is that they are not reliable. I’ve tested several Linux flavors but they are all the same almost. Boards hung all of a sudden, watchdog does not work reliably. Network connectivity is not stable.
Are you speaking of older boards shipped with a BSP kernel based on 3.4 ? I’ve got a 3.4.39 for a while with my old nanopi-m3 and it was a real crap. I remember the WiFi connection hanging all the time for example, and kernel panics here and there while processing video with opencv. Much later someone ported the patches to newer kernels, dropping all the stuff that was already covered and it turned from totally unreliable to perfectly stable. I don’t remember what kernel I’m running on my fire3, I think it’s 4.9 or 4.14 (I forgot precisely because I don’t have to fight with it anymore), and I also found that the ones provided by Armbian happen to work pretty well.
Yes, These are the old version. I tried many kernels from FE and armbian builds (Debian and Ubuntu). Results vary but nothing rock solid so far. The plan was to have two small DNSCrypt servers + some IoT stuff. But the reality is that I can’t rely on these boards. They die all of a sudden. If watchdog works, it will work, but it doesn’t.
That is my experience your mileage may vary. I tried to convince myself to give it a chance, but I failed
What exact model are these ? Are you powering them from a micro-usb connector, and if so have you tried other cables ? Random freezes can often result from power issues. I’ve even had some bad luck with NanoPC-T3 and the barrel connector, just because the barrel cable I used was crap (2.2 ohms over 30cm!). It would randomly crash during installation. I was really angry when I discovered the cause! Now I power all my devices with a 5.2V source to compensate for cable losses.
As I said I’ve had stability issues with kernel 3.4 on the M3 (wifi and usb), others on the fire3 with the same crappy kernel, and I never got the S2 to work reliably at all with this kernel, and the board died during my quest for the problem. But my experience with the stability of the Neo, Neo2, NeoPlus2, Neo4, PC2, PC3, Fire2, Fire3 and M4 with more recent kernels has been very positive for now. These ones are permanently up on my desk so that I can instantly access one of them to compare the performance of my code, and I don’t even remember when I last found one hung.
FriendlyELEC told me they’ll make some with SPI FLASH in one or two months.
And they also launched the board on OpenBazaar for $10.99 for people wanting to buy with crypto-currencies (Zcash). Link is in update 2 at the end of the post.
What would be some applications/use cases for this board? Without the GPIO pins, it seems pointless to me.
I had setup my NanoPi NEO as a domoticz server. https://www.cnx-software.com/2017/01/19/how-to-install-domoticz-home-automation-system-in-nanopi-neo-and-other-arm-linux-boards/
I’m only using the Ethernet connection. It’s also true I don’t need Gigabit Ethernet, Fast Ethernet is good enough.
It can also be used as a cheap mini NAS: https://www.cnx-software.com/2017/06/18/nanopi-neo-nas-kit-review-assembly-openmediavault-installation-setup-and-benchmarks/
Some people will use it as proxies, SSH bounce boxes, VPN gateways, even firewalls when connected to a cheap manageable switch with VLAN tagging (plug this to a $25 GS105E and you get 4 gigabit ports). Those deploying probes for network status monitoring will find it great as well. It will simply be used to periodically scan and report devices around, measure response times from various services etc. At this price, it’s the type of device you send for free to your customers and you don’t even expect to get back, so you don’t care if someone steals it to play at home with it once the audit is over.