It was a really nice feeling seeing a device of this class running Linux with near to zero effort and really wished it would always be that simple.
Edit: It will be easier to get a device with UEFI firmware. It seems possible to replace the firmware with a manufacturing tool published from Intel. But i haven't looked into that yet. I might try at some day to compile TianoCore or coreboot for it. Getting fastboot to work for Android seems possible too.
Or is it because HW manufacturers just ship code as soon as it builds and doesn't crash in rudimentary testing, leading to a code quality far below Linus-acceptable?
You could have a long-term stable API between the drivers and the rest of the kernel, but the kernel developers don't want that because it would restrict their ability to make breaking changes in the interests of performance or maintainability. It would also encourage proprietary drivers even more, and make them explicitly legal (at the moment, proprietary drivers are at best in a grey area, and most likely illegal).
Check out the wondermedia wm8850 sources on github:
Instead of using a device tree the drivers expects memory address to be passed to the uboot command line and other venders just hardcode the addresses, making you modify the sources to run the driver on a different device
On one project I attempted to move the kernel from 3.0.35 to 3.10 and even that was a huge pile of problems, asking vendors to bring their drivers up to speed. Some did, some didn't. It wasn't worth the trouble so off we went, shipping with 3.0.35.
Best i recall, Intel started Moblin (that later merged with Maemo to from Meego) because their mobile Atom SoC didn't provide PCI enumeration. Thus MS was reluctant to provide a Windows version for it, as Windows was highly reliant on just that for hardware management.
It's always saddened me that Open Firmware never got picked up for IA. They went for EFI instead...
There is nothing explicitly stopping a user from installing a different, open-source program that talks to the open-source shim module.
An overwhelming majority of SoC manufacturers develop drivers for Android's Linux Kernel 3.4 (and I think more recently? 3.10, etc). As per GPLv2 the kernel part of the driver needs to be FOSS, so most of the driver logic exists in the (proprietary) userland code.
Since there is no FOSS drivers for many of these SoCs, Ubuntu (and Jolla) use these proprietary drivers (targeted at Android's Linux Kernel 3.4) in conjunction with the GNU userland, by using libhybris (https://en.wikipedia.org/wiki/Hybris_%28software%29).
This allows Ubuntu (and Jolla) to:
1. Run the Linux kernel (3.4, or whatever version the driver was developed for)
2. Run the GNU userland (including glibc)
3. Run the Android drivers (using libhybris)
Was there anything useful gleaned from that approach, and would companies not able to share code be willing to try something similar?
Here is a good example of the new, caring, Blackberry side of QNX:
Foundry27, their hobbyist community site, is now a desolate wasteland.
How L4 compares with the QNX kernel, I don't have the knowledge to comment on.
I miss the Nokia Maemo days, which was not completely open hardware wise. But almost there. In practice, it was running Debian on your phone (but again with some caveats, including a non-mainline kernel).
Perhaps DragonBox Pyra, about to be released, will give us the chance to re-create that experience. In theory it will be possible to run a mainline kernel and Debian, ArchARM, GuixSD or whatever ARM distro you like.
Can you clarify how a mainline kernel can be run on such a device? I assume PowerVR are written only for specific kernel versions (e.g. in the same way GPU drivers are written specifically for Android's Linux kernel 3.4)
PowerVR is also said to be working on a free driver . This might do the trick.
Generally, GPUs are the showstopper in ARM architectures. Otherwise, it is possible to run not only a mainline linux kernel, but a deblobbed one (linux-libre). I do this on a Chromebook C201 . Note you don't even need CPU firmware, as it is the case with Intel.
On the surface Wayland is fairly innocuous, but it is having the effect of moving a whole lot of what used to be done by X onto the DE/toolkit.