[OpenBIOS] Summary: Booting the OS

[Florian Wunderlich]

Here's the summary of our discussion about booting the OS and how it is
done in the minicomputer world. This is not about integrating a new HAL
into the BIOS; its just about how the BIOS should load and execute an OS
from disk/net/... .


- The "unintellingent" approach: c/h/s et al

David Kennedy <dkennedy at engsoc.carleton.ca>, said that he boots his Next
with the following command:
	bsd(0,0,0) [kernelname]
but made not clear what "kernelname" means (passed to a secondary loader?).

I booted (before its death) my Sun/CV (68k, SysV) with a command like
	b sd(0,0,0); syntax is clear.


- The "we load an intermediate loader" approach: OpenBoot, ...

James Laferriere, <babydr at nwrain.net>, said he boots his Sparc 4/xx series
with a command like:
	/sbus/esp at 0,800000/sd at 3,0:a

This is Sun OpenBoot 3.x syntax, as far as I understand, from Sun's
OpenBoot 3.x Command Reference Manual, section The Device Tree. (www.sun.com)
James states that the BIOS understands UFS(Solaris type) filesystems, too;
but it seems to me that this is only true for the secondary boot program.
The primary OpenBoot boot code does not understand more than TFTP and
simple I/O. Quote from Sun: "Often, the program loaded and executed by the
boot process is a secondary boot program whose purpose is to load yet
another program. This secondary boot program may use a protocol different
from that used by OpenBoot to load the secondary boot program. For example,
OpenBoot might use the Trivial File Transfer Protocol (TFTP) to load the
secondary boot program while the secondary boot program might then use the
Network File System (NFS) protocol to load the operating system.
     Typical secondary boot programs accept arguments of the form: filename
-flags where filename is the name of the file containing the operating
system and where -flags is a list of options controlling the details of the
start-up phase of either the secondary boot program, the operating system
or both."

Pros: Bootcode in the EPROM can be small and simple, and need to know only
the Right Things; but in contrast to the conventional lilo-style boot, you
can have a real comfortable boot prompt, with fq path name to the kernel etc.

Cons: If your hdd or whereever you load the second loader from is broken
you got a problem.

With a litte extensions to the BIOS (network!), this is a fancy lilo.


- The "we waste some space on hd only for our kernels" approach: BSD,
DOS+loadlin

A simple filesystem on a special partition.

Pros: We do not need to know anything of a complex filesystem; but we can
use different kernel images.

Cons: Where are the pros, I have all those with lilo already. Stupid thing.


- The "we implement a complex fs, network, cdrom, tape, ... <fill in your
favorite killer device driver, at least 512k in size>" approach:

Ok, why not just implement it in the firmware of your harddisk? Imagine, an
ext2fs harddisk :-). This is the bootrom-on-my-nic-approach.


What we wanted (David Kennedy):
- Network boot
- Boot from any partition
- Booting a Linux kernel directly/Filesystem support, so we can easily
specify above Linux kernel
- A powerful BIOS UI (most likely command-line driven)
- Extended hardware diagnostics in flash ROM


To conclude, I think the only interesting thing is to improve lilo; without
replacing the entire BIOS, I do not see any possibility to make things like
diskless boot etc. work without Boot EPROMS on NICs.
The best thing IMHO is to adopt OpenBoot for 80x86 machines. It has a
well-thought concept, an UI (huh, forth :-), you can write your own
hardware diagnostics, and with the secondary-loader-approach, you can do
the other things as well.


---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request at linkscape.net   Body: un/subscribe
Problems?  dcinege at psychosis.com