[OpenBIOS]: Pros & Cons

[Matthias Wächter]

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

-- 
Der Wein mit der Pille ist in dem Becher mit dem Fächer.
-----------------------------------------------------------------------------