Perhaps I can begin by introducing myself since I'm new to this mailing list before I make a comment and please pardon me while I think out loud.
My background is both hardware and software. I've worked on compilers and operating systems for main frame manufacturers until about 10 years ago at which time I started building pc hardware for various spacecraft. I guess I've seen both ends.
I have been frustrated by the "trade secret" mentallity that pervades the PC business. In order to gain competitive advantage, manufacturers (Award, AMI, Microid Research, Phoenix and most of all Microshaft) have kept the inner workings of operating systems and bios's a secret to stifle the competition. I can say that with certainty that if a company got an IBM, a Univac, a Control Data, a Cray or what have you mainframe, they got an operating system and system software from the same company. And the form that the software was delivered in was source, binaries and link libraries (all three, not just one). When a customer had a problem with a machine, he sat down with the customer engineer and went over the problem, usually by referring to the source code of the operating system. I know, I've worked both sides. Many, many times it was customer system programmers that would rewrite sections of the operating system to solve their local problems and would then give the code to the vendor who would then make similar changes to the vendor source and pass it on to other customers. The IBM customer organizations SHARE and GUIDE served as conduits.
This is what pleases me about linux and now this group. With so many eager minds working at these system components, maybe we can get some good source code.
Now to reply to the email.
I believe the model of a layered boot is the correct one to implement. It is the model implemented on all computers that I have worked on including PCs. The only difference is that the boot itself was usually layered.
Let me give an example from the IBM mainframe world. The mainframe computers had I/O channels and therefore DMA. The channels were controlled by a 64 bit channel command word. A series of channel command words made a channel program which could the direct an entire sequence of I/O operations.
To boot the mainframe, a channel/device address was inserted into a predefined channel command word. The channel command word directed the device to read the first block of data at that address into memory via DMA and to begin execution at the beginning of the block. (In therory, one could boot from a punch card reader, a keyboard, tape drive or a disk drive. All he needed was the time and patience to enter the binaries. In fact, I once had a punch card deck with the binaries to boot any IBM mainframe.) This was layer one. The only function of layer one was to get layer two into memory.
The function of layer two was to load the operating system and then terminate.
AFIK, this is how the PC boots. The bios enters, performs system checks, initializes pointers and tables and then loads the master boot record. The master boot record is record 0 of track 0. The front of the master boot record is the partition table and the rear of the master boot record is a short piece of code which tells how to load the next part of the operating system. (This system was so primitive on early PCs that IBMIO.SYS had to begin at record 1 of track 0 or else it couldn't be found)
It's not too surprising that it should work that way because of IBM's influence in the early PC market. I can only spectulate that because XT's had only floppy drives and floppies were of such limited capacity at the time (Does anyone else remember 180k drives?) that it was necessary to hide some of the operating system (bios) in the boot EPROM so as not to fill the floppy. The pre x86 machines (8080, 8085 z80) did the same thing because of lack of floppy space.
With all of that history, I like the model
--------------------------------------------------------- Media: EEPROM BootDevice BootDevice Any Device Code: BootLoader -> BIOS -> OSloader -> OS
The EEPROM has four necessary functions that I can identify: Self test of the motherboard. The chipset dependent functions. These are really unique to the motherboard. For speed and efficency, copy the os independant portion of the kernel to shadow ram. Loading layer 1 of the boot.
Layer 1 (in the MBR) finds the active partition and loads the os boot from that partition (LILO, NTLOADER, IBMIO.SYS ...).
The drive and partition could be parameters passed to the boot loader. This is already a function performed by most bios's in the setup but could include functions now included in add on's such as System Commander in the DOS/Windoze world or Lilo/Loadlin in the Linux world.
And this is where it becomes complicated because there are several divergent paths, each with their own set of problems.
If I ruled the world, all device drivers would be OS independant and would be loaded by layer 2 as TSR's along with the OS independant portion of the kernel. But unfortunately, Microshaft uses different drivers for each version of Windoze and Linux and DOS also have different driver versions and where Linus might be cooperative, Bill Gate$ isn't going to be.
Another problem is that Windoze 9x insists on having its own version of the MBR. So that anything put there will soon be replaced if the user chooses to install WIN 9x.
Since very few users install an OS, and those that do are presumably computer literate, this may not be too much of a problem. One solution would be to have user reinstall the MBR as WIN NT users must now do if the choose to have both on the same PC (double the pain, double the hell) and add modules to the WIN 9x library to load the remaining os dependant part of the kernel into shadow RAM following the os independant part and to perform self test of the non motherboard user added devices such as vidio cards, ethernet cards et cetra.
In fact, a very simple procedure would be to copy the current BIOS EEPROM contents to a 128k file (BIOS.OLD?) which would be loaded to shadow ram on booting up the PC. That change alone would allow motherboard manufacturers to save a few cents per motherboard by replacing Flash EPROMS with less expensive and never changing PROMs. And it would be very easy to switch bios's and test new bios's (BIOS.OLD, BIOS.NEW, BIOS.TST, BIOS.001 possibly as input to layer 2 passed from layer 1 as a parameter in a register)
For Linux and other intelligent operating systems, the second layer shouldn't be too much of a problem.
At 06:13 PM 2/8/99 -0500, you wrote:
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?