Most low cost development boards do not include internal storage in order to decrease costs, and instead require their users to flash their preferred operating system on (micro) SD card. This makes it easy to get started, but many micro SD cards often suffer from poor random I/O performance, even for Class 10 or greater card, leading to a poor user experience compared to what you’d get with an eMMC flash. Shenzhen Xunlong has released yet another Allwinner H3 board, namely Orange Pi PC Plus, similar to Orange Pi PC but adding WiFi, and 8GB eMMC flash.
Orange Pi PC Plus specifications with main change with Orange Pi PC highlighted in bold:
- SoC – Allwinner H3 quad core Cortex A7 @ 1.3 GHz with ARM Mali-400MP2 GPU up to 600 MHz
- System Memory – 1GB DDR3
- Storage – 8GB eMMC flash + micro SD card slot
- Video Output – HDMI with CEC, AV port
- Audio I/O – HDMI, AV port, on-board microphone
- Connectivity – 10/100M Ethernet, 802.11 b/g/n WiFi with external antenna
- USB – 3x USB 2.0 host ports, 1x micro USB OTG port
- Camera – CSI Interface
- Expansions – 40-pin Raspberry Pi compatible header with 28 GPIOs, UART, I2C, SPI, PWM, CAN, I2S, SPDIF, LRADC, ADC, LINE-IN, FM-IN, and HP-IN
- Debugging – 3-pin UART header for serial console
- Misc – IR receiver; Power button; Power and status LEDs
- Power Supply – 5V/2A via barrel jack (micro USB OTG cannot be used to power the board).
- Dimensions – 85 x 55 mm
As usual, the description states that the board supports “Android 4.4, Ubuntu, Debian, Raspberry Pi Image”, but most people who want to run Linux will now go with Armbian server or desktop image instead, using a Linux 3.4 legacy kernel. Mainline support for the server image is almost there for all Orange Pi H3 boards.
As usual with Shenzhen Xunlong boards, the price is very competitive, and Orange Pi PC Plus is sold for $19.99 + $3.43 for shipping on Aliexpress. As a side note, while Aliexpress used to be the only options to buy a Orange Pi boards, the little inexpensive boards have become a little more popular recently, and I’ve seen several models sell on other websites such as DealExtreme, eBay, GearBest and others…
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
Performance numbers for the eMMC (and link to the fastest tested SD cards) and some experiences regarding Wi-Fi summarized (and hopefully soon a bit more feedback) at the usual location
BTW: It’s H3 @ 1.3GHz. All the Oranges (except One/Lite) with the better voltage regulator run without any problems at 1.3 GHz and do not even throttle down that much even under heavy synthetical benchmark workloads.
At Armbian we’re currently evaluating development of a user-friendly tool to let hardware reliability of every board be checked individually so that experienced users might be able to ‘unlock’ even higher CPU clockspeeds (without insanely overvolting their boards!) or improve throttling behaviour but there’s not that much to gain since getting better real world performance needs tweaks at other places: Using HW acceleration where available, setting kernel tunables right, distributed IRQ handling accross CPU cores and even such boring stuff as explaining again and again that choosing a storage medium showing high random IO performance helps in most if not all use cases (that’s where the eMMC jumps in — we did testings with random crappy SD cards and the fast eMMC present on H3 Oranges/Bananas and it’s like night and day)
cnxsoft: So you will be forced to update the table with H3 SBCs from previous article 🙂
Orange pi have come along way but suffers from lack of more focus on software. It needs a gathering of developers to benefit from a larger eco system and less of a one size fits all walled city approach. There are many working on less well know OS for users not just Server, Nas users.
Plop Linux seeks support but not many people have bothered to vote.
And other OS at various states of ability, http://www.orangepi.org/orangepibbsen/forum.php?gid=46
@Theguyuk
There are currently really strong guys at Armbian, OpenELEC (jerney), Android distros customizators, etc. It is not that bad as a few months ago. I personally wait for possiblity of changing resolution on the fly as I hate frequest manipulation with script.bin files.
As to the SD card random access issue people forget these cards have for years been aimed at high speed burst photography of large photo image files and recently high definition video record and play back. High speed random access as ROM, Hard drive store is not there intended market. They are just getting used for that by users.
Often the cheap thinking outside the box solution beats the high price approach, ie USB to Sata can beat the slow , cheap Sata implementations on many boards, assuming no heavy bandwidth sharing.
So look for memory storage designed for fast random access not high speed image play back, record, still image capture.
@cbm80
Changing resolutions on the fly isn’t that hard to achieve since linux-sunxi community works together and A64 and H3 are pretty much the same. Jernej/OpenELEC figured out how to do and implemented it already on H3, longsleep provided an universal sunxi-disp-tool to be used from user space in the meantime so all that’s needed is a dev joining the Armbian team who’s interested in display stuff (I for example connect displays most of the only by accident or to test stuff I’m not really interested in 😉 )
@cbm80
hmm. right. Thanks for making me work hard :p
I guess I’ll just edit Orange Pi PC column since it’s quite similar.
It’s nice price but I would suggest all mini computer developers to focus on SATA ports, since it’s not pleasant to depend on USB HDD always, or little EMMC’s (they’re best for OS though). I don’t think microSD cards are enough for many tasks, and they can’t hold much data even nowadays. SATA is perfect to have 1 or 2TB of avaliable space, or even more in the near future, since everyday more and more 2.5″ HDD’s are being used thanks to SSD’s.
It’s hilarious that the few solutions with SATA ports are well over 20$, and that’s kinda nonsense.
@nobitakun
https://olimex.wordpress.com/2015/07/09/allwinner-did-it-again-new-quad-core-powerful-chip-pin-to-pin-compatible-with-a10-and-a20/#comment-22806
Or use the f2fs file system !
(Igor has promised to test it… any idea why armbian does not use f2fs?)
@JotaMG
Armbian does support f2fs (even btrfs) but the problem is that only ext4 allows online resizing (that’s the reason our Armbian images fit on every SD card or eMMC larger than 2GB since we ship small and expand on 1st boot) so we can provide only ext4 OS images. Also f2fs/btrfs require more recent kernels as supported on H3/sun8i now.
But using our build system and mainline kernel you can create Armbian images for all boards with f2fs or btrfs rootfs (or any if you chose NFS –> nice to roll out a fleet of SBC equipped with just minimal storage and booting through the network). But in these cases you have to decide how large the rootfs on the card has to be before since this will produce an image of fixed size.
how about instead creating another partition on 1st boot and mount there /usr, /home etc?
humm i kind of regret having bought an opi pc a couple of months ago, not that i’ve done anything with it anyways..
But i seldom use wifi, especially if it’s 2.4GHz only, and although emmc is a nice upgrade, the only thing that would really make me switch from my amlogic s805/s905 or rpi boards would be a chip with sata which allwinner don’t have either (besides Ax0 chips)..
The low price and great armbian support may make me reconsider that in the future but at the moment, when i don’t need gpios which is 90% of the time, i’m better of with a cheap tv box, beelink x2 with H3 at 20e, or some s805/s905 1GB at 25-30e, where i can run openelec or ubuntu nicely with official hw acceleration..
I still have to try running armbian on my beelink x2 h3 box as well as jernej’s openelec, i believe there is already an oe build for the x2 box, and if i can use that then i’ll probably stick with that box.
i’ll test armbian desktop on my opi pc and try installing cedrus/sunxi-vdpau if it’s not already present and see how kodi handles that. If that actually works it would be already be a very nice step forward for my specific use.
I believe that’s a test cnxsoft did on another orange pi h3 board with mediocre results, we’ll see..
@tkaiser
reading your feature “Enabled overlayfs”, i was wondering what use is made of ovelayfs in your image ?
thx
@mdel
Vanilla (e.g. unmodified) Kodi on Armbian doesn’t benefit from libvdpau-sunxi, due to missing OpenGL interop function, which obviously will never happen (Mali doesn’t support OpenGL). Some people are already working on modifications to make it work.
@TC
We do already too much ‘1st boot magic’ (which is time consuming since problems that appear here waste insane amounts of time to test/debug since you have to walk through the whole image creation and 1st boot process multiple times).
The ‘real’ problem is that people want to solve a hardware problem (crappy SD cards) in software (f2fs instead of ext4). In our tests f2fs isn’t that faster or faster at all (search in Armbian Free forum for SD card performance thread) and especially with older kernels strong reliability concerns apply (do a web search for ‘american fuzzy lop filesystem’ to get the idea). F2FS performance might be better when running Android where constantly fsync calls happen but that doesn’t matter much for Armbian/Linux.
And to be honest: If you buy recent SD cards from any of the 4 recommended vendors or use eMMC you don’t have to fear early wear-out too (in Armbian we try to detect crappy/old SD cards on 1st boot and leave some unpartitioned spare area to help their controllers with wear leveling on these old cards)
@mdel
Adding overlayfs was maybe added on user request. At least it should ease creating Armbian images that are read-only (no writes to SD card or eMMC) since all changes happen in RAM and are dropped on reboot. Would be then a simple one-liner in our customize-image.sh modifying /etc/fstab of the freshly created image (using Armbian build system you can even replace the whole rootfs/distro at the end of the installation this way)
You would’ve to use Desktop images to get libvdpau/Cedrus support but only working with mpv as far as I understand. And it’s pretty easy to let either Armbian or OpenELEC run on any ‘unsupported’ H3 TV Box since most probably all that’s needed is replacing script.bin. But to be honest: OPi PC Plus with its eMMC also makes a nice TV box if you could also make use of the GPIO features or want to connect many disks (4 USB ports without shared bandwidth!)
Why have they dropped Bluetooth in their latest boards? This sucks. No buy from me.
@JM
There was never any Orange Pi with BT. The only H3 SBC with a BT capable chip is BPi M2+ but the vendor didn’t manage to get BT working (applies to the CSI camera as well — they really suck when it’s about software/support). BT on H3 SBCs means USB anyway so choose a board with plenty of USB ports: http://www.cnx-software.com/2016/06/08/allwinner-h3-boards-comparison-tables-with-orange-pi-banana-pi-m2-nanopi-p1-and-h3-olinuxino-nano-boards/
How important would eMMC be for a board used as a headless server, with a fairly light load? I’m thinking in that case, 1GB RAM would be enough for buffers/caches to hold most of the data that the eMMC would speed up read/write access for. So the benefits of the eMMC would only really be apparent under heavy loads (either a lot of access for a headless server, or running a GUI).
Does that make sense?
@onebir
Most probably not that important. I’ve noticed good internal storage performance makes a massive difference when running Linux desktop, but on a light load headless server it should not matter that much, it will boot slower, and answer requests a bit slower too. A fast eMMC would also be important if your server requires a lot of database accesses. If you only serve static content, it might not make that much a difference.
I’ve also noticed SD cards tend to die prematurely compared to NAND / eMMC flash, but maybe that’s because I use them to test OS and often completely re-write them.
@cnxsoft
Makes sense – thanks!
@cnxsoft
And in addition it should be noted that not every eMMC used on various boards behaves identical. The modules used by Xunlong are pretty fast but Hardkernel for example use eMMC that is way faster on their most recent ODROIDs and other implementations are far behind. For example Olimex Lime2-eMMC. Given the price difference and the performance numbers my next Lime2 will still come without eMMC and will be combined with a 32GB Samsung EVO (since 8 times more storage, identical random IO and outperforming sequential speeds comparing to Olimex’ eMMC). But please read a few posts below how newer mainline kernel positively influences eMMC performance on this board.
@tkaiser
F2FS is preferable due to less wear. Although flash cards have become pretty robust, the design of F2FS is convincing!
@LinAdmin
If we would talk about Android then maybe. At Armbian we chose a 600 second write commit interval for ext4, do partition alignment on 16MB boundaries (most recent Samsung EVO/EVO+/Pro/Pro+ use this and not 4 MB as most other/older cards), leave some unpartitioned space on older/small cards to help the controller with wear leveling and so on.
Other use cases (eg. a desktop Linux with apps that constantly write to disk to update SQlite databases like Midori/Firefox using fsync calls permanently) might show a real advantage for F2FS. Headless/server useage with our settings definitively not and anyone who tries to optimize database useage on SD cards or eMMC (where F2FS would shine) IMO is doing something wrong (better move the stuff to SATA — random IO with A20 and a connected SSD is superiour regardless of the FS in question)
Apart from that f2fs requires a pretty recent kernel version so for most users unavailable on H3 anyway since we’re dealing there with an 3.4.x Android kernel.