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)
SBSA standard in the server realm seems to have it figured out.
For example, right now I have an old armhf i.MX6 Wandboard Quad that runs:
U-Boot -> UEFI (with Secure Boot if desired) -> Systemd Boot (or Linux EFI Boot Stub) -> Debian (or other distro)
Some arm devices such as the i.MX6, are strict on the placement of their boot firmware where it would interfere with a normal GPT table. One solution to this is to use a special "--move-main-table" option in gdisk² so that the GPT doesn't clobber U-Boot. While technically GPT is optional as long as U-Boot can read your main partition, I still always setup GPT anyway or Systemd Boot complains.
Honestly, my opinion after all this was that UEFI is pretty convenient and nice, and I'm glad U-Boot has its own implementation, even if it isn't fully grown yet; UEFI for the executable spec with a DTB for bringing up the SOC with nothing else was nicer than a lot of embedded boot flows I've handled.
¹ https://en.wikipedia.org/wiki/GUID_Partition_Table#Features
¹ https://u-boot.org/blog/seeing-is-believing-video-support-la...
I find it amazing that ARM hasn't come up with an auto-discovery mechanism for their platforms. They're the only ones in a position to do it, and they've done exactly nothing about it. The device tree junk we have to live with is here to stay.
The U-Boot situation is really no better. Nearly every vendor ships with U-Boot, and it's always, always a fork that never gets updated. ARM should have taken that situation in hand decades ago, too.
UEFI does make things a lot easier. It's a shame that this isn't more common for Arm boards, but it's good to see things heading in the right direction.
Or something 3D-printed...
Or did you mean the height of the ports on the backside itself is too large for 1U already?
The metal back panel is standard. It'd be nice to have one that's made to fit 1U cases.
Just look on Android phones - i.e. Lineage OS, special Android build for every phone. That would not be necessary if booting process would the same.
UEFI makes it so you can boot your Unix OS, like NetBSD, without needing to have specific bootblocks that are tailored to the given machine. You can move drives between Arm machines, too. Much simpler.
Like the entire HII thing, with an UI toolkit!
There is also a specification[2] on how UEFI is to be implemented.
0. https://github.com/riscv-non-isa/riscv-server-platform/relea...
This is a radical departure from the abstraction-on-abstraction that is implicated by BIOS/UEFI but it feels like it would make the whole architecture not feel like a fossil once it's out of the vendor's hands.
This would mean that every OS would need to make an implementation and feels like wasted effort, however, looking at all the BIOS bugs that i encountered which were OS specific, I have to say I'd rather see OS specific implementations than having to convince your vendor that you hit a bug which happens to be on a OS other than Windows or an ancient redhat patched Linux kernel.
[1]: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...
ACPI even included "compatible interface discovery" to handle the possibility that newer features might confuse older OSes without requiring end user to install newer OS (which they might not want to for various reasons) which used to be the norm. I owned a ~1994 UNIX workstation whose manual came with explicit instructions "you need to use at least this specific emergency upgrade version or the OS won't boot". PPC macs despite OpenFirmware had the same issue, because OpenFirmware had no such "interface discovery" mechanism allowing varying interface according to OS being run - it could only specify compatible device identifiers, which was not enough.
Also, you often need (a bit less today, but still important in server systems) considerable amount of vendor-specific drivers in firmware just to get to the OS.
Of course you can also go the completely other way, and implement always-virtualized environment like some IBM POWER systems, where the CPU wakes up with all of hardware already initialized and instruction pointer pointing to hypervisor scheduler loop.