(12-27-2015, 11:17 AM)tkaiser Wrote:(12-27-2015, 08:58 AM)paulieg Wrote: 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.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
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)
- 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
Thank you for the very informative precis of the initial issues, their impact and some of the steps required to address them. It's much more helpful and actionable. Would you say that this state of affairs for banana pi is a consequence of fixing it being too difficult or the status quo being sufficiently workable so that no one is sufficiently incented to do the work? This might be my ignorance of linux on ARM talking, but none of it seems insurmountably difficult especially wrt u-boot.
I haven't been able to find the Orange Pi for anything near $15 - they currently run $25+ on their ali* storefront. As far as use case, I'm interested in being able to ingest video at 720p via MIPI-CSI, send it somewhere over a kludgy imitation of 802.11p using packet injection and seeing what the floor is like for end-to-end latency. Provided all of that works and I like the numbers, I'll want to see if I can adapt it to a low power platform. I'm not married to this idea though - this is a hobby after all, so I'd like to do it on a device that's more rather than less futureproof. I also happen to have a more work-related reason to be interested in 64-bit ARM and this is a cheap way to start developing some familiarity with the architecture and its performance.
-p