As some of you notice, I am now working on rewriting the
boot system of NetBSD/x68k.

The old boot system is excellent program but has little
space for new features (FFS has only 8KB reserved space for
the boot program).  Plus, from the viewpoint of the project
goal, keeping code machine-independent, I decided to rewrite
the boot system using MI libsa (stand-alone library).

We are planning to switch the executable format from a.out
to ELF.  To load an ELF kernel the new system is required.
It is important to test the new system before the switch.
For test, I put the binary at

ftp.netbsd.org:/pub/NetBSD/arch/x68k/newboot.tar.gz 158200bytes

Before you try this please prepare a fallback boot method
such as boot floppy.

- Floppy case (part1):
 The firmware (IOCS) loads the first 1KB from the floppy.
Previously, this was /usr/mdec/fdboot.  fdboot loads the
kernel directly from the FFS on the floppy.

New boot system consists of 2 part: fdboot_ufs and /boot.
fdboot_ufs is installed to the first 1KB as the boot block
just like fdboot but does not support selecting kernel and
uncompressing gzipped kernel.  It loads the second part
called /boot.  Kernel selection and gunziping is done by this
second part.

Note that currently fdboot_ufs does not support LFS,
because -current LFS is too broken to test.

Example installation:
    # /usr/mdec/installboot.new /usr/mdec/fdboot_ufs /dev/rfd0c
    # mount /dev/fd0c /mnt
    # cp /usr/mdec/boot /mnt
    # umount /mnt

- Floppy case (part2)
 Alpha's ustarfs boot system is ported.
Usage is similar to i386's, but use /usr/mdec/fdboot_ustar
as the first part.
    # /usr/mdec/installboot.new /usr/mdec/fdboot_ustar /dev/rvnd0c
Also, since the standard FD format of x68k is different from
the libsa standard, the filename of the first archived file
(/usr/mdec/boot) must be USTAR.volsize.4540 (4540 is the
octal representation of 2400 = # of blocks of a FD).

- SCSI harddisk case
 The firmware (IOCS) loads 1KB data from the byte offset of
0x400 (when the sector size is smaller than 0x400 = 1KB).
This is called `IPL menu' although our implementation
(/usr/mdec/mboot) does not have the menu functionality.
IPL menu analyses the Human68k-style partition table, and
read first 1KB of the appropriate partition as the
OS-dependent bootstrap loader.

 Previously, the OS-dependent loader was /usr/mdec/sdboot
(which is hardlinked to /usr/mdec/fdboot).  sdboot loads the
kernel directly from the FFS on the partition.

 New boot system consists of 2 part: sdboot_ufs and /boot.
sdboot_ufs (which is hardlinked to /usr/mdec/sdboot) is
installed to the first 1KB as the OS-dependent loader just
like sdboot but does not support selecting kernel and
uncompressing gzipped kernel.  It loads the second part
called /boot.  Kernel selection and gunziping is done by this
second part.

 Note that currently sdboot_ufs does not support LFS,
because -current LFS is too broken to test.

Example installation:
    # /usr/mdec/installboot.new /usr/mdec/fdboot_ufs /dev/rsd0a
    # mount /dev/sd0a /mnt
    # cp /usr/mdec/boot /mnt
    # umount /mnt

Note that if the target partition is mounted,
installboot.new can be only completed when securelevel < 1
(singleuser mode).  See init(8).

- /boot usage
 /boot adopts a simple commandline interface instead of the
CUI interface of sdboot and fdboot.  This is because I
wanted to support serial console.

The usage is very similar with the i386 one.  Typically it
waits for user interaction for several seconds, and loads
the default kernel.  If the user types space (or other) key
while the prompt is shown, it enters to the command mode.
Type help to show the list of effective command.

Example:
    > boot -s			boot single-user
    > boot sd2a:		boot from SCSI ID2 disk
    > boot onetbsd		boot /onetbsd

- BSD-style disklabel support.
 Recent kernel supports reading and writing BSD-style
disklabel.

Previously, NetBSD/x68k read the Human68k-style partition
table and the in-core disklabel was faked up from it.  This
method had a few weakness:
 - It does not have some information which BSD label has.
 - It does not support >16GB disk/partition.
 - It does not support >2KB sector medium.

BSD label is located at the byte offset of 64 (0x40) of the
disk.  It is the reserved area after the X680x0 signature
(disk mark) on harddisks but is believed to be unused, and
the bootblock area on floppies.

To write the BSD disklabel, supply -r option to disklabel(8).
disklabel(8) MUST be the most recent version (after Nov.20).

The kernel first attempts to read the BSD label.  If (and
only if) a valid label is not identified it reads the
Human68k partition table.

The kernel does not produce any errors even when it detects
inconsistency between the BSD label and the partition
table.  You must maintain by yourself the consistency of
them.  Especially since the IPL menu does not support BSD
label the boot partition must be recorded correctly in the
Human68k partition table.  The new boot system (xxboot_ufs
and /boot) does support the BSD label.

Assumed environments are (1) the start offset and the size
of all the partitions that are defined by both are completely
equivalent, and, (2) all the partitions that are defined by
the BSD label correspond to a single Human68k partition.
For (1), you can easily write the BSD label by following
sequence:

    # disklabel sd0 > proto
    # disklabel -rR sd0 proto

(2) is similar style to i386 and other MBR-based ports.  The
installer (sysinst) is planned to adopt this policy,
although the time line is not decided yet.

Experimental support to eliminate the Human68k partition
table is imported in the new boot system.  When the
first partition spans from the byte offset 0 of the disk,
and it is the boot partition, you can install sdboot_ufs in
place of the IPL menu.  In this case Human68k partition
table is not used and can be eliminated.

-- 
Minoura Makoto <minoura@netbsd.org>