This here is the important next step for ARM SBCs. A working UEFI. Maybe they can get together and standardize something they can work on together. But this whole SD card flashing nonsense needs to stop.
https://www.arm.com/architecture/system-architectures/system...
When the topic comes up some people express a lot of hatred for uefi (mostly users rather than implementors) but where it’s implementors the ms style APIs and so on are largely the center of it IME, and that’s not really an easy fix when it’s already spec’d. Sometimes there are concerns about size, but slimmed down deployments are common in the socs that ship already - perhaps standardizing on what that slimmed down thing is might help too. May also assuage some of the other concerns of excessive runtime services (which seems rare, but I get the existential concern)
People also rarely think of the complexity inherent in having an open platform where owner of a device does not need to build/acquire a custom OS build for their machine, and thus see cases of "enough to run something they care about" and think that's enough.
[0] I still remember BIOS config menus and PCI card option roms that effectively had stripped down windows 3.0 in them, or an approximation of it. And how it meant presence of Intel PCI hardware RAID controller in certain server meant I needed a full crash cart or remote KVM to fix RAID config.
SBSA standard in the server realm seems to have it figured out.
Manufacturers kind of suck at actually describing the hardware on their motherboards and hacks and workarounds are very much required to provide a usable experience on many machines.
Unless manufacturers stop lazily copy-pasting their DSDTs with minor changes, we should probably hope for a better solution.
On PC, the main check against it is Microsoft because they at least try to make vendors care with "Designed for Windows" and the like and their test suites.