After reading the responses to my "Philosophical question" it became clear
to me that what I was suggesting is more of a boot loader than a bios.
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.
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. 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.
What I am thinking is something along the lines of a layered approach.
* Boot loader only *
- Linux kernel could be loaded this way
---------------------------------------
Media: EEPROM BootDevice
Code: BootLoader -> OS
* Boot Loader & OS loader *
- Lilo (modified?) could be used this way
-----------------------------------------
Media: EEPROM BootDevice Any Device
Code: BootLoader -> OSloader -> OS
* BootLoader, BIOS and Legacy OS *
- Loads BIOS code from boot device to Shadow,
runs BIOS code (from Shadow) which then boots
legacy OS (such as DOS, Windows etc).
----------------------------------------------
Media: EEPROM BootDevice BootDevice
Code: BootLoader -> BIOS -> OS
* Boot Loader, BIOS, (Legacy OS support) and OSloader *
- Used on a system where multiple OS's must be supported.
BootLoader loads BIOS into Shadow, BIOS loads OS loader
which can be used to select which OS will be loaded.
---------------------------------------------------------
Media: EEPROM BootDevice BootDevice Any Device
Code: BootLoader -> BIOS -> OSloader -> OS
I guess my thinking here is that a boot loader will be a much simpler piece
of code to implement than a full scale BIOS. The first generation
development efforts would focus on providing good boot support for various
boot devices without the added burden of replicating (or inventing new)
BIOS API's.
During development we could use the copy of the BIOS that comes with all
motherboards (moving it to an image on disk) for legacy OS support. Once
the Boot Loader library and the tools needed to create a good OpenBIOS boot
EEPROM are working, efforts can be expanded to creating an open BIOS clone
for legacy OS support (assuming there is still demand for such a thing).
There is a good chance that M$ would make future versions of Windows
(when/if they abandon legacy DOS support) boot without a BIOS if the open
BIOS boot loader works well enough. Everyone wants to save a buck and if a
BIOS is not needed, I am sure the motherboard makers will be happy to ditch
it in favor of a smaller, free, OpenBIOS boot PROM. In the end there may no
longer be a need for the BIOS as we know it.
Then again we could take the path to create a new and improved BIOS model
that would be good enough to actually be used by modern OS's and
motherboard makers. But for that to happen we would have to gain some
credibility in the greater world by producing something that works and is
widely accepted.
Creating a library of boot code (and a system for managing and configuring
it for various hardware platforms) will be a significant challenge given
the number of possible motherboards and boot devices there are out there. I
propose that OpenBIOS boot code would be a good first step goal for a
modular open BIOS project.
Thoughts, comments?
Dave
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?
