The approach here for 64-bit ARM on servers has been to say "it must run UEFI". Then the vendor-specifics get dealt with by UEFI and ACPI, and the kernel can simply assume those facilities exist (and the distro can install new kernels in the usual UEFI way without having to know how to flash them into 500 different bootloaders). You can argue the merits and demerits of UEFI (and people do!) but there's a lot of benefit in pushing for "all server hardware must work like this".

I wish Google would mandate that with newer Android versions instead of this /vendor crap in Oreo. Microsoft mandated UEFI for their phones, but unfortunately their bootloaders are still locked. If they weren't though, it'd be a great standardized platform for alt OSes.

newer android versions of qualcomm are coming with uefi

Why not Coreboot?

There isn't much abstraction of the underlying hardware in coreboot, which can be either a good thing or a bad thing.

Why core boot? Uefi is open source (edk, tiano) if you make it so.

Coreboot is also very x86 centric last I checked.

Coreboot has some pretty solid ARM support too. Modern Chromebooks (both x86 and ARM) use Coreboot with a "depthcharge" payload. You can even use Libreboot at this point to bring up an RK3288, and boot into ChromeOS or a traditional linux. Even cooler is that if you do your own build of Coreboot, you can provide your own OS verification keys, and use vbutil to sign your own OS and have custom verified boot.

>> Coreboot is also very x86 centric last I checked.

Actually RISC-V is fully supported:

https://riscv.org/wp-content/uploads/2016/01/Tues1345-riscvc...

Real hardware coming soon...

Isn't UEFI way more complex? But I'm not sure if that's a problem because of Windows and all the drivers it has to support, or if it's a problem with the specification. I believe it was the latter? I think Google mentioned that in its recent talk on removing Intel ME.

UEFI is more complex but also nicer for management.

Developing a runtime on UEFI is easy to setup and get going, you don't have that feature in coreboot.

because uefi gives more than booting support, it also acts as firmware interface even after kernel has booted up. Kernel can continue to use uefi services for hw specific things which are abstracted via uefi interface

Very successful.

We're now in the 3rd generation of Arm servers, all built to the same set of specifications with multiple vendor SoCs by tens of different OEM/ODMs - SBSA (Server Base System Architecture) and SBBR (Server Base Boot Requirements).

The goal of these specs was to make these servers as "boring" as possible, i.e. as similar to an x86 server so that neither OEM/ODMs nor IT guys have to be able to distinguish between supporting an Arm or an x86 servers.

This means that you will be able to boot the same binary OS distribution on every machine. There are no more BSPs like in the old 32-bit Arm world. This means that the OS does not need to know anything about clock domains, pin muxes, GPIOs or DVFS beyond the standard facilities exposed via ACPI. Like x86, machine error handling is firmware-first. PCIe works the same way as on x86. AP core boot up and power off is abstracted through the PSCI (Power State Control Interface). TrustZone is not available for OS use and is purely used to implement resident portions of firmware (RAS error handling, PSCI, SDEI).

For people asking why UEFI and why ACPI, the answer is very simple: because that's what 99% of all deployed servers use. Using something else is just a friction point for the OEMs, ODMs, IHVs and firmware vendors. It would also be a friction for anyone consuming these systems. Sometimes, you have to be the adult in the room and say that you don't need an "ideal" solution, but the existing solution will work. Plus, the UEFI+ACPI world only really works when you are able to make all systems look more or less the same, hiding all the nitty-gritty shitty bus accesses (I2C for power buttons, SPI for flash, GPIO etc) completely in the firmware, not for the OS to care about. The OpenPower ecosystem didn't see this at all, and they have an elegant firmware solution (hostboot + skiboot + petitboot), but... why bother? It's yet another way to boot, and it just makes their systems foreign to 99% of everyone making and using servers. The OpenPower booting was basically built for Google, but the reality of Google is very different from the realities of the world.

How is uboot fundamentally different than BIOS or UEFI/EFI? It's not like all the PC clones through the ages had the same bootup sequence for RAM and peripheral init.

uboot is more striped down than traditional INT call based BIOS because it doesn't provide a boot API, or any "runtime" services. Basically it does little more than early hardware init, and jump to kernel image. For example it doesn't have an execution environment for option roms. Its great if your shipping a device with a fixed hardware configuration and kernel, but what ends up happening is that it fails to provide "platform" abstractions to the kernel. The result is constant churn at the platform level because even simple operations like "I want to boot this kernel/configuration on the next boot" cannot be communicated from the OS/kernel to the firmware in a standard way.

UEFI OTOH, is a bad combination of BIOS and openfirmware, but has standardized an execution environment that allows device vendors to build standalone "driver" packages that enable booting off plug-in network boards/RAID controllers/graphical display/etc.. Those drivers can then either be installed in the firmware or provided on option roms. There is a higher level API so that grub/whatever can say read a config file written by the OS without having to know the underlying technology.

Basically uboot is great for devices that could do without firmware and just boot a kernel, uefi is useful if you want to have a standard environment usable by a generic kernel/OS across a wide range of devices because combined with ACPI AML/etc it abstracts away much of the underlying platform management.

It's different because uboot typically resides on what I would refer to as "end-user" storage. If it booted from an on-chip or on-board flash/ROM device and then loaded content from the end-user's device, you're right -- in that case it would be remarkably similar to BIOS/UEFI.