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?
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?
I'm a little confused with the following design:
Media: EEPROM BootDevice BootDevice Any Device Code: BootLoader -> BIOS -> OSloader -> OS
Is the intention to have much of the BIOS code on the hard drive with only the minimal amount of code on the EEPROM? This sounds like a design IBM did years ago (ever heard of microchannel?). There are a number of problems with this design, the biggest being that the user can accidentally delete the BIOS portion on his/her hard drive and completly trash the system. I would disagree with using this design.
Sincerely, Eric R. Kern
I see two clear fractions here. One that, like me, wishes to create a full, complete BIOS with all the functions that goes with it (keyboard, video, storage etc). And one that supports the minimalistic approach with just a bootloader in the Flash ROM. How should we deal with this? Should we make two seperate versions of OpenBIOS? Or should we join our efforts in making one, very flexible and configurable BIOS? Any other ideas?
I think that, when considering the bootloader approach, you miss two vital parts of the BIOS, the I and the O. To be classified as a BIOS (in particular, OpenBIOS), in my opinion it should atleast support some form of input and output system. Otherwise you are left with BS (perhaps Booting System?). There is nothing wrong with this, and I can clearly see some merits of that, but as I said, I don't classify that as a BIOS. Perhaps there should be a subproject of OpenBIOS called OpenBS?
(Flameshield suit - ON ;)
/ Niklas Ekström
On Mon, 8 Feb 1999, Ed Brinker wrote: <snip>
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.
<snip>
On Tue, 9 Feb 1999, Niklas Ekström wrote:
I see two clear fractions here. One that, like me, wishes to create a full, complete BIOS with all the functions that goes with it (keyboard, video, storage etc). And one that supports the minimalistic approach with just a bootloader in the Flash ROM. How should we deal with this? Should we make two seperate versions of OpenBIOS? Or should we join our efforts in making one, very flexible and configurable BIOS? Any other ideas?
I think we should make it flexible and support both. If you just want the B and the S, you say so when you configure/compile it (maybe a selection that hides all other options when selected). If you want more, you say so. I think this should be possible. People that want the minimalistic thing work on that part, and people who wants more features, like I and O can work on those features. Together we make the fantastic thing called OpenBIOS! :)
Karl Erik _______________________________________________________________
Karl Erik Asbjornsen Tlf: 73837153 / 90738663 Utleirvn 11 karlea@samfundet.no 7033 Trondheim, Norway http://www.samfundet.no/karlea _______________________________________________________________
Sorry, I don't have my Mark IV flame thrower with me.
I agree with your point in that there are two extremes of approaches to the problem and one's personal preference probably depends on the problems one would like to solve with the BIOS and perhaps some confusion between the functions of a boot loader and a BIOS. Both are necessary. The question I am posing is just how much of the BIOS should be made loadable.
As I said, my background is both hardware and software.
My hardware hat has (is) grumbled about the limitations that a BIOS imposes on the operation of a PC. For example, when running in a pure DOS mode, I don't need the capabilities of a 1600x1200 3D graphics card. What I need is just the capability of a VT220 type serial terminal. I have had situations where the only spare vidio card was a super vga card with bad memory and I wanted to run DOS. Rather than booting into DOS with a serial terminal, I had to swap vidio cards with another PC.
Not every PC is used as an office business terminal or juniors game station. Most PC's are used as POS terminals or simple controllers. You just don't see these advertised in the PC mags. These system almost always run an embedded DOS and don't need the capabilities required in many of the current BIOS's. In fact, they might be cheaper and more reliable without them. And any universal, configurable BIOS should reflect those end users also.
While this may seem an extreme example to some, I was looking at an elevator control system several days ago which was 386 PC based. The manufacturer had installed a vidio card and terminal because the PC wouldn't boot with them.
As another example, I was looking at a server "Black Magic" built by Dresselhaus Computers (www.dresselhaus.com). The server was based around a standard 4 slot ISA motherboard. The only function of the server was to act as a LAN router. To keep the cost low, the manufacturer had modified the BIOS so as not to use any vidio terminal or hard drive. The server sdimply booted up and began executing what was pointed to by the boot record on the floppy drive. Ther server had no hard drives, no vidio capability, a 10 base t ethernet card and an internal modem card. It was, IMHO a simple way to use a PC.
I only use these examples to point out that a configurable BIOS/Boot Loader must be exactly that, configurable. And I only know of three ways of making a configurable BIOS.
The first is a very modularized ROM based BIOS with a number of conditional executions.
The second is to provide a source code rich in conditional macros or include statements which would be compiled/assembled by the manufacturer/hacker and burnt into the (E)(EE)PROM.
The third would be to make a loadable, segmented BIOS.
Each approach has it's pros and cons. The first is universal but at the expense of ROM space. It requires the least amount of customer interaction.
The second most closely fits the curent BIOS distribution model but requires that a knowledgable person make the final configuration after which the BIOS becomes unchangable.
The third is the most flexible but will require the most knowledge in the place least likely to find it, the end user.
A fourth approach would be to make some parts (or all) of the BIOS loadable or reloadable. That is, to provide a "boot" BIOS embedded containing some subset of functions necessary and sufficient to boot the OS in ROM and another superset of functions that would or could reconfigure the system to take advantage of the unique hardware configurations. For example, I have a 486 computer with a caching HD controller (a TEKRAM 2277). That particular controller is a hell of a lot faster and more efficient than the embedded controller on my K6-2 SOYO motherboard on the PC I am now using. I would like to optimize or change the Microid Research BIOS on the 486 mother board to only use the 2277 supplied drivers but under the ROM only BIOS, I can't.
My hardware hat prefers the third approach. My practical side knows that the second approach is most like to be widely received by the PC community. Maybe I can hope for the fourth.
At 11:52 PM 2/9/99 +0100, you wrote:
I see two clear fractions here. One that, like me, wishes to create a full, complete BIOS with all the functions that goes with it (keyboard, video, storage etc). And one that supports the minimalistic approach with just a bootloader in the Flash ROM. How should we deal with this? Should we make two seperate versions of OpenBIOS? Or should we join our efforts in making one, very flexible and configurable BIOS? Any other ideas?
I think that, when considering the bootloader approach, you miss two vital parts of the BIOS, the I and the O. To be classified as a BIOS (in particular, OpenBIOS), in my opinion it should atleast support some form of input and output system. Otherwise you are left with BS (perhaps Booting System?). There is nothing wrong with this, and I can clearly see some merits of that, but as I said, I don't classify that as a BIOS. Perhaps there should be a subproject of OpenBIOS called OpenBS?
(Flameshield suit - ON ;)
/ Niklas Ekström
On Mon, 8 Feb 1999, Ed Brinker wrote:
<snip> > 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.
<snip>
At 11:52 PM 2/9/99 +0100, you wrote:
I see two clear fractions here.
I do not see the two as being mutually exclusive. If we take a modularized approach, keeping in mind that the long term goal may be to create a complete BIOS, then building a boot-prom is still a reasonable first goal.
One still has to test/init the hardware and boot the system, wether or not you plan on providing API's by loading them from PROM to shadow, loading them from disk to shadow or assuming that API's are not needed because the OS has its own drivers (i.e. Linux and NT).
Dave
At 09:29 AM 2/9/99 -0500, you wrote:
Is the intention to have much of the BIOS code on the hard drive with only the minimal amount of code on the EEPROM?
That is what I was thinking. I think this approach makes it much easier to modify, update and experiment with the BIOS.
We could design the boot prom to try to boot from a primary bios image file. If the boot was unsuccessful, the next boot would occur from the backup binary image file. Thus you would be free to experiment with modifying the primary binary image and always know that you can still recover on the next boot if your experiment was less than successful.
There are a number of problems with this design, the biggest being that the user can accidentally delete the BIOS portion on his/her hard drive and completly trash the system.
But how is this different than the user deleting any needed file from their system. In either case they will have to boot from a recovery disk (or other backup media) and restore a missing file. The BIOS image is just another file that would have to be restored if it was deleted.
Dave
On Wed, 10 Feb 1999, Dave wrote:
At 09:29 AM 2/9/99 -0500, you wrote:
Is the intention to have much of the BIOS code on the hard drive with only the minimal amount of code on the EEPROM?
That is what I was thinking. I think this approach makes it much easier to modify, update and experiment with the BIOS.
What if you don't have a hard drive? I don't like this approach.
Karl Erik
_______________________________________________________________
Karl Erik Asbjornsen Tlf: 73837153 / 90738663 Utleirvn 11 karlea@samfundet.ntnu.no 7033 Trondheim, Norway http://www.samfundet.ntnu.no/~karlea _______________________________________________________________
On Wed, 10 Feb 1999, Dave wrote:
At 11:52 PM 2/9/99 +0100, you wrote:
I see two clear fractions here.
I do not see the two as being mutually exclusive. If we take a modularized approach, keeping in mind that the long term goal may be to create a complete BIOS, then building a boot-prom is still a reasonable first goal.
I don't see why that should be a good idea. If building a BIOS is what we want, then that is what we are going to do. Building a boot loader in between will just make it possible for us to get caught in the old got-to-keep-compability trap. I want to make this right the first time. Then there will be no need to make stupid technical compromises, just because we didn't think about something that comes later with the BIOS part.
After all we are "only" talking about a total of 128kB of code and data. Lets aim to make a complete BIOS and see that we get there within resonable time. This should be no more than 6 months from now, I think. What we need to do is: * Specify exactly what functionality we want * Make up a good way of modularizing the whole BIOS * Write func. spec. (function specification) for all functions in all modules * See that all the modules fit and that there are no bugs in the design * Implemtent it all
I know we can do this. We just have to focus on a single target so that everyone pulls in the same direction. Sure, we can discuss what this target should be, but lets make it quick. Personally (not that I think anyone cares what I think, but anyway) I don't feel that I have the time to discuss _what_ we should do for much longer. Lets move on to discussing _how_ we should do it.
(Btw. If you (Dave) want a bootloader just to test/experiment with a BIOS without having to flash the ROM, I suggest you use the LOADBIOS app instead. You can get it from the OpenBIOS homepage.)
/ Niklas Ekström
hi,
I think, one question we have to clarify is, what OS we want to run above our BIOS.
1. If it will be MS-DOS or Windows, we have to make the BIOS compatible to the standard IBM BIOS. There won't be much room for an own/better API. It would be a very tedious work to copy the whole interface.
2. If it will be Linux, we don't need the I and the O, a simple boot loader which initializes the hardware will do the job. You could think of the Linux Kernel as a very sophisticated BIOS, which adapts the hardware to a comfortable API (glibc) :)
Because the whole project is complex (think of all the chipsets, we had to care for and other hardware differences from an simple embedded 386EX to a Pentium II with PCI and AGP), I don't think, we can manage (1.) in half a year. If we concentrate on a simple, good, flexible boot loader, we could get a running system in finite time. For legacy OS's, I like the approach to load a legacy BIOS with this simple boot loader.
If we later want the I and the O, would it be possible to strip down a (already for many hardware platforms configurable) Linux Kernel? The aim would be then, to sepearate Linux in a hardware dependent and a hardware independent part. The hardware dependent part could migrate to a kind of BIOS, the hardware independent to a Linux Kernel, which don't have to be configured for a special platform any more. Big project anywhere, I think.
Opinions?
Corvin
--- Corvin Zahn zahn@zac.de
Hi!
Sorry for the long message, but, please, read it and make comments!
On Mon, 8 Feb 1999, Dave wrote:
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.
That's quite right. The role of the BIOS changed while the OSes migrated from DOS-based (BIOS compatible) to PM 32bit OSes. And exactly this is the chance for OpenBIOS, to fill the gap introduced by modern hardware (and software and other topics like authentication) not supported until the OS is loaded.
Let's first return to what the BIOS was for, a few years ago.
The BIOS was there to hide hardware details from the OS, to provide a OS-compatible constant API to use the hardware. At first, every component plugged into the motherboard, and of course, the motherboard itself, provided an own BIOS for its own setup and functions. Long, long time ago, we had multi-I/O-cards with a BIOS on it, providing interfaces to floppy, harddisk, serial and parallel communication, for the optional real-time-clock, etc. The BIOS on the motherboard was small and provided basic operations to use main memory, to "collect" the other BIOSes and to load the operating system.
BIOS benefit changed a lot while the system of BIOS integration and interfacing didn't move an inch. Why? Simply: Even DOS allowed "drivers" to be loaded by the OS, even for block devices. But these block devices were at first thought to provide an own BIOS. Well, of course, it was (and is) cheaper to provide (and update!) a driver than a PROM on board. So, drivers for CD-ROMs, tapes and other devices occured besides the BIOS idea, but they were (speaking only of the block device drivers) BIOS compatible (though enhancing their functionality here and there).
After that "good old" DOS times, we got "Windows" providing a nearly total replacement for (a) the BIOS services and (b) the DOS-based device drivers. Until recently, a lot of people used DOS although Windows was born because either they didn't have hardware to run Windows on or their favourite software was working after all and not ported to Windows.
Nowadays, ignoring DOS, we have _only_ Windows 98 in need for a BIOS providing more than a kernel (or additionally a few driver files like with NT). That means, that BIOS either HAS TO CHANGE to fit the needs of the OSes to have any purpose after booting, or it should at least provide a service to support the hardware in a better way it did until now to enable booting f.e. from any media or other topics I raised already.
But: What's wrong with BIOS nowadays? What exactly is the gap OpenBIOS can fill? And: What are the benefits of BIOS16?
Let's start with the benefits of BIOS16: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
G1) It's supported by all PC OSes.
Well, as mentioned earlier, just a few API calls are in fact needed nowadays; the rest is done by driver replacement etc.
G2) It's supported by the hardware manufacturers.
Think of: your VGA card providing its own BIOS, think of your newly bought SCSI controller: You plug them in, and at least you (a) see a picture on the screen and (b) can boot an operating system from it (of course, you need a driver to use it under the operating system as well).
G3) Enhancement of the BIOS is easy.
The hardware manufacturer, or the programmer of his BIOS, can rely on the API it uses and provides. In addition, new hardware or functionality can be implemented just by programming a BIOS providing the needed functionality (think of a network remote-boot program or user authentication).
G4) The BIOS is standalone.
You don't need any data on a media to boot. One can simply take a floppy or a harddisk or a CD-ROM and boot/install his favourite OS. This is in fact very important for booting when f.e. the one and only hard disk has lost its "magic smoke" and one has to initialize his system.
Now, what's wrong with BIOS16? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
B1) One needs a BIOS chip somewhere to enhance the BIOS.
That's why, for example, one cannot boot from a parallel ZIP drive. If the motherboard would support f.e. a large EEPROM one can write some boot drivers into, we could boot in a lot more ways we can do nowadays. Of course, we could simply design a new ISA or PCI card to provide only a BIOS (large enough for anything one could want to do, say, 1MB or so).
B2) the BIOS is useless once you have bootet the OS.
Well, except for the already-mentioned DOS and Win9x which rely on the BIOS16 even nowadays. The current BIOS is (a) 16bit real mode, (b) not reentrant and (c) interrupt based.
B3) The BIOS consists not only of the API.
For performance and other reasons, OS developers can rely on that f.e. the CMOS data have the well-known structure (instead of accessing BIOS functions for that) or that VGA display starts at address 0xA0000 (as I think).
B4) The API is very hardware near.
Think of Cylinders/Heads/Sectors ... even if harddisks are layed out that way even nowadays, not every cylinder has a constant amount of sectors etc. To introduce an alternative way of booting, f.e. remote boot over the network, the BIOS has to implement the whole boot process resulting in either a large BIOS chip or very primitive functionality for that (of course, the latter is what we have as the main remote boot protocols).
B5) The BIOS, in fact, does not know what it does booting the system.
The main and only purpose of the BIOS was (and is until now), to load the first sector (remember, that is 512 bytes) from the first (or otherwise specified) boot device and to execute it. The only validation done (well, to verify that the sector loaded is intended as a executable piece of code) is the check for 0x55 0xAA for the last two bytes of that sector.
Partitioning is not part of the BIOS, it's done by the MBR in a way not allowing more than one primary partition (i.e., one can boot from and access randomly, AFAIK), what means, one has to change the partition sector to select the boot device.
Boot viruses were spread widely until the 32bit OSes could not be harmed by them other than by disabling the boot process or corrupting data in a way it was recognized very quickly.
So, what's OpenBIOS for (AKA feature list)? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
F1) input/output/intermediate/control device flexibility.
input device: harddisk, network, parallel port ZIP, ... output device: VGA, HGC, serial, network, ... intermediate device: SCSI controller, PCI bridge, network adapter, serial port, chip card reader, keyboard controller, data encryption interface, partitioning system, network protocol, ... control device: human behind keyboard, authentication agent, network, ...
The devices should be able to interact in nearly every possible way.
F2) OS independent drivers.
Well - a point to discuss. Since a main part of every OS is the way drivers are called and programmed, this would mean that OpenBIOS would lead all (interested) PC OSes to a common way driver calls and programming is done. Since OS- and driver development is very fast evolving, I think that this would just be as useful as a compatibility mode like BIOS16 calls under Win9x, but of course, useful to every modern PM 32bit OS. But keep in mind, that we only have 128 kB (typical) for all drivers, so I think we have to limit on the really needed parts and interfaces, etc. for booting.
And: Why? I mean, the only benefit of using the drivers contained in the BIOS is to not being forced to load its OS-specific pendent for the OS. Well - is this a problem of any kind? I mean, of course, it can be some if one doesn't get a driver for his favourite OS.
F3) Support for "intelligent devices".
There's a main difference between devices storing data and devices able to compute or interact in any other way. From the BIOS point of view, this dynamic way of communication (for example, authentication, remote boot, remote administration) and the appropriate way of implementation could be a main feature of OpenBIOS.
F4) Authentication (user).
Providing an authentication mechanism, OpenBIOS could prevent booting without an authenticated user sitting in front of the PC (or communicating with any other "intelligent device", for example, over the network).
F5) Authentication (boot block).
This mechanism could be used in other way, too: A non-"intelligent device", i.e. the boot block itself (block device), could have to authenticate itself TO THE BIOS. I don't know whether one can get this bullett-proof (think of the turing machine and the related axiom), but the idea is great, I think.
F6) Compression.
Not a main detail, but interesting in any way.
F7) Encryption.
A main topic as security becomes relevant more and more. Of course, related to (F4) and (F5). Needed for any media which can be harmed by someone and for any media where the transmission of data can be (a) listened to and (b) modified (or even faked).
F8) Flexible and hierarchically selectable boot device selection.
A typical IDE boot control file could look like:
----------------- Boot:=PCI(0,3):ISA:Legacy_IDE(0,UDMA):Partition(1):BootLoader(Linux_OpenBIOS) -----------------
For example, the boot control file for a remote boot client could contain the following lines:
----------------- Auth_Client(BootServer):=Table(PublicKeys,our_famous_server) Boot:=PCI(0,4):RTL8139(10BaseT,HalfDuplex):IPV6(enableDHCP6):DHCP6(Linux_kernel_for_me):Security(BootServer):BootLoader(Linux_OpenBIOS) -----------------
In addition, we would have a system control file, like:
----------------- InputDevice:=PCI(0,2):ISA:Legacy_8042:AT102(german,ISO-8859-1) Monitor(my_19_inch_cube):=Table(Monitordata,Samsung_900p) OutputDevice:=Duplicate(OutputDevice_2):PCI(0,5):RivaTNT(my_19_inch_cube,text,100,43):TermOut(ISO-8859-1) OutputDevice_2:=PCI(0,3):ISA:Legacy_16550(0,9600,8N1):TermOut(US-ASCII) -----------------
Of course, there is a lot more to configure, etc. and there would be something like boot device selection menu in the boot control file, and, of course there would be a nice configuration utility to construct this data for us. If the EEPROM is large enough, we could implement something like a boot device selection browser to help us search for bootable devices. Of course, this is just the idea of an idea :-) and will need a large BIOS because all relevant modules would have to be in it.
But how should OpenBIOS deal with the advantages of BIOS16? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D1) Support by the OSes.
Of course, this is a major problem when being incompatible to BIOS16. Linux f.e. would be no problem, not only because it's OSS but because it just needs the kernel to boot. NT needs some drivers (like Linux modules) additionally _before_ booting the kernel, and I think, the loading is done with BIOS16 calls.
D2) Support by hardware manufacturers.
The second problem. At first, the support is done by ourselves, like with Linux where the least HW manufacturers supply native Linux drivers. Trying to be compatible to Linux driver sources could be our chance to have a lot of hardware being compatible to OpenBIOS at first.
Of course, we could try to be compatible to BIOS16 not only to provide DOS etc. to boot, but also to let hardware prividing BIOS16 BIOS to get a place in our structure. Of course, this would blow up code and make our BIOS like Win9x using both 32bit and legacy BIOS drivers.
D3) BIOS extensions.
Well, They should be possible, I think. More: We could use BIOS chips located in VGA or SCSI cards to contain the appropriate OpenBIOS drivers (of course, this would make them incompatible to BIOS16) instead of the BIOS16 code.
D4) The BIOS is standalone.
Of course, this could (and will) be a main problem (and is discussed already heavily). Either we try to make it standalone and take the risk of having the OpenBIOS not to fit into EEPROM, or we remove more and more benefits of OpenBIOS to reach the goal. To have main BIOS functionality on harddisk is dangerous in any way. Harddrive defect, new hard drive, virus, security, diskless workstations, etc.
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.
Agree, but for the BIOS (or boot loader) itself, we need the APIs.
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.
Thought of that: Then we have a problem using the CMOS for our purposes (Q: What do we need to be configured dynamically?)
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?
I found something on the SUN server I think. Search there for it. I think it's of no use for us at least because the sources are not free.
Winscheichwos, - Matthias
Let's start with the benefits of BIOS16:
G1) It's supported by all PC OSes. G2) It's supported by the hardware manufacturers. Think of: your VGA card providing its own BIOS, think of your newly bought SCSI controller: You plug them in, and at least you (a) see a picture on the screen and (b) can boot an operating system from it (of course, you need a driver to use it under the operating system as well).
Can we use any of this code which is in these cards for BIOS16 support? It would easen up the memory requirements.
G4) The BIOS is standalone. You don't need any data on a media to boot.
This sounds like an OpenBIOS feature :-) We could create somekind interface for adding custom modules. Some programs might fit directly to same EEPROM with OpenBIOS.
So, what's OpenBIOS for (AKA feature list)?
F1) input/output/intermediate/control device flexibility. input device: harddisk, network, parallel port ZIP, ... output device: VGA, HGC, serial, network, ...
What is HGC?
F3) Support for "intelligent devices". There's a main difference between devices storing data and devices able to compute or interact in any other way. From the BIOS point of view, this dynamic way of communication (for example, authentication, remote boot, remote administration) and the appropriate way of implementation could be a main feature of OpenBIOS. F4) Authentication (user).
This would also open possibilities for user profiles. Instead of just returning "user authenticated", the server could say "User ok. Please boot from network image server:filename:params". It might also be usefull if the authentication could be passed to the operating system underneath.
F5) Authentication (boot block). This mechanism could be used in other way, too: A non-"intelligent device", i.e. the boot block itself (block device), could have to authenticate itself TO THE BIOS. I don't know whether one can get this bullett-proof (think of the turing machine and the related axiom), but the idea is great, I think.
Why limit this to just boot block? I think that at least the file (kernel) should be authenticated. One rather bullet-proof method could be using md5 checksums stored in NVRAM. checksum matches -> boot loader will be allowed to continue.
This would enable one to boot from insecure media (like floppy disk) in a public area and still be rather secure. It would also be usable when booting from net.
F6) Compression. Not a main detail, but interesting in any way.
Might be usable when booting from serial line :-)
F7) Encryption. A main topic as security becomes relevant more and more. Of course, related to (F4) and (F5). Needed for any media which can be harmed by someone and for any media where the transmission of data can be (a) listened to and (b) modified (or even faked).
Not true with b) since it's possible to detect modifications using authentication.
F8) Flexible and hierarchically selectable boot device selection. A typical IDE boot control file could look like:
Boot:=PCI(0,3):ISA:Legacy_IDE(0,UDMA):Partition(1):BootLoader(Linux_OpenBIOS)
Could you explain this format a bit?
It would be nice to be able to pass parameteres to boot loader. Boot loader would then pass them to the kernel which is beeing loaded.
If we want to replace entire boot loader (like LILO) then we would need a way to boot from different files. This might be possible to implement without including file system support in BIOS.
It could be done using utility which would run under the operating system. The utility would store the starting point and the length of the boot image (kernel) in NVRAM.
Sun's OpenBoot has some neat features. One of them is dev-aliases.
Here is an example:
boot /iommu@f,e0000000/sbus@f,e0001000/espdma@f,4000/esp@f,80000/sd@3,0
Quite long, isn't it. I'm not certain what t /iommu is, but I think that it refers to the motherboard itself since as I understand it some sparc architectures allow multiple motherboards (with 2 or 4 cpu's / board). Sbus refers to the expansion bus, esp refers to scsi-controller and sd to scsi disk, @3,0 refers to scsi id 3 and lun 0.
I think that we should think something as configurable as that.
OpenBoot allows this to be written as:
boot /iommu/sbus/espdma/esp/sd@3,0 and I think that if you have only one disk, you can use command: boot /iommu/sbus/espdma/esp/sd
You need the longer version only if you happen to have multiple SCSI-controllers or SBUS'es etc.
Since that's quite hard to remember, OpenBoot allows you to define alias for that device and then you can use commands like boot disk boot disk1 boot net boot tape
or even the feared: boot floppy
In addition, we would have a system control file, like:
InputDevice:=PCI(0,2):ISA:Legacy_8042:AT102(german,ISO-8859-1) Monitor(my_19_inch_cube):=Table(Monitordata,Samsung_900p) OutputDevice:=Duplicate(OutputDevice_2):PCI(0,5):RivaTNT(my_19_inch_cube,text,100,43):TermOut(ISO-8859-1) OutputDevice_2:=PCI(0,3):ISA:Legacy_16550(0,9600,8N1):TermOut(US-ASCII)
Aarghh! Yet another place to configure your monitor. But you are right, BIOS would seem to be the correct place to do it. This would allow us to use fixed-frequency monitors more easily, but it could also create problems. But to be really useful this information should be made possible to obtain while running some OS.
I'm beginning to see that there is some need for bios after the kernel has booted. I can almost see the light :-)
If the EEPROM is large enough, we could implement something like a boot device selection browser to help us search for bootable devices. Of course, this is just the idea of an idea :-) and will need a large BIOS because all relevant modules would have to be in it.
I don't think this to be a problem. We just need multiple user interfaces, one basic which is as small as possible and then really fancy for those of us who have enough EEPROM available.
But how should OpenBIOS deal with the advantages of BIOS16?
D2) Support by hardware manufacturers. Of course, we could try to be compatible to BIOS16 not only to provide DOS etc. to boot, but also to let hardware prividing BIOS16 BIOS to get a place in our structure. Of course, this would blow up code and make our BIOS like Win9x using both 32bit and legacy BIOS drivers.
I don't think that we should mix bios16 stuff with the rest of the OpenBIOS. I'd say that bios16 should be as separate as possible from the "real stuff" so that it wouldn't ruin the design. I'm not at all certain wether this kind of separation is possible, so please comment.
D3) BIOS extensions.
Well, They should be possible, I think. More: We could use BIOS chips
located in VGA or SCSI cards to contain the appropriate OpenBIOS drivers (of course, this would make them incompatible to BIOS16) instead of the BIOS16 code.
In future all devices will have OpenBIOS drivers in their BIOS chips :-) Definetly worth supporting. Perhaps somekind of model for dual support might be nice so that a device could have both: OpenBIOS code and bios16 code.
D4) The BIOS is standalone. Of course, this could (and will) be a main problem (and is discussed already heavily). Either we try to make it standalone and take the risk of having the OpenBIOS not to fit into EEPROM, or we remove more and more benefits of OpenBIOS to reach the goal. To have main BIOS functionality on harddisk is dangerous in any way. Harddrive defect, new hard drive, virus, security, diskless workstations, etc.
I don't think that removing features from OpenBIOS only because we need bios16 support is an option. I think that we should make OpenBIOS modular and make it _support_ module loading from hd. Since we already decided (?) to have somekind of authentication for bootblock why coudn't we use authentication for modules as well?
If bios16 would be seperate module, it wouldn't be vital to have it in order to get the system boot. It would be required only if the user wishes to run OS which doesn't support OpenBIOS. I wouldn't recommend storing modules in HD. I think that this is much better way than not beeing able to use bios16 at all.
In addition I think that Bios16 might not be needed on older machines since you can't run w95/nt with them. More likely old 486's are used as servers which run linux or some other free unix.
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.
Thought of that: Then we have a problem using the CMOS for our purposes
Another tought: how much NVRAM we have to store our data? Encryption keys and boot loader configuration take some space..
A couple of you have mentioned Open Boot.
I found something on the SUN server I think. Search there for it. I think it's of no use for us at least because the sources are not free.
Even if there is no source to be copied we might want to copy some ideas from OpenBoot. I think that we should compare BIOS/bootloader features used in other systems before deciding what to include in OpenBIOS.
Comments, anyone?
Hi,
We could create somekind interface for adding custom modules. Some programs might fit directly to same EEPROM with OpenBIOS.
This definitely seems like the best option, we can just generate code to use modules in flash, and look at the possibility of loading additional modules from secondary storage if/when we start to fill up typical flash ROMs.
BTW all the machines I have access to at the moment have either 128k, or 256k flash ROMs, if you write efficient code, then it will take a long time to use up all this storage - it's not that long ago that most of my computer's operating system (including GUI) came in a 256k ROM.
If we want to replace entire boot loader (like LILO) then we would need a way to boot from different files. This might be possible to implement without including file system support in BIOS.
I would definitely like ext2/vfat support as an option for my BIOS, I use GRUB, (http://www.uruk.org/grub/), as my boot loader, and find this invaluable. The 'Multiboot Standard' which is linked to from this page might also be worth a look. Having the ability to load a set of kernel modules (which are needed at boot time) prior to boot-strapping the kernel seems like the most flexible way of doing things to me.
I don't think that we should mix bios16 stuff with the rest of the OpenBIOS. I'd say that bios16 should be as separate as possible from the "real stuff" so that it wouldn't ruin the design. I'm not at all certain wether this kind of separation is possible, so please comment.
Does anyone know what support services (if any) a typical VGA BIOS requires from a system BIOS? Presumably we'll need to jump to a VGA BIOS to get the graphics card in a sane state?
Is there anyone who would like to maintain a set of documentation links? Here are a few that I dug up:
http://www.sandpile.org/80x86/index.shtml - Loads of x86 information (e.g. Intel P6 Microcode update images).
http://www.cix.co.uk/~mayday/ - 8086 development tools for Linux
http://developer.intel.com/design/chipsets/datashts/index.htm - Intel chipset data sheets
http://www.x86.org/intel.doc/Chipsets.html - More Intel chipset information, and links to other useful information
http://www.amd.com/K6/k6docs/pdf/21062e.pdf - AMD 'k86' BIOS/SW dev guide (2.2M)
http://www.amd.com/K6/k6docs/pdf/21329h1.pdf - AMD-K6 Processor BIOS Design Application Note (430k)
Tim.
Hi.. :-)
We could create somekind interface for adding custom modules. Some programs might fit directly to same EEPROM with OpenBIOS.
This definitely seems like the best option, we can just generate code to use modules in flash, and look at the possibility of loading additional modules from secondary storage if/when we start to fill up typical flash ROMs.
Yes. this could happen in several stages * from floppy disk (early stage) * from harddisk/cd (OS/special hardware dependant modules) * from network
BTW all the machines I have access to at the moment have either 128k, or 256k flash ROMs, if you write efficient code, then it will take a long time to use up all this storage - it's not that long ago that most of my computer's operating system (including GUI) came in a 256k ROM.
Hehe... yes. The Amiga had a nice design.. :-) Of course should all storage space be used which is in my opinion possible, if you keep things as modular as possible.
Does anyone know what support services (if any) a typical VGA BIOS requires from a system BIOS? Presumably we'll need to jump to a VGA BIOS to get the graphics card in a sane state?
This part already works in current implementations of OpenBIOS (thanks to Daniel) I am not really into the current code but afaicr from the Alpha BIOS emulation, only one or two functions have to be called to get a vga compliant display
Regards, Stefan
-
Dave -
Ed Brinker -
Eric R. Kern -
Karl Erik Asbjornsen -
Matthias Wächter -
Niklas Ekström -
Paananen Osmo -
Stefan Reinauer -
Tim Small -
zahn＠zac.de