> 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 drive

> 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.