4 ms·
The problems are: * "Show the user interface" implies that you need a way to render to the screen. Rendering to the screen implies a graphics driver. Since o
by AshamedCaptain 6y ago
The problems are:
* "Show the user interface" implies that you need a way to render to the screen. Rendering to the screen implies a graphics driver. Since on many architectures the user can change the graphics hardware, you need a Plug&Play system where drivers for graphic cards can be loaded dynamically (e.g. from the PROM in the graphics card itself, and yes, EFI does this) . You need to be able to set resolutions, control multiple plugged in monitors (otherwise your BIOS output is sent to your HDMI connected projector only rather than your primary monitor).
* "when I press F2": to read keyboard input implies a full USB stack with HID support. Bluetooth keyboard? You need a USB stack again, HCI support, capability for storing non-volatile data such as the pairing key for the keyboard, and either the UI to pair stuff or at least a tool to edit the pairing information once the system is booted (likely not a hit with users).
* "Boot from a DVD" implies a Serial ATA stack, ATAPI possibly full SCSI stack. ISO9660 support, plus FAT32.
* "Boot from a USB" implies USB host support, likely USB 1, USB2/EHCI, and USB3/xHCI support -- unless you want your pendrive to work on some ports and not others, or some pendrives to work and not others. Also support for the multiple mass storage protocols such as Mass Storage or UAS (again, full SCSI stack), and support for FAT32, exFAT, likely NTFS since a lot of people use it, etc.
* And then comes the bells & whistles that most users also want, which suprisingly at this point actually add very little complexity. Fancy graphics support, mouse support (you already have HID driver, so why not?), sound support (cause most devices don't have a plain speaker anymore, if you want even simple beeps you have to use the sound card, which requires drivers like HDA, codec drivers, etc. And yes, Macs do this.), crypto functions for full disk encryption support, OPAL, secureboot, etc.
* Also most users want their BIOS to present devices in a abstract way, i.e. so that your kernel is able to render to a framebuffer on an ARM server board with the same code it uses to render to a framebuffer on more standarized x86.
All of this at this point already requires a operating system-level of complexity. So you end up with a BIOS that resembles an operating system -- EFI.
tldr: BIOS are complicated because they have to abstract hardware, and hardware has become complicated.
- billpg 6y agoFair points. I'll accept the F2 interface only working on a standard keyboard with a basic monitor port and a restricted selection of USB devices. Needing to use it at all is an exceptional case that only techies need understand. Sound, fancy graphics, mouse, disk encryption. These can all be delegated to the OS loaded from the hard disk. You don't need any of these in the BIOS. The reason for wanting a simple BIOS is so it can be protected from being modified by malware. That's the prize. I'm not saying there won't be costs, but I think the benefits outweigh them significantly. I've had my desktop machine for something like five years and its worked fine without ever needing a BIOS update. It can boot up a live-USB copy of Linux quite happily, but if I ever add a set of future-USB ports that the BIOS doesn't know about, I'll have to be content to using the old USB ports on the motherboard just to get the alt-OS started.
- userbinator 6y ago"Show the user interface" implies that you need a way to render to the screen. Rendering to the screen implies a graphics driver. VGA text mode should always be available. You need to be able to set resolutions, control multiple plugged in monitors (otherwise your BIOS output is sent to your HDMI connected projector only rather than your primary monitor). Sane defaults help a lot here --- like all outputs enabled (and showing the same thing), and of course 80x25 text mode. and support for FAT32, exFAT, likely NTFS since a lot of people use it, etc. Load first sector of boot device to 7c00h and jump to it. The code there can use int 13h to load the rest. BIOS doesn't need to have any knowledge of the filesystem to do that, nor should it. Also most users want their BIOS to present devices in a abstract way, i.e. so that your kernel is able to render to a framebuffer on an ARM server board with the same code it uses to render to a framebuffer on more standarized x86. Approximately zero users care about ARM having the same BIOS as x86. and hardware has become complicated. Not all of that complication is necessary, however. USB and ATAPI boot, as well as PXE (network boot) was been around long before UEFI reared its ugly head. I bet the amount of space taken up by the (IMHO totally unnecessary and definitely not wanted if you're in the CMOS SETUP to fix something with the GPU not working right) graphics in UEFI setup is far more than an entire pre-UEFI BIOS with all the other features.
- AshamedCaptain 6y ago> VGA text mode should always be available. Surprise: it's not. Even on PC hardware there are cards right now that will not render VGA modes correctly, or on all monitors. And what if you have two VGA cards? It's more common these days to have two VGA cards rather than one, and you simply have no way to use two cards simultaneously with standard PC VGA. > Not all of that complication is necessary, however. Sure, but it is there, and the dream of going back to a platform where everything is standarized at the IO register level is just wishful thinking.
- deleted 6y ago[deleted]