As expected, Pine64 has now launched Pine H64 development board, powered by Allwinner H6 quad core processor, and contrary to Orange Pi H6 boards, it exposes both Gigabit Ethernet, and a USB 3.0 port, which should please people wanting fast storage combined with Gigabit Ethernet.
The board comes in three variants with 1, 2 or 3GB of memory, with all also equipped with a mini PCIe interface, and various I/O headers.
Pine H64 specifications:
- SoC – Allwinner H6 quad core Cortex A53 processor with Arm Mali-T720MP2 GPU
- System Memory – 1, 2 or 3GB LPDDR3 PC-1600 RAM
- Storage – 128 Mbit SPI flash, micro SD card slot, and eMMC flash module connector (all bootable)
- Video Output – HDMI 2.0a up to 4K @ 60 Hz
- Audio – HDMI audio output,
- Video Decoding – 10-bit H.265 up to 4K @ 60 fps, VP9 and H.264 up to 4K @ 30 fps
- Connectivity – Gigabit Ethernet, headers for SDIO 3.0/UART wireless module
- USB – 1x USB 3.0 port, 2x USB 2.0 host ports
- 1x mini PCIe slot
- 40-pin Pi2 GPIO bus
- Euler GPIO bus
- Misc – IR receiver, RTC
- Power Supply – 5V/3A
- Dimensions – 127 x 79 mm (Same as Pine A64 board)
It’s worth noting there’s no information on the Wiki yet, and the company clearly states “PINE H64 is still in early stage development cycle, the current board condition is only suitable for developer and early adopter”, so it’s not for everybody, as software support is not there yet. We do know the board will support both Android and Linux distributions, and that Allwinner will/has release(d) a Linux 4.9 BSP, so a fairly recent kernel will be used with the board, and linux-sunxi will likely be working on mainline Linux and U-boot support for the SoC and board.
Price is quite competitive with the 1GB RAM version selling for $25.99, the 2GB RAM version for $35.99, and the 3GB board for $45.00. This does not include shipping, and accessories like the power supply. You’ll find the purchase links on Pine64 store.
In other news, the company also launch SOPINE clusterboard taking 7 Sopine64 systems-on-module for $99 with one free SoM for a limited time, but I cover this into more details tomorrow.
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.
27 Replies to “Pine H64 Development Board Features Allwinner H6 processor, Gigabit Ethernet, USB 3.0 and PCIe for $26 and Up”
The Allwinner 4.9 BSP (in beta state) as well as the 4.4 based BSPs for the older H SoCs can be found here: https://github.com/Allwinner-Homlet?tab=repositories
And here is the Pine H64 wiki:
H6 Soc have a 4xTS-interface … so my question is,does the Pine H64 have connection to it,
maybe via the “Euler” pins?
What kind of PCIe?, ı mean GEN2 or GEN3?
That’s that Allwinner H6 datasheet says:
Keith, if you saw my briefly posted complaint about not finding the boards, my browser opened up with the Rock 64 stuff at the top. After churning for a bit, it expanded the thumb and a huge page opened. I searched and found the H64. Thanks for the link. I’m studying it.
I deleted the original comment.
The Pinebook 14″ caught my eye too. Will be studying these.
can the H6 boot from a pcie storage device ?
i imagine the onboard spi flash could take care of initial uboot / kernel with a fs on a pcie storage..
Real world performance tests of the various high i/o buses will tell if the price is fair or not really.
LOL. A certain amount of SBC users for whatever obscure reasons think they need as much RAM as possible (and never look at ‘free’ output to see that all they get is just the kernel using more DRAM for buffers/caches). They will buy the 3GB version for no reason and are happy. Same with PCIe and USB3. These are associated with 5Gbps and so people are happy regardless of real world performance (see Allwinner SATA, I don’t know that much Banana Pi users able to admit that their boards were performing very poorly wrt storage and they fooled themselves praising ‘native SATA’)
Whether prices are ‘fair’ or not depends on BOM. I would call these prices somewhat aggressive given DRAM costs at the moment.
So far nobody knows how H6’s high speed busses perform since the numbers generated with Allwinner’s Android do not matter at all (not only Allwinner’s Android favours settings that will lead to nice single threaded CPU performance suitable for an Android device — everything that’s needed for performant IO and networking needs different settings that aren’t developed yet).
AFAIK USB3 and PCIe IP blocks are licensed from Synopsys so at least USB3 performance should be predictable (as good as RK3328/RK3399) so we have to see what’s possible with PCIe. Whether it’s something that performs poorly and is there more or less by accident (like SATA on Allwinner’s A10 and A20) or something you want to attach 4-port SATA controllers and other stuff to.
BTW: I doubt you’ll ever want to connect ‘PCIe storage’ to H6 since those expensive PCIe SSDs want a PCIe 3 x4 interface and not PCIe 2 x1 (more than 8 times slower). More likely we’ll see USB3 and SATA controllers attached to the PCIe bus, Pine64 folks already have an ASM1061 dual-SATA mPCIe module in the pipeline. So it’s all about driver support (PCIe + SATA) and most probably you’ll need to cramp u-boot + kernel + initramfs into SPI NOR flash to be able to put your rootfs on a SATA disk (since I doubt u-boot supports all the gazillions of SATA controllers available to be attached to a PCIe bus)
Almost forgot to mention. If it’s still as on the early prototypes then this board also supports USB2 data lines on the mPCIe connector. So it’s also suitable to attach LTE modems there but only those that feature an own SIM card slot on the card. And if USB on the mPCIe connector is used then IIRC one of the 2 USB2 receptacles doesn’t work any more.
AFAIK Pine folks are pretty busy at the moment (and on their way to FOSDEM) but they promised to upload recent schematics of the board to the wiki early next week.
Might be a nice NAS board if you add a “4 Port SATA III Mini PCI-e Controller Card”
One of the things I see keep coming up is people have different uses in mind for these devices so as normal what is terrible to one person is useable for another.
I have a hobby interest in Indie film making, I edit, cut, transcode my own mini films.
I use a elderly Intel duel core laptop, a elderly ( LCD smashed, but HDMI out AMD Phenom II quad core laptop ), a second hand Dell intel i5 .
I don’t bother with 4K, I normally use 1080, 720 or DVD. I use a simple USB to 2.5 HDD case, cost less than £7 and a second hand £5 2.5 HDD. To move movie between devices and to play on my Android TV boxes ( I don’t want the cost or trouble of installing a network at home or central storage ).
My arrangement would drive tkaiser mad or any network professional. But for me it works, does the job, I am not a business chasing time lines or have customers bullying me, that they want it yesterday. I have copes of my films on different devices and /or on DVD.
My adhock systems suits me and my needs.
Sure, this will also be my first test once we have mainline Linux running on this board and looked into appropriate settings and software support (cpufreq/DVFS, IRQ affinity, PCIe driver support/quirks and so on).
Some numbers for the rather popular Marvell 88SE9215 4-port SATA controller (single lane PCIe 2.x interface) can be found here: https://forum.armbian.com/topic/4845-marvell-based-4-ports-mpci-sata-30/
It’s important to read the text too since the numbers were generated with setups that aren’t comparable (eg. ext4 vs. btrfs and this with various RAID modes). At least it’s obvious that the rather outdated i.MX6 has not the fastest PCIe 2.x implementation compared to the Marvell SoCs that are able to fully saturate a PCIe lane. And also funny that Marvell’s own SATA implementation that lives directly in the SoC clearly outperforms PCIe attached SATA as long as we’re talking about a single PCIe 2.0 lane as on H6.
But even if PCIe performance isn’t that great and even if it’s just at i.MX6 level it’s still a great way for flexible expansion since it’s a general purpose high speed interface we’re dealing with.
You get ‘450Mbps Apple Atheros AR5BXB112 AR9380’ mPCIe cards off eBay that were taken out of used MacBooks for less than 10 bucks with dual-band capability and 3×3 MIMO. So unlike the crappy Wi-Fi that can be found on almost all SBC today a board with mPCIe slot can serve as a real performant wireless accesspoint (or client of course).
And with a flex cable and an adapter with an usual open ended PCIe x1 slot you can attach literally anything PCIe equipped to this board — slow but will work.
H6 support ts interface (DVB) but any devboard has pinout. Why any company add ts interface. I think good options alwinner h6 for dvb but need onbord tuner
Do you have Ts pinout for the pine H64 ?…”tuner” itself is no really problem,you can use ready can tuners like from serit .Add some components to power and control it,ready!….for the chips inside(tuner and demod)Stm linux driver are available …https://wiki.batc.org.uk/Serit_tuner
I dont know board pinout but H64 has look h64 pdf
The H6 with single threaded workloads can really clock with 1.8 GHz, confirmed by running the OpenSSL speedtest which also confirms existence of ARMv8 crypto extensions. The following is the ‘8192 bytes’ score comparing 3 different Cortex-A53 that run at different CPU clockspeeds: Marvell Armada 3720 at 1.0 GHz, Rockchip RK3328 @ 1296 MHz and Allwinner H6 at 1.8 GHz:
The numbers scale linearly with CPU clockspeed so H6 at least when only one CPU core is busy can operate at 1.8Ghz, with full load on all CPU cores it looks differently (maybe some sort of ‘Turbo Boost’ like on Amlogic SoCs where the ‘firmware’ decides how fast to clock the ARM cores but provides only bogus cpufreq values through sysfs. But maybe it’s just simple throttling that affected the available benchmarks. At least with the current BSP thermal tresholds are pretty conservative and let the SoC start to throttle already at 70°C)
Tinymembench numbers made on Orange Pi One Plus with old 3.10 BSP (libdram also from this version): https://pastebin.com/ubszDSUH (so most probably not comparable with PineH64 since different memory configuration. On a related note: few hours ago linux-sunxi devs got already rid off libdram, H6 can now initialize DRAM and boot BLOB free)
And this ‘7z b’ result for Orange Pi One Plus:
These scores are also influenced by memory throughput so can vary between different H6 devices. And IIRC James who did the tests thankfully added both heatsink and fan so these numbers are not affected by throttling and show again that H6 is able to clock a lot above 1.5 GHz. As a comparison: A RPi 3 that neither throttles nor is frequency capped running with a 7z Debian binary that has been built with identical compiler switches scores at 2866, a S905X board like ‘Le Potato’ running at slightly below 1.5GHz scores 3352.
Since memory bandwidth/throughput also has an influence it’s not possible to use 7-zip scores to determine CPU clockspeeds (useful to eg. verify that Amlogic is still cheating on us) but at least these numbers serve as a proof that H6 can exceed 1.5Ghz easily also with multi-threaded workloads and the 1488 MHz we saw here and there as maximum cpufreq have no meaning. It’s a 1.8 GHz SoC and to my knowledge currently the fastest Cortex-A53 around…
Nice openssl performance.
i was not expecting such an improvement over the rk3328, as you said if it scales with the cpu clock speed.. That also makes me wonder how the crypto block clocks are set, is it a fraction of the “runtime” main clock ? i thought it was a fixed clock, anyways the more the better..
yes that’s what i was thinking about, i don’t know what’s more stable / fast, usb3-sata or pcie-sata controllers..
LTE card support would also be nice, although huawei usb dongles are so cheap and fully supported in older kernels, that i would probably not look elsewhere unless you need cat6 (>150Mbps?) LTE modems..
Thomas, you seem to be commonly facing the problem of accurately determining the CPU frequency. When I started to work on my build farm and discovered that the S905 in my Odroid-C2 was cheating on me, I wrote a small utility to report the CPU’s frequency. It’s reasonably accurate on various architectures (x86, armv7, armv8, MIPS). It reports 1247 MHz for my Neo PLUS2, 1799 for my MiQis, 1999 for my CF-Pro (set to 2000 MHz). 497 MHz on my Geode LX800 @500 MHz, 4399 for my i7-6700k, or 396 for the AR9331 in my GL-inet (which is said to be 400 but from a 24 MHz crystal, so very likely 396).
I’ve just implemented auto-calibration in it (I used to set loop counts by hand), it’s available here : http://git.1wt.eu/web?p=mhz.git
It lacks documentation, but build it with -O2/-O3, and call it with an optional argument indicating the number of measures you want (1 by default), and another optional argument being the number of milliseconds of pre-heating (to get cpufreq / intel_pstate raise the frequency).
Hoping this helps!
Not really since I’m able to accept the thermal constraints most of those devices suffer from (in other words: to get top performance you do not need to look at maximum clockspeeds but at the amount of heat generated and the consumption and start there).
My interest here started due to some vendors cheating. You mentioned Amlogic already but the other negative example are the RPi people. The vast majority of RPi 3 users does not even know they’re running frequency capped with demanding workloads. The primary OS reduced the ARM core clockspeed to just 600 MHz while the sysfs node everyone looks at (or use it as monitoring source) happily lies about running still at 1200 MHz (same when throttling occurs, the sysfs node below will remain at 1200 MHz even when the SoC throttled down to 601 MHz):
And with Amlogic S905X and S912 (and even S905 when not using Hardkernel’s bl30.bin bootloader BLOB where it’s ‘fixed’) it’s the same issue. A firmware reducing clockspeeds based on certain criteria while the sysfs node reporting cpufreq is lying: https://www.cnx-software.com/2017/11/27/amlogic-s905x-vs-rockchip-rk3328-vs-allwinner-h6/#comment-549464
Thanks for your tool, will give it a try in the hope I’m able to spot such behaviour easily (eg. S912 lowering CPU clockspeeds to 1200 MHz when more than 3 CPU cores are busy).
That’s what the single-threaded openssl benchmark is telling (and that’s how we can use this benchmark to check for real clockspeeds but @willy‘s tool seems to be the better choice for stuff like this).
What happens in real world scenarios when the CPU cores are busy in parallel or more than one thread is running… needs more testing.
Wrt LTE modems: all I know are USB anyway using pins 36/38 of the mPCIe connector. So you can use ‘LTE mPCIe modems’ on the PineH64 since they followed the mPCIe specs closely (USB2 on the connector) while you can’t on eg. the Banana Pi R2 since there they forget to route USB2 to the connector.
BTW, the current version runs a single thread. I didn’t have the courage to implement a full cpu mapping configuration for multi-threading. Instead I’m running it with “taskset -c”, several instances at a time in the background and that’s often enough. This is already pretty visible on my upboard, which goes down from 1920 MHz to 1680 when more than 2 cores are active.
On platforms with mature driver support wrt sequential transfer speeds there’s not much difference between a good and UASP capable USB3-SATA controller and a PCIe attached SATA controller if limited to a single PCIe 2.x lane: gets close to 400 MB/s. But usually this is only achievable with SSDs and then you also want to benefit from high random IO performance / IOPS. Here we see PCIe attached controllers outperforming USB3 easily.
But it’s always also a matter of drivers and yet no one knows how performant the PCIe implementation here is (while we know that the USB3 IP is a Designware controller — most probably the same as in RK3328/RK3399 so performance with USB3 is at least somewhat predictable)
On behalf of James who again helped with testing: pastebin.com/p9CdLVuk
Your mhz tool running on an Orange Pi One Plus correctly reporting H6 clocking at 1.8GHz… and that also when all 4 CPU cores are busy at the same time.
Not that it would make much of a difference in practice, but in case you want to also drop the locals initialization overhead from loop50 and loop250, here’s a patch: https://pastebin.com/7U9Zcf9f
Hi blue! Thank you, sorry for the delay, I didn’t notice your message. I’ll give this a try, but I suspect it will be slightly more accurate on inefficient processors where the 0 initialization is not negligible.
Absolutely np, I often miss replies on cnx myself. Just to let you know, your tool has come in handy to me repeatedly. Coincidentally, it’s very useful for measuring variances in VM speeds on cloud providers ; )