[MisterTea]

And I'd happily run them if the hardware situation wasn't so damn grim. There's no Arm booting standard so you have to re-invent the kernel for each model of chip vs just booting an x86 PC and let the kernel poke at discoverable hardware and figure it out. Arm has old-school ISA like configuration for your non-discoverable hardware with devicetrees preventing generalized kernels from existing.

Someone please make open booting and hardware configuration for a general OS on Arm a reality. Without standard booting I feel that open source OS phones will never exist. They're always behind on driver development leaving users with buggy battery murdering devices that are missing features. Dev's don't want to bother with messy alpha quality platforms. They move slow as they don't have FAANG money so the platforms never gain momentum. Simple general booting will change that - no more recompiling a kernel using some byzantine labyrinth build system - just write an image to SD or USB and boot.

[sunk1st]

Please expand on “devicetrees [prevent]… generalized kernels from existing,“ if you don’t mind.

[MisterTea]

I am wrong there, they describe non-discoverable hardware so they are useful.

I am confusing them with the issue of getting a kernels built for a lot of the poorly documented hardware that varies a bunch which device trees try to solve but don't. No two vendors agree on how to boot things. I cant just download ubuntu or even openbsd for my phone or tablet as each of those has its own boot loader. Too splintered of a platform.

[sunk1st]

Thanks for your response. It’s an interesting perspective. From my point of view the idea of having incompatible boot protocols is a feature, not a bug. Fundamental differences must exist at some point in the hierarchy. Why not the boot mechanism?

[MisterTea]

> Why not the boot mechanism?

The SoC is its own static architecture - each vendor sells its own little computer system complete with booting methods. Since the hardware is static there is no need to implement a configuration mechanism which also acts as a discovery mechanism (like PCI). So we can't build a kernel that asks the SoC "Whats inside", instead, the device tree is a list of what hardware exists and where it is mapped in memory.

And that hardware might not be standard or use weird register layouts that don't match other commonly used layouts in other similar devices further complicating the porting effort. The SoC might have a unique USB controller or Ethernet MAC or whatever that needs a new driver. Just lots of duplicated effort for each "new computer" when its all the same hardware inside. And its like this because SoC's are low cost disposable chips - no one cares if you cant port a new kernel because by the time you want a new kernel the thing is already obsolete and expected to be disposed of and replaced with a new gadget.

What could be done? Setting standards for hardware registers - similar to how PC vendors like Intel and Microsoft standardized the dumb basics like ATA, USB, Ethernet, Serial ports and so on. Set standards so we don't need to re-write drivers for every new chip released. Then standardize the boot firmware so the device can boot-strap the hardware to the point where it can load a kernel image via a debug interface, thumb drive, emmc, sd etc. Let the device boot hand the OS its device tree - done.