On Tue, 12 Mar 2002, Luke Mewburn wrote:

> In a revised scheme, we have the following requirements:
> 	* installboot(8) has a uniform user interface,
> 	  and is installed in /sbin/installboot for platforms
> 	  which are migrated to this new scheme.
> 	* installboot(8) can be run on foreign systems (other
> 	  NetBSD ports or even other platforms)
> 	* installboot(8) works on file system images as well as
> 	  raw devices
> 	* The boot blocks support various file system types as the
> 	  boot file system (where the kernel is found), including:
> 		ffs, lfs, cd9660, ustarfs
> 	* The boot blocks are bootable from RAIDframe mirror sets
> 	  (by installing the boot blocks on the underlying components)

This is a laudable goal. I'll fill in the macppc parts as I understand
them.

> 2. Preferred operation of boot blocks
> -------------------------------------
>
> The boot blocks comprise of loading the following items in sequence:
>
>     Stage 0 boot block (the first sector)
>     -------------------------------------
>
> The PROM reads the first sector of the file system.
>
> Depending upon the platform, the first sector might contain code
> which will be executed at a specific relative offset (e.g., i386),
> or it might contain a list of sector offsets/counts which the PROM
> then uses to read in more code to boot in (e.g., pmax).
>
> This loads the stage 1 boot block from a hard-coded location (which
> might be changed by the installboot program).
>
> It is possible to support multiple ports booting from the same
> stage 0 boot block by carefully constructing the layout of the
> boot block and installing the stage 1 boot block in different
> locations in the file systme.  This feature is mostly used when
> constructing iso9660 CDs that can boot on multiple ports.
> In this case, installboot(8) needs a flag to in-situ update the
> relevant parts of the stage 0 boot block without modifying the
> rest of it.
>
> Existing use of Stage 0 (the first sector):
>
> 	Offset	Size	Machine	Use
> 	------	----	-------	---
> 	0	512	i386	MBR boot sector
>
> 	2	6	vax	boot info
>
> 	8	24	pmax	boot info
>
> 	32	440	pmax	extra program boot sections (if mode == 1)
>
> 	64	276	alpha	disklabel
> 			pmax	disklabel
> 			vax	disklabel
>
> 	128	276	sparc	disklabel
> 	128	276	sparc64	disklabel
>
> 	340	24	vax	boot info (more)
>
> 	480	24	alpha	boot info
>
> 	504	8	alpha	64bit checksum of previous 504 bytes
>
> 	508	4	i386	0xAA55

Macppc has two ways of doing this, the current installboot way, and what
we do with OF 3 machines. For the latter, we just look at the Apple
partition map for a partition, and have OF read a file (ofwboot, the stage
2 loader) off of it.

For older systems, we install a fake apple partition map which has only
two partitions, the partition map and a partition covering the stage 1
loader. Older versions of OF will load it, and use it to boot.

