How's the BIOS so clever?

[onlyonemac]

Hi!

I haven't posted for a while but the other day I was thinking about a stark difference between the BIOS and us operating system developers. You see, we always struggle to support every different kind of hardware that could possibly exist, yet whenever there's a BIOS function to do something it will probably be able to do it with whatever hardware you supply. And now what I can't work out is how come BIOSes are so able to work with any kind of hardware.

I know BIOSes are developed commercially, but I still don't think any company will have resources to produce a BIOS that will work with absolutely any hardware. And I know Linux can work with most hardware, but then Linux has an enormous team of programmers (by several orders of magnitude larger than most teams of BIOS developers). Now what I'm wondering is if the compatibility offered by BIOSes is because only a limited range of hardware will work with a given PC's internal hardware, so there's no need to spend time developing support for hardware that will never work with the PC's internal hardware (as opposed to osdevvers who don't know what hardware their users could have). However, most BIOSes these days are designed to work on a wide range of motherboards - surely the manufacturers don't package up a custom-modified BIOS image for every make and model of motherboard?

This just puzzles me because it seems like there's an obvious solution to versatile hardware compatibility, but at the moment it's only known to BIOS developers.

Any ideas?

Thanks,

onlyonemac

[iansjack]

A particular BIOS is designed to run with a particular motherboard whereas an OS is designed to run on many different hardware configurations. So the BIOS writer has an easier task (inasmuch as that level of development can ever be called easy) than the OS writer. Any ancillary components will have their own BIOS to hook into the motherboards BIOS.

A BIOS performs a particular task with a well-defined set of hardware, so I wouldn't say it is that clever. Try flashing a motherboard with a BIOS designed for another motherboard and see what happens. You might not consider it so versatile then.

[SpyderTL]

Most of the stuff that the BIOS does just happens to not need specific device information. During startup, it is mainly responsible for taking information from one known source (say the PCI bus), and copying it to a known memory location in a known format (say, the APCI tables).

As for the more complex stuff, there are several standard APIs that can be used to communicate between the BIOS and devices, like VESA, PXE, PCI, USB, etc. These must be supported by the hardware, so that the BIOS and the hardware can agree ahead of time how they will communicate. Using nothing but these standard APIs, the BIOS can do a lot of initialization by itself, and for more complicated things, like SCSI controllers, the BIOS uses PCI to "notify" the hardware that it needs to initialize itself, which gives the hardware the ability to "install" it's own "event handlers" to "extend" the default BIOS functionality.

Still, it is amazing that it all works as well as it does. There are several open-source BIOS projects that you can check out to see what happens beneath the covers if you are really interested.

http://www.seabios.org

[onlyonemac]

A particular BIOS is designed to run with a particular motherboard whereas an OS is designed to run on many different hardware configurations.

That is exactly what I was thinking.

Any ancillary components will have their own BIOS to hook into the motherboards BIOS.

I didn't think of that; I seem to remember I read that somewhere a long time ago...

This just puzzles me because it seems like there's an obvious solution to versatile hardware compatibility, but at the moment it's only known to BIOS developers.

The solution is to package up a different version of our operating system for every motherboard . Seriously is there not a way for us to tap into the BIOSes of the "ancillary components" so that we don't have to try and reverse-engineer every single piece of hardware? (Perhaps Linux could do that too then...)

[Rusky]

The solution is to package up a different version of our operating system for every motherboard . Seriously is there not a way for us to tap into the BIOSes of the "ancillary components" so that we don't have to try and reverse-engineer every single piece of hardware? (Perhaps Linux could do that too then...)

DOS tried that already. Coming from the other direction, if you write a coreboot payload you can use the same drivers in the early boot and when fully booted.

[Brendan]

Hi,

I haven't posted for a while but the other day I was thinking about a stark difference between the BIOS and us operating system developers. You see, we always struggle to support every different kind of hardware that could possibly exist, yet whenever there's a BIOS function to do something it will probably be able to do it with whatever hardware you supply. And now what I can't work out is how come BIOSes are so able to work with any kind of hardware.

BIOS doesn't support that much hardware. For example, it doesn't support:

• Sound input or output (other than PC speaker)
• Video (it's provided by the video card's ROM)
• Networking (it's provided by the network card's ROM)
• IO APICs (not used at all)
• HPET (not used at all)
• IOMMUs (not used at all)
• Game controller/s (joysticks, etc)

In addition; for the hardware it does support, often it's using crusty/slow legacy modes (e.g. basic PIO for hard disks, rather than the full NCQ with bus-mastering/DMA, etc).

Also; the code is simpler than the corresponding code you'd expect in an decent OS, because:

• there's no protection/isolation (other than being in "hard to modify ROM")
• no support for multiple CPUs (excluding setting MTRRs and populating ACPI tables)
• no support for multi-tasking
• very little memory management
• very simple user interface
• no file system/s
• no disk cache/s
• no need for good performance for anything
• poor fault tolerance (e.g. not even basic exception handlers that work - if anything goes wrong then crash/reboot)

Basically; it only has to be "bare minimum" code that's able to start an OS (and is only used for less than 5 seconds); and none of it is actually good (for any definition of "good" - features, performance, fault handling, etc).

Finally, BIOS developers don't write everything from scratch for every motherboard. Instead, they'd have "generic BIOS code" and customise a few things to suit the chipset/motherboard. The majority of the code would be code that has evolved over the last 30+ years. Some things (e.g. RTC and PIC code) may have been untouched for several decades, some things (e.g. USB support) might have been added 15+ years ago. The amount of "new and untested" code for a motherboard is likely to be very little.


Cheers,

Brendan

[tehmav]

You could take a look at coreboot.
Very interesting project, definitifly worth a look (especially at the source )