Almost exactly one year ago, FriendlyELEC launched NanoPi K2 board powered by Amlogic S905 processor, following Raspberry Pi 3 form factor, but adding an eMMC flash socket, Gigabit Ethernet, 4K video playback, an I2S header, more memory (2GB RAM), and doing without a camera or LCD display interface.
The company has now launched another similar looking model – NanoPi K1 Plus – based on Allwinner H5 processor, also equipped with one DVP camera connector, but losing one USB 2.0 port, and HDMI is limited to 4K @ 30 Hz.
NanoPi K1 Plus specifications:
- SoC – Allwinner H5 quad-core Cortex-A53 processor @ 1.3+ GHz with Mali-450MP GPU
- System Memory – 2GB DDR3
- Storage – micro SD card slot, eMMC flash interface
- Video Output – HDMI 1.4 up to 4K @ 30 fps, CVBS (composite)
- Audio
- HDMI digital audio output
- 3.5mm audio jack
- On-board microphone
- 7-pin 2.54mm pin header
- Connectivity – Gigabit Ethernet (RTL8211E IC), 802.11 b/g/n WiFi (Realtek RTL8189ETV) with on-board PCB antenna
- USB – 3x USB 2.0 host ports, 1x micro USB OTG port
- Camera – 24-pin DVP camera interface
- Expansion – 40-pin compatible GPIO header with I2C, GPIO, UART, PWM, S/PDIF, SPI, and etc
- Debugging – 4-pin serial console header
- Misc – IR Receiver, 1x user button, power and status LEDs
- Power Supply – 5V/2A via micro USB port
- Dimensions – 85 x 56 mm (6-layer PCB)
The company provides a Ubuntu Core (FriendlyCore) image based on Linux 4.x for the board, and instructions to get started on the Wiki, where you’ll also find schematics and other documentation.
NanoPi K1 Plus can be purchased now for $35 + shipping on FriendlyELEC store and ships with a heatsink and USB cable for power.
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
I’m guessing you meant to say I2S?
Most important question: How is Armbian support?
Nice to see and unlike Orange Pi, Friendlyelec have software available on launch. I await more toys to be unwrapped from the toy box.
Still no Allwinner H6 CPU
This works on Pine H64 (allwinner H6) board
https://forum.pine64.org/showthread.php?tid=5790&pid=35873#pid35873
Icesnowys has put in all the hard work. First build arm trusted firmware, bl31 and then do the uboot, and finally kernel
Gigabit ethernet, usb3 works, I am yet to test PCI on Pine H64 board
Igor assembled yesterday also an experimental Armbian image for Pine H64 available at dl.armbian.com. Based on @icenowy’s work of course. Bootlog: http://ix.io/18DU (I don’t see XHCI/USB3 though)
The usb3 phy is unchecked for some reason in the kernel config hence desen’t get build.
Its listed under PHY devices, just below usb2 phy. enable it and all works
I got close to 299MB/s on an m.2 ssd (hdparm).
on a mechanical disk, it was about 127MB/s which was the same as my i7 dell laptop
Xalius mentioned such numbers already but just in read direction. So I would test write too.
BTW: Could be symptomatic. In 2018 a new H5 device is launched and we’re all talking about H6 instead :\
Wasnt H5 released in 2016 ?
> Wasnt H5 released in 2016?
Yes, but the point is that Allwinner’s H5 BSP was again that crappy that unlike with A64 one year before when Allwinner + 64-bit was interesting literally no one (to my knowledge not a single community member) wasted his own time to fix the H5 BSP (still not even cpufreq scaling / DVFS is working).
All community driven development focused solely on mainline kernel but still important parts of full H5 support are missing upstream (e.g. cpufreq scaling / DVFS). And now with the first H6 devices around I would believe situation negatively affects older Allwinner SoCs like the H5 (since count of linux-sunxi devs doing the major work is rather limited).
On the bright side: We could convince FriendlyELEC 14 months ago to stop relying on those crappy Allwinner BSPs and the smelly BSP 3.x kernel and they started to pick up community work (partially in a somewhat proprietary way and unfortunately they still do not upstream their own stuff). So with FriendlyELEC H3 and H5 devices users can really benefit from a recent u-boot and kernel version (though not really ‘mainline’ as per definition).
On a side note: FriendlyELEC also started to design their boards in a way u-boot can differentiate between them automagically (CPU type and some GPIO that can be queried). So their mainline u-boot fork identifies the board it’s running on to set stuff like DRAM clockspeeds or load the correct DT automagically.
Unfortunately this stuff is not compatible with upstream u-boot and also official maintainers ignore this (for example the DRAM clockspeeds FriendlyELEC uses on their boards that are pretty conservative: 408, 504 and 576 MHz — of course upstream u-boot uses weird settings like 672 MHz instead due to maintainer ignorance leading to all sorts of instabilities)
Ok, ok, that was just a lame attempt to get back on topic 😉
https://github.com/Icenowy/linux/tree/h6-init/drivers/phy/allwinner
its the phy-sun50i-usb3
“Pine H64 (allwinner H6)” They could not have picked a more confusing name? Something not close to “Pine H64, actually not based on a A64 soc, but hosted at pine64.org”. I don’t know, there are plenty of names available, why not a volcano name, a planet, a city, whatever. Why not adopting Orangepi naming convention: Pine H64 v2+ pro 🙂
They still only have 8GB eMMC modules available. There competitors (HardKernel and Pine64) are offering multiple sizes up to 64GB.
http://linux-sunxi.org/H6
Seems the PCIe interface doesn’t work on Linux without some massive tweaking.
> Seems the PCIe interface doesn’t work on Linux without some massive tweaking
A bit off-topic here but you’re right: PCIe and H6 are not a perfect fit since Allwinner pretty much crippled the implementation which prevents mainlining a driver for it. Allwinner themselves try to cope with it by hacking the drivers for the few PCIe devices they support in their BSP.
Maybe some vendors will combine H6 onboard with one dedicated PCIe chip for which an out-of-tree driver could do the job with mainline kernel. Pine64 folks wanted to explore a NAS device with H6 and 2 PCIe attached SATA ports for a very attractive price for example. But currently we better treat H6 as not PCIe capable at all.
Thats it!
H6 is not usable at all for pcie. I think sunxi ppl are wasting their time and h6 is another a31…
I doubt aw will start manufacturing corrected steppings of h6 either.
> I think sunxi ppl are wasting their time and h6 is another a31…
Even without being able to use PCIe H6 is still a nice and inexpensive SoC for a lot of use cases. If only Allwinner would start to support their own hardware upstream and stop this BSP mess using forward ported drivers from hell…
Thats also true…
Mainline with official aw support. Sounds like a snowstorm in hell 😛 lets see maybe they will eventually realize their benefits.
One question for you: why is it that there are many patches in armbian that are not upstreamed and also dont seem to end up there anytime soon? License? Coding style? No one caring to integrate? Just out of curiosity 🙂
> One question for you: why is it that there are many patches in armbian that are not upstreamed and also dont seem to end up there anytime soon?
That’s due to the upstreaming process in Linux being such a mess. For example THS (thermal) and cpufreq/dvfs drivers for H3 existed already 2 years ago and my H3 devices since then run also with mainline kernel and correct cpufreq scaling, DVFS and throttling if necessary.
@megous the original author tried to get these patches into mainline kernel but lost interest due to maintainer requests. Then @icenowy picked up his work but lost interest for the same reason. Yesterday or the day before yesterday @wens reported that at least cpufreq landed in -next branch for H3 but still without voltage regulation support so DVFS is not working and even if this will become part of mainline kernel we still can not make use of cpufreq scaling support since DVFS is not implemented. Direct result: with plain mainline kernel H3 devices are much slower compared to legacy/BSP kernel (or Armbian).
Armbian tries to collect those patches flying around, if needed adopts them to the specific kernel version we’re currently using in our next or dev branches so that stuff that will not land in mainline kernel ever or anytime soon is already usable.
But some patches (like e.g. our clockspeed adjustments for cpufreq and DRAM to allow our users to operate their boards reliable) will never arrive upstream. So you might end up with some boards running instable with ‘real’ mainline u-boot/kernel but not with Armbian. Life’s too short to argue with upstream maintainers over and over again, better patch the problems away on your own.
Thanks your insight into those processes are very much appreciated. Was curious about this for a while.