>     Stage 1 boot block
>     ------------------
>
> Almost all platforms need extra code to support reading in the
> stage 2 boot block (the ordinary file "/boot") from an arbitrary
> block location on the first partition in file system that the
> stage 0 boot block is installed in.  This is achieved with a stage
> 1 boot block which understands how to read the file system.
>
> All NetBSD-bootable filesystems support a boot block area in
> first few kilobytes (usually 8 KB).  Depending upon the port,
> the disklabel is up to one sector in size and is stored somewhere
> within this region.  The stage 1 boot block can be stored in
> the remaining space (e.g, 7 KB).
>
> It may be necessary to supply a separate stage 0 / stage 1
> combination for each file system type that the stage 2 boot
> block may be loaded from.
>
> Stage 1 can support booting from RAIDframe mirror sets by
> detecting that the first partition is type `RAID', and
> making the appropriate adjustments to find the real file
> system type.

For macppc, this program is bootxx.

>     Stage 2 boot block
>     ------------------
>
> This stage is often installed as the regular file "/boot" in
> the top level of the boot file system.  It provides the user
> interface to the user which allows for the selection of
> different file systems and kernels to boot, etc.
>
> In order to share root file systems amongst multiple platforms,
> the stage 1 boot block should search for "/boot.${MACHINE}"
> before "/boot".

Making macppc ofwboot more like the other boot loaders would be nice.

>     Kernel
>     ------
>
> Also known as the "stage 3 boot block" :-)
>
>
> 3. installboot(8) - the boot block installation tool
> ----------------------------------------------------
>
> installboot(8) installs the stage 0 and stage 1 boot blocks
> into a file system, which may be a file or raw device.
> It is found in /sbin/installboot.
>
> installboot has the following usage:
> 	installboot [-nv] [-b blockno] [-m machine] [-p password] [-t timeout]
> 		    file-system stage1
> 	installboot -c [-nv] [-m machine] disk
>
> 	file-system	file system device or image to write to
> 	stage1		stage 1 boot block (which might contain stage 0
> 			for ports which have code in stage 0)
>
> 	-b bno		block number to write stage 1 from
> 	-c		clear/remove boot blocks
> 	-m machine	installboot for machine type `machine'.
> 			if running on NetBSD, defaults to current machine.
> 	-M		"merge" changes into stage 0
> 	-n		do nothing
> 	-p password	password for 2nd stage (optional support)
> 	-t timeout	timeout for 2nd stage (optional support)
> 	-v		verbose
>
> It may not be possible to run installboot on a device that is a
> component of a mounted file system (e.g., running a NetBSD system
> at securelevel == 1; c.f., init(8)).  In this case, installboot
> needs a method of changing the necessary blocks via the kernel
> (e.g., an ioctl(2)), and that will most likely only work on a
> "native" system.
>
>
> [ XXX: consider port specific options via -o ? ]
>
>
> 4. Existing situation
> ---------------------
>
> * alpha
> 	- stage 0 contains sector map to stage 1, and disklabel
> 	- separate stage 1 for ffs, ext2fs, lfs
> 	- stage 1 can read /boot from anywhere in the file system
> 	- stage 2 must exist in the first partition
> 	- first partition has to start at the sector 0
> 	- can boot off RAIDframe
>     todo:
> 	- stage 1: tar (to replace installboot.old and bootxx.old,
> 	  which are used to install bootxx.old at block 17 of a
> 	  tarfile for floppy boot blocks.
>
> * i386
> 	- stage 1 supports ffs
> 	- stage 1 has hard-coded block locations for stage 2
> 	- all components of the boot blocks and kernel must
> 	  reside below 8 GB (PC BIOS limit)
> 	- can boot off RAIDframe with significant effort and separate
> 	  non-mirrored partition for /boot
>     todo:
> 	- stage 1 ffs should search for stage 2 (no hard coded blocks)
> 	- stage 1: lfs, cd9660, tar
>
> * pmax
> 	- stage 0 is a single sector offsets/count but the firmware
> 	  can handle multiple discontiguous offsets/count pairs
> 	- separate stage 1 for ffs, ext2fs, lfs
> 	- stage 1 can read /boot from anywhere in the file system
> 	- stage 2 must exist in the first partition
> 	- first partition has to start at the sector 0
> 	- can boot off RAIDframe
> 	- no ustarfs, but no floppy support either
>     possible todo:
> 	- stage 1: tar
> 	- floppy boot
>
> * vax
> 	[similar to alpha and pmax ?]
>
> [ XXX: fill in the missing ports ]

macppc (old firmware):
	- stage 0 is an apple partition map with two partitions, the
		partition map and a partition containing the stage
		1 loader
	- stage 1 loads a set of block offsets we encode into it when
		we install it. It has no fs smarts, so it's easier to
		support booting off of other non-lfs filesystems
macppc (new firmware)
	- stage 0 is handled by the firmware itself. We tell it to
		boot a file off of a given apple partition. The
		firmware doesn't understand ffs (or Darwin ufs).
		It does understand hfs(+), cd 9660, and I think
		ms-dos.
	- stage 1 doesn't exist as the firmware actually loads
		ofwboot, the stage 2 loader.

	I'm not sure how well either technique will work with
		loading the stage 2 loader off of a raid set, as
		we would then have to have open firmware open each
		raid component, and masage them together.

Take care,

Bill