Clarification....

[Ed Brinker]

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?
>