Linux Kernal Development - BETA Boards

[tkaiser]

It certainly won't be the first time the community has hacked on an imperfectly supported piece of hardware to make it do what we want.

Sure, but devs might think different about this specific board compared to the Kickstarter crowd that only heard of the Raspberry Pi before.

I had a look into the BSP two weeks ago: http://forum.armbian.com/index.php/topic...er/?p=3173

Just to elaborate what I meant with 'crappy OS images' and 'slow'.

The problem with Allwinner's BSP is that it only provides an Android boot sequence with leads directly to problem N°1: http://forum.pine64.org/showthread.php?t...207#pid207 (Andre provided also a few first patches in the meantime that focus on compiling and not functional issues)

If this is sorted out and we're able to boot then everything that's really important does NOT live inside the rootfs of the distro in question but instead in the first sectors of the SD card used unless we (the community) develop a different bootloader approach. You want to change a kernel parameter? Rebuild the BSP! You want to adjust a small piece of hardware initialisation? Rebuild the BSP!

Most people happily joining the Pine64 club now (developers) seem not to be familiar with the linux-sunxi platform (Allwinner SoCs) and that this is one of the hardest challenges as long as we've to rely on Allwinner's kernel and bootloader. Therefore they will concentrate on the stuff they're familiar with (tuning something inside the rootfs) and that's where the crappy OS images will originate from. 

You can see that over at banana-pi.org (Banana Pi M2/M3 are just other sunxi devices with limited mainline kernel support) where even the vendor itself is only able to provide crappy OS images since he doesn't manage to escape from Allwinner's Android bootloader stuff. They told you to recompile the whole BSP to switch to a different display resolution in the past (same might happen here). In the meantime they adopted our suggestions to provide a few adjusted u-boot settings and to overwrite the first sectors on the boot media. But this 'solution' is far away from being acceptable.

And regarding 'slow': We can't benefit that much from the one important '64 bit' feature with a SoC that can only address 2 GB of physical RAM (though it helps being able to use a huge virtual address space). But to be able to benefit from the other ARMv8 feature it would be necessary to use code that has been compiled for the ARMv8 instruction set. Only then you see a performance improvement. If you're forced to use software compiled for ARMv7 or ARMv6 (I bet someone will provide a Raspbian image for the A64 rather sooner than later) then you don't benefit from Cortex-A53.

Therefore we'll see OS images where performance differs much due to

• used architecture (if you choose the normal armv7h Arch Linux rootfs instead of building your own on top of http://archlinuxarm.org/platforms/armv8/generic then performance will be degraded)
  
• kernel settings (a few things are really important to get performance gains on slow ARM SoCs)
  
• cpufreq/dvfs/thermal settings
  

And then it's the question of the use case. If you're a software developer that wants to start porting stuff to Aarch64 then the Pine64 might be interesting. If you just want a cheap SBC with the same CPU/GPU performance but much more I/O bandwidth you better go with an Orange Pi PC for the same price. Its SoC has 3 USB host controllers instead of just one (the 2nd USB port on the Pine64 uses the USB OTG controller. On other/older Allwinner SoCs the OTG port can use the musb app gadget controller in host emulation mode but that's not a real host controller, performance is worse and not all USB devices will work with. I would suspect the same applies to the A64 as well)