It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper on the system board if you like.

> How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot?

You give the OS access to the flash and then document what the bits do so the OS knows what to change.

> Granted, most of what goes on in a BIOS is displaying and changing variables involved in getting the system running, and maintaining those values, which just requires some sort of minimal editing interface and nv storage, but then... users appear. They want to be able to use a mouse. They want an ability to configure their raid chipset prior to boot, or netboot, and HW makers want to implement that in a way that's not some arcane raw assembly dance between BIOS and additional chip FW. What then?

Limit the firmware UI to extremely basic settings like "restore factory defaults" and "choose boot device", none of which need a mouse. Boot an OS to do anything more complicated.

> UEFI is terrible. Baseband firmwares are terrible. Security processor firmwares are terrible. AMT is terrible. Okay, but we still need them.

The reason these are all terrible is that they're supplied by the OEM. Delete all of them and replace them with hardware documentation that allows anyone to write their own. Ship the machine with an open source reference implementation that most people will never have to change unless it's terrible, in which case the 0.1% of the users that care will fix it and you can incorporate the fix into the reference implementation.

Its just the x86 platform that is shite.

Raw coreboot/uboot like approaches give you open source but closed platform - the simplicity means you need considerable resources to do something else than the original maker wanted to do with it.

UEFI (and before it, Microsoft attempts at semi-standardizing PC low level interfaces, effort on ACPI, etc) are an effort to provide an open platform no matter the opennes of code, availability of deep dive docs of individual computer models, and handling the fact that computers arez in fact, complex.

If you want a general purpose computer that explicitly targets the idea that it's owner can just plug in CD/USB/netboot a windows/Linux/BSD installer media, without waiting for new release just to have a bootable kernel on s new machine, there's s lot of inherent complexity. Especially if you want to be able to boot a version from before release of the board you're using without significant loss of functionality (something that devicetree cannot do without special explicit work from physical device vendor, but is handled by ACPI through bytecode and _OSI checks for supported capability levels from OS).

Especially if you also want to make it extensible and reduce cost in integrating parts from different vendors (aka why UEFI with hardcoded CSM boot started taking over by 2005).

It's much easier not just to integrate a third party driver for example for network chip when the driver will use well defined interfaces instead of hooking into "boot BASIC from ROM" interrupt, especially when the driver can then expose it's configuration in standard format that will work no matter if you have monitor and mouse connected or just serial port. Petitboot is not the answer - it's way worse when you have to custom rebuild system firmware to add drivers (possibly removing other drivers to make space) because you want to netboot from a network card from different vendor, or just because the hardware is still good but the NIC is younger. Much easier to just grab driver from OpRom or worst case drop it in standardised firmware-accessible partition.

Did I mention how much easier handling booting with UEFI is compared to unholy mess of most other systems? Yes, even GRUB on x86, which by default doesn't write standard compliant boot code so if you dual boot and use certain software packages you end up with nonbootable system. Or how many Linux installers and guides make partitions that only boot because of bug-compatibility in many BIOSes. Not to mention messing with bootsectors Vs "if you drop a compatible filesystem with a file named this way* it will be used for booting".

If I want to play around with booting a late 1960s design where you need to patch binaries if you change something in hardware, I can boot a PDP-10 emulator instead. I push for using UEFI properly because I have work to do and goals to achieve other than tinkering with booting, no matter how much I like tinkering in general

To the point that it's Microsoft who mandated a deviation from UEFI SecureBoot spec that enables owners to replace root of trust keys (Platform Key) in UEFI systems if the vendors wants that "designed for windows" sticker.

It also means you can bypass the mouse driven monstrosities from at least Dell by booting with console on serial port (for example through IPMI) - and all the same options are available, in vt-100 compatible form.

What relief after finding a server where the base bios was fine, but the intel raid card had its own SVGA+PS/2 mouse requiring setup interface... The mad scramble for a mouse to add to crash cart...

Because like most consumer PC parts, it's a race to the bottom low margin low wage business, usually offshored to Asia, that's only remotely profitable for the top 2-3 players who captured the market and optimized the costs, processes, development and supply chain to the max.

Why would anyone else want to enter such a market to compete for even lower profits?