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.
That is what the Arm SystemReady Compliance Program was supposed to achieve. Unfortunately not many manufacturers are following it yet
https://www.arm.com/architecture/system-architectures/system...
There is a UEFI standard in some of Arms specs, but it’s only mandatory for the server class IP atm. Some soc vendors are starting to adopt it even in non-server class but it’s slow. My feedback to an Arm devrel a few years ago was exactly this though: you need to provide a consistent standard boot path that also helps OS authors with enough bootstrap that debugging is less of a crapshoot every single time. I hope some progress is made on pushing that down the stack.
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)
- [deleted]
I don't understand the hatred for UEFI. It seems like people get irrationally disgusted when they find out that it's a big complex standard with lots of extraneous stuff that almost nobody cares about (on desktop, that is). Just give me text, a framebuffer, file system access, and a memory map. It's not difficult. Sadly I think that no one will be happy until there is some equally-overwrought spec on the ARM side.
People have rose-tinted glasses for BIOS, have no idea of all sorts of hidden complexity that was involved in it, assumptions, etc. Or all the broken ideas that vendors put into BIOS-era firmware [0].
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.
ARM SoCs have always been very proprietary and fragmented, and until/if something like the x86/PC comes along I don't think just UEFI is enough. The PC flourished because of many de-facto standards, and not just the BIOS. Unfortunately the companies these days seem to love their proprietariness, so I don't think something like that will happen again.
PC flourished, because IBM lost control, what is happening with ARM is basically what every other 8 and 16 bit home computers used to be.
And part of the lost control was emulating IBM PC enough that software that ignored sanity and did weird things to hardware or assumed certain behaviours worked even on clones and most importantly, upgrades
It's this. UEFI doesn't solve the problem of peripheral discovery, for example.
SBSA standard in the server realm seems to have it figured out.
Arguably, "full" UEFI implementation mandates use of ACPI, which solves discovery of components that don't have self-discovery mechanism to use (including finding the very roots of various self-discovering buses)
UEFI+ACPI+PCIE+XHCI pretty much covers everything you could want.
In theory yes, in practice ACPI isn't always a great solution (as can be seen by the many lines of kernel logs about broken DSDTs on my motherboard).
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.
Actually, I take that back. ACPI is fine except for the DSDT system, which should be nuked from orbit. These lazy PC hardware manufacturers keep pushing "please bro just let us run arbitrary code on your machine bro". This goes back to VGA BIOS (ugh). There's no need for it, other than the fact that it makes hardware vendor's lives slightly easier. Definitely something to avoid when designing a new interface.
There is no a better solution because "manufacturer loads broken description table" does not care for the technology of the description table, just that manufacturer borked it.
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.