Philosophical question...

[Maciej W. Rozycki]

On Thu, 4 Feb 1999, [iso-8859-1] Matthias Wächter wrote:

> > Using this approach you would not have to worry about optimizing the
> > BIOS code for any specific OS. The BIOS's only job would be to
> > load/execute the first block from the boot device and then get out of
> > the way.
> 
> hmmm, I mean, the partitioning scheme should be kept for a minimum amount
> of compatibility to other OSes. Either the boot loader resides on an own
> partition (like the OS/2 boot loader) or it would be loaded like DOS -
> implicitly from the partition (boot block, file name searching, loading,
> executing). The problem is: Both need an API to continue loading or to
> search for data on the media (harddisk, etc.). I don't think that it would
> fit into something like a boot sector ("first block from the boot
> device"). What exactly do you mean with "one block"?

 I don't think reading one physical block from the medium is a good
solution.  Many non-x86 systems read a specified amount of data from the
medium they boot from (which may usually be a random access device such
as a floppy disk, a hard disk or a CD-ROM, a sequential access device such
as tape or a network device).  This greatly simplifies boot loaders and
allows to get rid of them at all in some cases, i.e. the system
firmware loads the kernel of the OS directly.

 For example, upon booting a DEC Alpha system from a random access device,
the SRM firmware loads the first block from the device and treats two
64-bit words at offsets 480 and 488 as the number of blocks and the number
of the first block to read from the device, respectively.  There is also a
64-bit magic number located at offset 496 which indicates the bootblock is
valid.  The blocks are being read and then executed.  This allows booting
a Linux kernel directly from a disk.  A second-stage boot loader may also
be used and unlike x86-based solutions it's clean and straightforward (and
is written in C, actually).

 A similar approach is used on MIPS-based DECstation systems.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro at ds2.pg.gda.pl, PGP key available        +