This is a specialised pc kernel that acts as a bootstrap loader for
386 and amd64 kernels, and replaces the old 9pxeload, 9load and
9loadusb.  It relies on the pc port (in /sys/src/9/pc) for most of its
non-portable source files, notably the disk and ethernet drivers, so
you'll want an up-to-date system (see replica/pull) if installing this
by hand.  Support for user mode (such as system calls) is almost
entirely absent.  There is some duplication of code with the pc
kernel, but we have tried to keep it to a minimum.

Caveats:

9boot doesn't scan disks for partition tables since it doesn't contain
the disk drivers, but `readparts=' in plan9.ini (see
/sys/src/9/boot/parts.c) will make the loaded kernel read them early
on.  9load does read partition tables.

9loadusb seems to hang for two minutes when attempting to read via the
bios on some bioses (e.g., vmware's), then reports a disk timeout on
the INT 13 extended read operation.


How these new bootstraps differ from the old 9load and 9pxeload.

The old 9load was a single process derived from (but separately
evolved from) an old PC kernel, so it needed modified device drivers
(primarily for ethernet and disk controllers), which was an ongoing
maintenance nuisance, and not all ethernet controllers had bootstrap
drivers.  The new bootstraps are just specialised Plan 9 kernels that
are loaded into the first 640KB of RAM, so they use unmodified Plan 9
drivers.  There isn't enough room below 512K to include useful support
for user mode and system calls, but the new bootstraps do implement
kernel processes.  The 512K limit is imposed by PXE or PBS loading of
the new bootstraps into the first 512K or 640K.

The old 9load was capable of loading from disks, floppies, USB disks
or ethernet (via PXE).  Again due to space limitations, we've had to
focus the new bootstraps more sharply.  9boot loads via PXE and
nothing else, which is our usual mode of operation.  9load loads from
non-USB disks (using BIOS INT 13 calls) but not floppies, which ought
to be obsolete by now.  If you must boot from floppy and are doing so
now and your BIOS won't boot from USB, do this to arrange to boot from
USB disk instead:

	a: && cp /386/9loadusb /n/a:/9load

9loadusb loads from USB disks only.  BIOSes seem to be easily confused
by intermixing direct I/O and BIOS calls, thus we keep 9load and
9loadusb distinct.

The new bootstraps can load amd64 as well as 386 kernels, and generate
Gnu Multiboot tables for their benefit.

The new 9load will look on all available disks for FAT file systems.
If no bootfile is specified in a plan9.ini, it will examine each file
system to see if it contains a single Plan 9 kernel (9pc* or 9k8*),
and if so, will boot it.

The new 9boot contains no disk drivers, so it can't read partition
tables and populate #ec/sd??part for the kernel's benefit, so if you
need to access a disk partition early in the kernel's execution (e.g.,
you have an nvram partition), you'll want to add

readparts=

to the /cfg/pxe file for any such machines.

The new bootstraps should run on more machines than the old ones.  We
discovered new ways to enable the A20 address line and try them all
until success.  This may fix various odd memory corruption problems
seen in the past.  We also discovered that BIOS calls may enable
interrupts, so we disable them again immediately upon return.  This
may prevent mysterious resets seen with the old bootstraps.


CD booting changes

pbsraw can be up to 2k, so we can print and be nice, uses things
written up by mk9660.  In any case, it reads a contiguous file and is
468 bytes long (we dropped the 9fat support here), so it could be used
to load from any raw partition supporting lba access.

There are corresponding changes to mk9660 to annotate the PBS.  A new
parameter, -x loader, names a loader that has to be in the root
directory.  In conjuction with -B, can be used to boot directly from
the CD.

9load was changed to deal with a 9fat image file in the root directory
of a CD image.  It has to be called bootdisk.img and can be of any
size (as long as it is contiguous).


Memory Map

This is how the bootstraps use memory:

0	---------------------

31K	---------------------
	start of pxe decomp + compressed 9boot
64K	---------------------
	start of pbs decomp + compressed 9boot
	decompresses to 9MB
	...
512K	---------------------
	pxe loader from ROM
640K	---------------------
	UMB
1MB	---------------------
	kernel
9MB	---------------------
	9boot after decomp.
	decompresses kernel.gz
	from 13MB to 1MB.
13MB	---------------------
	(kernel.gz)
15MB	---------------------
	no-man's land
16MB	---------------------
	malloc arena for 9boot
	...

chinese puzzle constraints:
BIOS calls only work from bottom 1MB (640K, really).
with paging on, we need to have created page tables for the memory we use.
a20 has to be enabled before we try to use memory above 1MB.