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.