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@pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware --------------------------------------------------------------------
--- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com