Hi!
Sorry for the long message, but, please, read it and make comments!
On Mon, 8 Feb 1999, Dave wrote:
I still think this is a good approach. Separate the BIOS functionality (standard interface to the hardware) from the boot loader. The reasoning behind separating the two is that 1) a good BIOS would be as much OS dependent as it is hardware dependent. 2) Modern operating systems do not currently take advantage of the services provided by the BIOS.
That's quite right. The role of the BIOS changed while the OSes migrated from DOS-based (BIOS compatible) to PM 32bit OSes. And exactly this is the chance for OpenBIOS, to fill the gap introduced by modern hardware (and software and other topics like authentication) not supported until the OS is loaded.
Let's first return to what the BIOS was for, a few years ago.
The BIOS was there to hide hardware details from the OS, to provide a OS-compatible constant API to use the hardware. At first, every component plugged into the motherboard, and of course, the motherboard itself, provided an own BIOS for its own setup and functions. Long, long time ago, we had multi-I/O-cards with a BIOS on it, providing interfaces to floppy, harddisk, serial and parallel communication, for the optional real-time-clock, etc. The BIOS on the motherboard was small and provided basic operations to use main memory, to "collect" the other BIOSes and to load the operating system.
BIOS benefit changed a lot while the system of BIOS integration and interfacing didn't move an inch. Why? Simply: Even DOS allowed "drivers" to be loaded by the OS, even for block devices. But these block devices were at first thought to provide an own BIOS. Well, of course, it was (and is) cheaper to provide (and update!) a driver than a PROM on board. So, drivers for CD-ROMs, tapes and other devices occured besides the BIOS idea, but they were (speaking only of the block device drivers) BIOS compatible (though enhancing their functionality here and there).
After that "good old" DOS times, we got "Windows" providing a nearly total replacement for (a) the BIOS services and (b) the DOS-based device drivers. Until recently, a lot of people used DOS although Windows was born because either they didn't have hardware to run Windows on or their favourite software was working after all and not ported to Windows.
Nowadays, ignoring DOS, we have _only_ Windows 98 in need for a BIOS providing more than a kernel (or additionally a few driver files like with NT). That means, that BIOS either HAS TO CHANGE to fit the needs of the OSes to have any purpose after booting, or it should at least provide a service to support the hardware in a better way it did until now to enable booting f.e. from any media or other topics I raised already.
But: What's wrong with BIOS nowadays? What exactly is the gap OpenBIOS can fill? And: What are the benefits of BIOS16?
Let's start with the benefits of BIOS16: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
G1) It's supported by all PC OSes.
Well, as mentioned earlier, just a few API calls are in fact needed nowadays; the rest is done by driver replacement etc.
G2) It's supported by the hardware manufacturers.
Think of: your VGA card providing its own BIOS, think of your newly bought SCSI controller: You plug them in, and at least you (a) see a picture on the screen and (b) can boot an operating system from it (of course, you need a driver to use it under the operating system as well).
G3) Enhancement of the BIOS is easy.
The hardware manufacturer, or the programmer of his BIOS, can rely on the API it uses and provides. In addition, new hardware or functionality can be implemented just by programming a BIOS providing the needed functionality (think of a network remote-boot program or user authentication).
G4) The BIOS is standalone.
You don't need any data on a media to boot. One can simply take a floppy or a harddisk or a CD-ROM and boot/install his favourite OS. This is in fact very important for booting when f.e. the one and only hard disk has lost its "magic smoke" and one has to initialize his system.
Now, what's wrong with BIOS16? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
B1) One needs a BIOS chip somewhere to enhance the BIOS.
That's why, for example, one cannot boot from a parallel ZIP drive. If the motherboard would support f.e. a large EEPROM one can write some boot drivers into, we could boot in a lot more ways we can do nowadays. Of course, we could simply design a new ISA or PCI card to provide only a BIOS (large enough for anything one could want to do, say, 1MB or so).
B2) the BIOS is useless once you have bootet the OS.
Well, except for the already-mentioned DOS and Win9x which rely on the BIOS16 even nowadays. The current BIOS is (a) 16bit real mode, (b) not reentrant and (c) interrupt based.
B3) The BIOS consists not only of the API.
For performance and other reasons, OS developers can rely on that f.e. the CMOS data have the well-known structure (instead of accessing BIOS functions for that) or that VGA display starts at address 0xA0000 (as I think).
B4) The API is very hardware near.
Think of Cylinders/Heads/Sectors ... even if harddisks are layed out that way even nowadays, not every cylinder has a constant amount of sectors etc. To introduce an alternative way of booting, f.e. remote boot over the network, the BIOS has to implement the whole boot process resulting in either a large BIOS chip or very primitive functionality for that (of course, the latter is what we have as the main remote boot protocols).
B5) The BIOS, in fact, does not know what it does booting the system.
The main and only purpose of the BIOS was (and is until now), to load the first sector (remember, that is 512 bytes) from the first (or otherwise specified) boot device and to execute it. The only validation done (well, to verify that the sector loaded is intended as a executable piece of code) is the check for 0x55 0xAA for the last two bytes of that sector.
Partitioning is not part of the BIOS, it's done by the MBR in a way not allowing more than one primary partition (i.e., one can boot from and access randomly, AFAIK), what means, one has to change the partition sector to select the boot device.
Boot viruses were spread widely until the 32bit OSes could not be harmed by them other than by disabling the boot process or corrupting data in a way it was recognized very quickly.
So, what's OpenBIOS for (AKA feature list)? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
F1) input/output/intermediate/control device flexibility.
input device: harddisk, network, parallel port ZIP, ... output device: VGA, HGC, serial, network, ... intermediate device: SCSI controller, PCI bridge, network adapter, serial port, chip card reader, keyboard controller, data encryption interface, partitioning system, network protocol, ... control device: human behind keyboard, authentication agent, network, ...
The devices should be able to interact in nearly every possible way.
F2) OS independent drivers.
Well - a point to discuss. Since a main part of every OS is the way drivers are called and programmed, this would mean that OpenBIOS would lead all (interested) PC OSes to a common way driver calls and programming is done. Since OS- and driver development is very fast evolving, I think that this would just be as useful as a compatibility mode like BIOS16 calls under Win9x, but of course, useful to every modern PM 32bit OS. But keep in mind, that we only have 128 kB (typical) for all drivers, so I think we have to limit on the really needed parts and interfaces, etc. for booting.
And: Why? I mean, the only benefit of using the drivers contained in the BIOS is to not being forced to load its OS-specific pendent for the OS. Well - is this a problem of any kind? I mean, of course, it can be some if one doesn't get a driver for his favourite OS.
F3) Support for "intelligent devices".
There's a main difference between devices storing data and devices able to compute or interact in any other way. From the BIOS point of view, this dynamic way of communication (for example, authentication, remote boot, remote administration) and the appropriate way of implementation could be a main feature of OpenBIOS.
F4) Authentication (user).
Providing an authentication mechanism, OpenBIOS could prevent booting without an authenticated user sitting in front of the PC (or communicating with any other "intelligent device", for example, over the network).
F5) Authentication (boot block).
This mechanism could be used in other way, too: A non-"intelligent device", i.e. the boot block itself (block device), could have to authenticate itself TO THE BIOS. I don't know whether one can get this bullett-proof (think of the turing machine and the related axiom), but the idea is great, I think.
F6) Compression.
Not a main detail, but interesting in any way.
F7) Encryption.
A main topic as security becomes relevant more and more. Of course, related to (F4) and (F5). Needed for any media which can be harmed by someone and for any media where the transmission of data can be (a) listened to and (b) modified (or even faked).
F8) Flexible and hierarchically selectable boot device selection.
A typical IDE boot control file could look like:
----------------- Boot:=PCI(0,3):ISA:Legacy_IDE(0,UDMA):Partition(1):BootLoader(Linux_OpenBIOS) -----------------
For example, the boot control file for a remote boot client could contain the following lines:
----------------- Auth_Client(BootServer):=Table(PublicKeys,our_famous_server) Boot:=PCI(0,4):RTL8139(10BaseT,HalfDuplex):IPV6(enableDHCP6):DHCP6(Linux_kernel_for_me):Security(BootServer):BootLoader(Linux_OpenBIOS) -----------------
In addition, we would have a system control file, like:
----------------- InputDevice:=PCI(0,2):ISA:Legacy_8042:AT102(german,ISO-8859-1) Monitor(my_19_inch_cube):=Table(Monitordata,Samsung_900p) OutputDevice:=Duplicate(OutputDevice_2):PCI(0,5):RivaTNT(my_19_inch_cube,text,100,43):TermOut(ISO-8859-1) OutputDevice_2:=PCI(0,3):ISA:Legacy_16550(0,9600,8N1):TermOut(US-ASCII) -----------------
Of course, there is a lot more to configure, etc. and there would be something like boot device selection menu in the boot control file, and, of course there would be a nice configuration utility to construct this data for us. If the EEPROM is large enough, we could implement something like a boot device selection browser to help us search for bootable devices. Of course, this is just the idea of an idea :-) and will need a large BIOS because all relevant modules would have to be in it.
But how should OpenBIOS deal with the advantages of BIOS16? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D1) Support by the OSes.
Of course, this is a major problem when being incompatible to BIOS16. Linux f.e. would be no problem, not only because it's OSS but because it just needs the kernel to boot. NT needs some drivers (like Linux modules) additionally _before_ booting the kernel, and I think, the loading is done with BIOS16 calls.
D2) Support by hardware manufacturers.
The second problem. At first, the support is done by ourselves, like with Linux where the least HW manufacturers supply native Linux drivers. Trying to be compatible to Linux driver sources could be our chance to have a lot of hardware being compatible to OpenBIOS at first.
Of course, we could try to be compatible to BIOS16 not only to provide DOS etc. to boot, but also to let hardware prividing BIOS16 BIOS to get a place in our structure. Of course, this would blow up code and make our BIOS like Win9x using both 32bit and legacy BIOS drivers.
D3) BIOS extensions.
Well, They should be possible, I think. More: We could use BIOS chips located in VGA or SCSI cards to contain the appropriate OpenBIOS drivers (of course, this would make them incompatible to BIOS16) instead of the BIOS16 code.
D4) The BIOS is standalone.
Of course, this could (and will) be a main problem (and is discussed already heavily). Either we try to make it standalone and take the risk of having the OpenBIOS not to fit into EEPROM, or we remove more and more benefits of OpenBIOS to reach the goal. To have main BIOS functionality on harddisk is dangerous in any way. Harddrive defect, new hard drive, virus, security, diskless workstations, etc.
For an operating system that comes with its own drivers (that work directly with the hardware) there is little or no need for a BIOS that provides API's to the hardware.
Agree, but for the BIOS (or boot loader) itself, we need the APIs.
The only need for a so called BIOS is to initialize the hardware to the point that it can read from the boot device and load the OS (or an OS loader) into memory. For legacy OS's (Dos, Windows) that require a BIOS, the Boot Loader can load a BIOS from the boot device directly into Shadow Ram and execute it as if it where copied from EEPROM to Shadow Ram.
Thought of that: Then we have a problem using the CMOS for our purposes (Q: What do we need to be configured dynamically?)
PS. A couple of you have mentioned Open Boot. Where can I find out more about it? Is Open Boot open as in open source or open as in marketing-buzzword "open". Could this be used as the boot loader part of the project? Is it something that we could build on?
I found something on the SUN server I think. Search there for it. I think it's of no use for us at least because the sources are not free.
Winscheichwos, - Matthias