Ross Harvey wrote:

> To do this right will require a rethink of pmax/stand and other boot issues.
> Both alpha and pmax boot the same way (block # and len in sector 0) but
> alpha has this huge array of bootblocks and boot programs, whereas pmax
> has remarkably minimal boot code and no boot installers at all.  (The boot
> block sector 0 is just hard-coded into a boot program .S file and the MI
> sbin/disklabel installs it, without even a single pmax #ifdef.)
> 
> The pmax approach is impressive in its austerity, and it certainly conserved
> developer effort, but it means there is *no way* to make the pmax bootable
> from the iso9660 official NetBSD CD.

From the looks of things, alpha needs the last 32 bytes of the first
sector (with a valid checksum).  I think the pmax needs 24 bytes
starting at byte 8 - the rest of the first sector doesn't matter.  You
mention sparc as a sector-0 dependant arch - do you know what it needs
and if there are any others that need sector zero?

> If anyone is looking at expanding the pmax/stand support, I have some
> observations:
> 
> 	* because the pmax sector 0, unlike the alpha one, takes an *array*
> 	  of block #/len values, a unified boot program that lives in the
> 	  FFS is possible.
> 
> 	* OTOH, the unified program has two drawbacks:
> 		1. restore(8) and cp(1) will change block #'s, and require
> 		   an installboot(8) rerun. LFS is another problem.
>
> 		2. by using up sector 0 with the array, you can stomp on
> 		   info needed by multiboot CD's (e.g., pmax+sparc+alpha)

The pmax recently (<12 months) went to a two-stage boot - initially the
first stage just loaded netbsd (or the passed kernel name) by name.  Now
we have a second stage that is looked for by name by the first stage.
I've also built (but not tested) LFS and iso9660 boot blocks.  There
never has been (nor will there be if I have a say :-) a reliance on
hard-coded block numbers for the second stage.

Also the pmax can take an array of sector number and block counts or
just a single sector number and block count - we just the latter.

> 	  The two-stage alpha support now finds /boot by name in CD9660,
> 	  FFS, or LFS. There is also a unified alpha boot program for
> 	  cases like the new libsa ustarfs that feature contiguous
> 	  layouts.

I've been tracking Chris's work relatively closely, and am planning to
move to an alpha-like boot setup soonish - "Time" :-)

Simon.