: Existing use of Stage 0 (the first sector):

Here's a braindump of the other platforms which I personally know; let me
know if there's gaps that I can fill in.

Others on this list can correct me if I have misconceptions.  All of this is
from either personal experience or research for the work put into multi-arch
ISO booting.

** amiga, amigappc **

RDB ("Rigid Disk Block") structure first block can exist anywhere in
512-byte blocks 0-15.  (Note that some, but not all, Amiga boot ROMs allow
for the RDB to exist in blocks 0-63.)

Use of this sector starts at byte 0, length 220.  Magic word `RDSK' at byte
0 to identify it.  Checksum has variable length, so can be made to contain
only the RDB.  (sys/arch/amiga/include/disklabel.h:struct rdblock)

This structure contains a (start,count) tuple of contiguous blocks anywhere
on the disk that contain partition entries, bad block entries, and AmigaOS
filesystem drivers (one descriptor per block).  NetBSD partitions have
special Amiga 32-bit type IDs to provide the NetBSD fake disklabel info.

Bootblock code is loaded from the first N blocks of the boot filesystem
partition (defined by the partition entry descriptor).

NetBSD does not use a BSD disklabel on RDB disks; the partition map is
read-only in this case.  (A BSD disklabel can be stored on non-RDB disks.)

** amiga (loadbsd method) **

RDB exists as above, but the bootable flag is unset on NetBSD partitions.
AmigaOS boots first.  "loadbsd" is then used to load and boot the kernel.

** arc **

ROM uses MBR, but I don't know specifics.

** cobalt **

Uses MBR and has an ext2fs parser in the ROM; boot code is read from a file
in the ext2fs partition.  I don't know more than this.

** hpcarm, hpcmips, hpcsh **

Windows CE boots first, and "hpcboot" is used to load and boot the kernel.

Currently, a standard BSD disklabel is used to identify partitions.

** i386 **

ROM loads and executes the code in block 0, which contains code to parse the
MBR and find a partition to boot.  Boot code is loaded from the first
512-byte block of the partition, which then loads the remainder of /boot.

The boot sector contains a block list for /boot
(sys/arch/i386/stand/lib/crt/bootsect/fraglist.S).

** i386 (dosboot method) **

MBR exists as above, but DOS boots first.  "dosboot" is then used to load
and boot the kernel.

** mac68k (new bootblock work-in-progress), macppc (OFW 1.x, 2.0-2.3) **

Apple's bootblocks can accept either 512-byte or 2048-byte sectors; mkisofs,
for instance, creates both to accomodate different ROMs regarding use of CD
media.  (It creates null partitions where 512-byte partition map blocks
would collide with 2048-byte partition map blocks.)

Apple Driver Descriptor Map occupies sector 0, start byte 0, length 18
minimum.  If MacOS is on the disk, each "SCSI Manager driver" (typically one
is installed for macppc, two for mac68k) will occupy an additional 4 bytes
of info at the end of this structure.  No checksum.  (Note that SCSI Manager
drivers are not bootblocks in the NetBSD sense; they load before bootblocks
and assist the ROM with accessing the disk.)

Apple Partition Map starts at sector 1, and is contiguous through the total
number of partitions.  Each entry can contain a CPU field to identify
"68000" vs. "powerpc" (optional if only on one arch) for selective boot
purposes.  The Partition Map block contains a (start, length) tuple of
bootblock code for the selected partition.
(sys/arch/macppc/include/disklabel.h:struct part_map_entry)

Note that currently, NetBSD uses a separate partition in some cases to store
the NetBSD/macppc bootblocks.  This is *not* necessary.  The bootblock code
can reside at the start of a ffs as with most other systems, provided the
pointer tuple above is correctly set for the bootblock code.

** mac68k (current method) **

Apple Driver Descriptor Map and Partition Map exist as above, but the
bootblock pointer is unused on NetBSD partitions.  MacOS is booted first,
and a native "Booter" program does the job of finding and loading the
kernel.

** macppc (OFW 2.4, 3.x) **

Apple Driver Descriptor Map and Partition Map exist as above, but the
bootblock pointer is unused on NetBSD partitions.  (Rumor has it that the
bootblock tuple is still usable by the ROM, but this is not the way NetBSD
currently boots on these systems.)

OFW contains a HFS/HFS+ parser, which loads the XCOFF or ELF version of
ofwboot from an Apple HFS partition.  This booter then locates the ffs
partition and boots the kernel.  An alternate version of the booter
maintained by a third party, hfsboot, can also pull the kernel from a HFS
partition.

** prep **

Uses MBR with partition type 0x41 (MBR_PTYPE_PREP), and does not directly
execute code in the MBR block.  I don't know how many sectors are loaded
from that partition for boot code.

** shark **

Can use MBR or raw disk.  No bootblock is used; a 4.4BSD FFS parser exists
in the OFW.

If using MBR, the FFS parser uses a specially marked partition ID (might be
0xa5, 386BSD, but I don't remember).  If not using MBR, the OFW parses a FFS
as if it started at sector 0.

The OFW can boot any file that is a.out.  Currently it is used to boot the
NetBSD arm32 a.out kernel directly, but thorpej has said that it's on his
plate to factor out a libsa booter so that ELF kernels can be booted.

NetBSD stores a BSD disklabel at sector 1, offset 0, but this could be
variable (defined by sys/arch/arm/include/disklabel.h).

** sparc, sparc64, sun2, sun3 **

All these use the well-known Sun disklabel for booting; bootable partitions
must be on cylinder boundaries.

The Sun disklabel contains a checksum (I don't remember where, but the
NetBSD/alpha installboot was made to respect and `fix' the checksum on
multi-arch bootblocks).

Note that unlike MBR systems, which store the BSD disklabel at sector 1
byte 0, the BSD disklabel for sun3 and sparc exist at sector 0 byte 64.
This might be changeable in the NetBSD kernel, since it isn't used for
booting anything.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/