4 ms·

> The question is why would you want to? To make it as easy as possible for people to transition from x86 to arm - having a compatible firmware interface means

by mjg59 4y ago

> The question is why would you want to? To make it as easy as possible for people to transition from x86 to arm - having a compatible firmware interface means you don't need to entirely rewrite your deployment tooling when you start deploying arm servers. > Your BIOS has a bunch of boot hooks that have to run before UEFI starts What? There is no BIOS on a UEFI system. > UEFI has to have all of its own drivers for storage and filesystems, just to load an OS kernel that has another driver suite. Well, yes, you need to have the ability to access the hardware that the OS is on in order to get to the OS. The only way you avoid that is to put the kernel in flash and jump to it directly, but then you're incompatible with existing general-purpose operating systems.

ajross 4y ago
> What? There is no BIOS on a UEFI system. This is... true, but only as an issue of semantics. There are absolutely duplicated framebuffer and storage drivers in the firmware of modern PCs (and probably TPM & CSME too, though that's not my world) (Edit: also USB and PS/2 input device handling). Those BIOS (yes, "BIOS" -- that's what the people who write it call it) splash screens aren't using UEFI, nor is the initial boot device selection in most cases I'm aware of. UEFI seems clean (well, cleanER) only when viewed from downstream.
- mjg59 4y ago
  > There are absolutely duplicated framebuffer and storage drivers in the firmware of modern PCs If you're using a desktop machine with a plug-in GPU, the driver for the GPU is carried on the card itself. That driver is implemented according to the UEFI specification. There's no way to initialise the hardware in order to display a splash screen unless you're already running the DXE layer (Driver eXecution Environment - there's a clue in the name), so the splash screen is absolutely using UEFI. For devices with on-board GPUs you could theoretically do something different, but I haven't seen any vendors shipping PEI drivers (they have a different header) and I've pulled apart a lot of firmware images in my time. Storage devices are subject to similar constraints (if you've got a plug-in SAS controller the firmware has no idea how to speak to anything attached to it until DXE time). Boot Device Selection is also part of the UEFI spec, and is one of the meaningful benefits of UEFI over legacy BIOS (eg, the OS being able to explicitly request what gets booted next through a generic interface). There is some potential duplication between the PEI and DXE layers, since you need to access the TPM (for example) in both phases, and also some storage code ends up in PEI because you need to handle stuff like self-encrypting drive unlock on resume and aren't going to execute any of the DXE layer. Looking through a real world UEFI tree, the only USB code in PEI is to support recovery from USB after a bad flash, and I can't find any input device handling there at all. So I'm honestly not sure what you're talking about. It could be that you're calling PEI "BIOS" and DXE "UEFI", but even then most of what you're describing doesn't seem to line up with real-world implementations. A lot of UEFI is ugly and overcomplicated, but pointing at something that only tries to solve a small subset of the problems (like the Chromebook implementation) as an example of how things should be done isn't really a great argument. UEFI is actually effectively solving two separate problems here - it's ensuring the hardware is in a well-defined state and also providing an environment for drivers to make use of that hardware. Both are required for booting a system, but only one is required for the resume path[1]. The ChromeOS firmware doesn't have to deal with any drivers or bootloaders or early boot code that isn't supplied with the device, so can skip a whole bunch of this. [1] Yes, ACPI does delegate most of this work to the OS, not to the firmware. But there's still a bunch of setup that needs to occur before handing control back to the OS - imagine the (real) case of an Intel SATA controller that can be configured to expose a legacy IDE compatibility interface, a spec-compliant AHCI interface, or a weird Intel-specific "RAID" interface. An OS using generic AHCI drivers has no idea about any of this, so it's up to the firmware to set the chip back up correctly before handing control to the OS. This is assuming traditional S3 - in S0ix environments we rely on runtime power management of the chip to get it to power consumption so low there's no benefit to actually powering off the chip and having to deal with reprogramming it from cold, and maybe once the entire world has transitioned to S0ix we can get rid of some of the complexity here.

by mjg59 4y ago

ajross 4y ago

> What? There is no BIOS on a UEFI system. This is... true, but only as an issue of semantics. There are absolutely duplicated framebuffer and storage drivers in the firmware of modern PCs (and probably TPM & CSME too, though that's not my world) (Edit: also USB and PS/2 input device handling). Those BIOS (yes, "BIOS" -- that's what the people who write it call it) splash screens aren't using UEFI, nor is the initial boot device selection in most cases I'm aware of. UEFI seems clean (well, cleanER) only when viewed from downstream.

mjg59 4y ago
> There are absolutely duplicated framebuffer and storage drivers in the firmware of modern PCs If you're using a desktop machine with a plug-in GPU, the driver for the GPU is carried on the card itself. That driver is implemented according to the UEFI specification. There's no way to initialise the hardware in order to display a splash screen unless you're already running the DXE layer (Driver eXecution Environment - there's a clue in the name), so the splash screen is absolutely using UEFI. For devices with on-board GPUs you could theoretically do something different, but I haven't seen any vendors shipping PEI drivers (they have a different header) and I've pulled apart a lot of firmware images in my time. Storage devices are subject to similar constraints (if you've got a plug-in SAS controller the firmware has no idea how to speak to anything attached to it until DXE time). Boot Device Selection is also part of the UEFI spec, and is one of the meaningful benefits of UEFI over legacy BIOS (eg, the OS being able to explicitly request what gets booted next through a generic interface). There is some potential duplication between the PEI and DXE layers, since you need to access the TPM (for example) in both phases, and also some storage code ends up in PEI because you need to handle stuff like self-encrypting drive unlock on resume and aren't going to execute any of the DXE layer. Looking through a real world UEFI tree, the only USB code in PEI is to support recovery from USB after a bad flash, and I can't find any input device handling there at all. So I'm honestly not sure what you're talking about. It could be that you're calling PEI "BIOS" and DXE "UEFI", but even then most of what you're describing doesn't seem to line up with real-world implementations. A lot of UEFI is ugly and overcomplicated, but pointing at something that only tries to solve a small subset of the problems (like the Chromebook implementation) as an example of how things should be done isn't really a great argument. UEFI is actually effectively solving two separate problems here - it's ensuring the hardware is in a well-defined state and also providing an environment for drivers to make use of that hardware. Both are required for booting a system, but only one is required for the resume path[1]. The ChromeOS firmware doesn't have to deal with any drivers or bootloaders or early boot code that isn't supplied with the device, so can skip a whole bunch of this. [1] Yes, ACPI does delegate most of this work to the OS, not to the firmware. But there's still a bunch of setup that needs to occur before handing control back to the OS - imagine the (real) case of an Intel SATA controller that can be configured to expose a legacy IDE compatibility interface, a spec-compliant AHCI interface, or a weird Intel-specific "RAID" interface. An OS using generic AHCI drivers has no idea about any of this, so it's up to the firmware to set the chip back up correctly before handing control to the OS. This is assuming traditional S3 - in S0ix environments we rely on runtime power management of the chip to get it to power consumption so low there's no benefit to actually powering off the chip and having to deal with reprogramming it from cold, and maybe once the entire world has transitioned to S0ix we can get rid of some of the complexity here.