4 ms·

How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all th

How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? 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? 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? I don't think the complaint is about complexity, but about code quality and architecture. This isn't the only case where an old, simpler but less capable and annoying, system has been replaced by a much more complex system that is much hated and [initially] buggy and less secure, but also more or less gets the job done better than the old way, and where average users of the new system find it easier and more productive. If there wasn't a case where a hardware manufacturer needed a capability prior to the OS taking over, or to modify their HW settings from the OS in a portable way, it wouldn't be in UEFI, right? Calling UEFI a full operating system seems needlessly inflammatory. It's not a linux or windows kernel. It has to do a fair amount of the basics, but so does any kernel running on a general purpose chip and interfacing with a bunch of other people's code. UEFI is terrible. Baseband firmwares are terrible. Security processor firmwares are terrible. AMT is terrible. Okay, but we still need them.

blueflow 2y ago
No, we don't need them. Look at the OpenWRT ecosystem and the routers it runs on. Those cheap plastic routers come with pretty dumb bootloaders and it works. Its just the x86 platform that is shite.
- kokada 2y ago
  However each OpenWRT router also has its own custom bootloader AFAIK. This is why you need different images for different devices, and can't create a single image for everything. UEFI on the other hand you just build one image and it works everywhere.
  - blueflow 2y ago
    > UEFI on the other hand you just build one image and it works everywhere. Thats the theory. Practice looks like that: https://lore.kernel.org/linux-efi/20200907170021.GA2284449@rani.riverdale.lan/ https://lore.kernel.org/linux-efi/20200907170021.GA2284449@r... If Vendors couldn't get the BIOS consistently right in the 80ies, why would they get UEFI consistently right now?
    - kokada 2y ago
      Yes, UEFI is messy, not saying you will never have issues. But on the other hand, in OpenWRT you literally need to build an image for each device, something that you (almost) never have to do with UEFI or BIOS. Or when was the last time you had to build a specific image for a x86_64 laptop? If this happened to you, I am curious, this would probably make a nice blog post. By the way, I am not saying that UEFI is not complicated, but there is probably a middle ground between "we need to build a specific image for this device because its bootloader is dumb" and "we have a f* operational system as a bootloader that works everywhere but is full of holes".
      - blueflow 2y ago
        > Or when was the last time you had to build a specific image for a x86_64 laptop? iwlwifi firmware blobs..
        kokada 2y ago
        This isn't related to UEFI itself though.
        blueflow 2y ago
        Not directly, but making bootable images is much easier if your firmware is stateless and does not require setup with efibootmgr.
        2y ago
AnthonyMouse 2y ago
> How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? 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.
- pixl97 2y ago
  And when you don't have an OS because you need to update the flash first?
  - jasonjayr 2y ago
    The flash updater IS the OS.
  - AnthonyMouse 2y ago
    You don't need to update the flash to boot an OS capable of updating the flash. The firmware it comes with can do that and if you've irrecoverably installed broken firmware then you've bricked your machine regardless.

blueflow 2y ago

No, we don't need them. Look at the OpenWRT ecosystem and the routers it runs on. Those cheap plastic routers come with pretty dumb bootloaders and it works. Its just the x86 platform that is shite.

kokada 2y ago
However each OpenWRT router also has its own custom bootloader AFAIK. This is why you need different images for different devices, and can't create a single image for everything. UEFI on the other hand you just build one image and it works everywhere.
- blueflow 2y ago
  > UEFI on the other hand you just build one image and it works everywhere. Thats the theory. Practice looks like that: https://lore.kernel.org/linux-efi/20200907170021.GA2284449@rani.riverdale.lan/ https://lore.kernel.org/linux-efi/20200907170021.GA2284449@r... If Vendors couldn't get the BIOS consistently right in the 80ies, why would they get UEFI consistently right now?
  - kokada 2y ago
    Yes, UEFI is messy, not saying you will never have issues. But on the other hand, in OpenWRT you literally need to build an image for each device, something that you (almost) never have to do with UEFI or BIOS. Or when was the last time you had to build a specific image for a x86_64 laptop? If this happened to you, I am curious, this would probably make a nice blog post. By the way, I am not saying that UEFI is not complicated, but there is probably a middle ground between "we need to build a specific image for this device because its bootloader is dumb" and "we have a f* operational system as a bootloader that works everywhere but is full of holes".
    - blueflow 2y ago
      > Or when was the last time you had to build a specific image for a x86_64 laptop? iwlwifi firmware blobs..
      - kokada 2y ago
        This isn't related to UEFI itself though.
        blueflow 2y ago
        Not directly, but making bootable images is much easier if your firmware is stateless and does not require setup with efibootmgr.
        2y ago

AnthonyMouse 2y ago

> How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? 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.

pixl97 2y ago
And when you don't have an OS because you need to update the flash first?
- jasonjayr 2y ago
  The flash updater IS the OS.
- AnthonyMouse 2y ago
  You don't need to update the flash to boot an OS capable of updating the flash. The firmware it comes with can do that and if you've irrecoverably installed broken firmware then you've bricked your machine regardless.