<i>>> As one example, we could be installing the Linux distribution of our choice on the Pinebook Pro using a standard aarch64 UEFI ISO installer, just like we do for any other laptop, if someone spent a couple of weeks upstreaming the last 6 patches to mainline Linux and put together a suitable u-Boot payload to flash on the SPI flash chip. But, instead of one working solution for everyone, we have 20+ Linux distros publishing Pine64-specific images to flash to microSD cards.</i><p>I think this is a key part of the problem and is not unique to Pine64 devices, but the ARM ecosystem as a whole.<p>There needs to be more funding and focus drawn towards standards compliant firmware. U-Boot is great, but it tends to lead to lots of unique distribution-specific problems as Drew points out here.<p>We have the SBBR and UEFI standards for ARM, but it needs to be more widely built out for consumer devices and not just servers.<p>Here is one key piece of work that NetBSD maintainers are working on: <a href="https://github.com/jaredmcneill/quartz64_uefi" rel="nofollow">https://github.com/jaredmcneill/quartz64_uefi</a>
I'm literally in the process of build a test hardware rack most of which will be full of Pine64 hardware... Drew is spot on here, as someone that is putting my own money where my mouth is and trying to support the hardware, the priority is inverted. I've got a PineBook Pro that can't sleep because S3/S4 sleep state stuff is low level kernel & foundations stuff, there's patches and packages but its far from clear, I had sleep working once, now it doesn't, and I'm putting an entire spare PineBook Pro into my test hardware rack after I crack it open and wire all the reset switches and stuff to external cables, because I'm sick of "whoops buggered the uBoot on the SPI, looks like I have to do take the case of and do that hardware reset dance again. I shouldn't have to turn a laptop into a hardware device under test to pre-flight basic stuff like boot loader updates due to the poor state of low level support.<p>Don't get me wrong, it's better than a LOT of other ARM based hardware. The Pine64 guys deserve to be commended for the work they are doing, but they do have their priorities inverted and need to do something about it. The recent changes about having "community pricing" and "regular pricing" are potentially a step in this direction but it doesn't seem to have made much difference from what I've seen so far.
This is an interesting take.<p>The author is probably correct that only Pine could organise priority coherent sharable work on kernel drivers, telephony stack etc which would then benefit all distributions.<p>I guess distributions could club together to fund it but that's more complicated.