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?