Regarding 3, I think a lot of this stems from ARM not using standardised interfaces with discovery of peripherals. Historically, board configuration ended up "compiled into" kernels and bootloaders. Device Tree (DTB) has made this a bit better, as the device tree can sit alongside the kernel or bootloader, holding the board-specific configurations.
The real root issue though is that ARM devices are generally built as "finished" products, so don't need to support pluggable hardware, meaning you can make assumptions about what pin on the SoC is used for each purpose, and exactly what it's connected to. This leads to kludges on phone handsets sometimes, where audio jack polarity is incorrect etc, and needs a board-specific driver hack. These hacks were often maintained in a board-specific kernel tree.
DTB certainly helps, but ARM devices are still (to some extent) quite hardware-specific. Moving towards UEFI bootloaders on ARM64 looks promising, and there are now "generic" ARM64 bootable images for some Linux distros.
Hopefully we'll see more use of a standard UEFI interface on ARM devices, so we can get towards having common bootable OS images, without board specifics needing handled by the OS!
Another major problem is OEMs and distributors that insist on locked boot loaders or other DRM baked into the firmware and OS. Such machines are never intended to run anything but approved software, which is always abandoned.
IMHO, any locked device sold that connects to the internet should be forced by law to unlock after 6 months of no updates.
I would love to see Verizon forced to do this. It would be glorious.
Device tree is really a step backwards. People hate how complicated plug and play became, but device tree is x86 before hardware discovery became a thing.
That's mostly the gist of what you're saying, but I think it needs to change; a lot of embedded platforms are adopting device tree now and it's just making things more difficult.
Not really; X86 still has an equivalent to device tree in the ACPI tables.
Device Tree is IMO better than X86's implementation because ACPI just gives you bytecode that you as the kernel have to trust to perform actions whereas device tree gives you a declarative view of the system.
Not being better ACPI so much as having busses that are reconfigurable on typical PCs.
With ACPI the configuration is packaged with the hardware, with device tree it's not. ACPI might be worse for certain reasons but it is more usable in practice.
> Not being better ACPI so much as having busses that are reconfigurable on typical PCs.
But there's tons of buses that aren't reconfigurable on PCs. You just don't generally see it because it's papered over with ACPI. But all the same I2C/SPI and random devices sitting off the major system management devices still exist on PCs.
> With ACPI the configuration is packaged with the hardware, with device tree it's not.
Eh, I've seen both options with both models. And ACPI being less declarative means that kernels have to ship larger patch tables to fix broken ACPI code. With device tree, a declarative approach means the drivers are free to fix issues in whatever way that kernel thinks is best.
> ACPI might be worse for certain reasons but it is more usable in practice.
I think it's easier to ship an MVP and forget about it than device tree, but device tree is easier to maintain over a long period.
>device tree is easier to maintain over a long period.
I don't really disagree, but for the most part all I've ever been able to buy are ARM boards with horrible support. If people aren't going to take up DT then it might be wise to find some middle ground.
Thanks for the insight. Are there some distros which have better support for ARM as a whole is really more a question of what distro has the best support for my specific ARM device?
What do you mean? The device tree is just a nested hash table, the interpretation of which is completely up to the device driver(s). If there is a limitation like you say, I guess it is fixable by patching the relevant driver?
The real root issue though is that ARM devices are generally built as "finished" products, so don't need to support pluggable hardware, meaning you can make assumptions about what pin on the SoC is used for each purpose, and exactly what it's connected to. This leads to kludges on phone handsets sometimes, where audio jack polarity is incorrect etc, and needs a board-specific driver hack. These hacks were often maintained in a board-specific kernel tree.
DTB certainly helps, but ARM devices are still (to some extent) quite hardware-specific. Moving towards UEFI bootloaders on ARM64 looks promising, and there are now "generic" ARM64 bootable images for some Linux distros.
Hopefully we'll see more use of a standard UEFI interface on ARM devices, so we can get towards having common bootable OS images, without board specifics needing handled by the OS!