[OpenBIOS] OpenBIOS: reality check

Pascal Dornier pdornier at pcengines.com
Fri Feb 20 09:39:08 CET 1998


The purpose of a BIOS is to create independence between hardware and
operating system.

A streamlined BIOS can be quite compact. For example, my own BIOS, tinyBIOS,
is about 10k lines of assembly source, < 16KB of object
code). The code is mostly 16 bit, with 32 bit code used where it
makes sense (e.g. memory test) or is required (32 bit PCI entries).
16 bit code is more compact.

Assuming no unnecessary delays, system startup time is dominated by
hard disk spinup time, and cannot be reduced any further.

If desired, custom boot loaders can be installed in the remaining
flash space. I've done this for one of my customers (they're using
their own non-UNIX kernel and file system).

> reentrant BIOS code so we can leave out drivers from the kernel(s)?

Why bother ? We're talking about a few KB worth of code. On some
platforms, execution out of BIOS space can be slower due to hardware
constraints (cacheability of BIOS space etc). If you try to keep this
code in the BIOS, you will have extra overhead for generic OS hooks
etc.

> On Systems with 4MBit Flash (are there any?): Kernel in Bios

What if the kernel gets any bigger ? Most boards have 1 Mbit or 2 Mbit
flash anyway.

> USB Support

Unless you need to boot through USB, probably bad idea. This belongs
in the OS.

> PCI/EISA/PnP Support

EISA ??? what's that <g> ?
ISA PnP should be implemented at the OS level, if at all.
PCI PNP is much simpler and more likely to be reliable.

> MSDos Filesystem code

A standard BIOS doesn't know about the file system, all it does is
load the first sector on the disk. The rest is up to the boot loader
of the operating system.

> repeat the same procedure for any cards which bring their own BIOS
> (SCSI, video, etc.)

Do you want to spend the rest of your life doing this ?

> obtain complete documentation on how you query SIMMs/DIMMs/etc.
> (including common bugs)

This is generally based on a trial and error detection procedure
(set biggest possible size, then find out how many address bits
really work), rather than presence detect bits.

> add some backward-compatibility interface for people needing DOS
> or one of its offsprings (Maybe not)

Highly desirable, DOS is a much easier environment for low level debug.

> implement some clever auto-configuration mechanism

Yes, this is key. Setup screens are evil. My BIOS doesn't have one.

Finally, who are you writing this for ? For the individual user, I
think it will be better to leave the BIOS on their system board
alone. The savings in boot time etc. will never pay back for the
effort spent playing with the BIOS.

For the industrial user (embedding Linux or FreeBSD in a custom
designed system), they can easily afford to license a commercial product
from the usual suspects (Award, AMI, Phoenix, Systemsoft, General Software,
moi). In volume, this can be as low as $0.10 per
unit. For small volume users, adaptation cost (either at the BIOS
vendor or on their side) will be higher than the license cost.

If you want to make the UNIX platform more suitable for embedded
use:

- Make the file system fault resilient. Existing boxes (e.g.
  http://www.whistle.com ) have to include a UPS to protect the
  file systems. Costs lots of money, and doesn't protect against
  software induced crashes.

- Flash file system support. Aggressively reduce size of minimum
  system (e.g. for routers). 1 MB = $5 or more. It's coming down,
  but slowly.

--------------------------------------------------------------------
Pascal Dornier   pdornier at pcengines.com     http://www.pcengines.com
Your Spec      + PC Engines            = Custom Embedded PC Hardware
--------------------------------------------------------------------



---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request at linkscape.net   Body: un/subscribe
Problems?  dcinege at psychosis.com



More information about the openbios mailing list