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?

> 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.