Hallo Waldi,

> 
> > > Not yet. At least one harddisk must have an AHDI partition
> > > table, because NetBSD can only be booted under TOS/MagiC.
> > > A bootloader is necessary to boot NetBSD without TOS.
> >
> > It seems that partitions labeled 'UNX' can be auto booted from
> > TOS, Volker raised that possibility.
> 
> The only thing TOS does, is to read the root sector (sector 0),
> calculate a checksum, and (if the checksum matches some magic
> number) execute the root setor code at offset 0. Everything
> else is left to this root sector code.
I understood that also the partition id played a role in this.
I assumed this true because volker said there were bit's in the
NV ram that determined wich id was chosen
    - first bootable
    - first bootable GEM/XGM
    - first bootable UNX
Volker suggested to use the UNX tag for bsd so we were able to
auto-boot. The problem is that people who want to run both NetBSD
and ASV or Linux (when they create a bootloader), will have a problem.
Or one could say that they should stick to TOS-boot.
> 
> The NetBSD root sector code (i.e. the primary boot loader) will
> have to load the remainder of the boot block (sectors 1..15,
> the boot block is 8KB) Sectors 1..13 contain the secondary boot
> loader, sectors 14..15 contain the disklabel. At this point the
> location of the root fylesystem is known, per definition it's
> on the first partition (sd?a).
> 
> (The boot code in ROM can only handle harddisks with a 512 bytes
>  sector size, so we don't have to worry about different sector
>  sizes and can happily use the DMAread() XBIOS function.)
> 
> The secondary loader must then load the kernel from /netbsd.
> I think it's reasonable to require that the root fylesystem
> is of type ffs, so that would be the only filesystem type
> the loader must understand.
At this point the ufsboot code for one of the other systems might
be of interest.
> 
> > The loader should also checkout the hardware config.
> 
> If it turns out that 6.5KB for the boot loader is a little
> low (dutch: `aan de krappe kant'), some of those checks
> could probably be moved to the kernel? The current NetBSD
> loader under TOS doesn't do much checking, does it?
No, but it takes some info from the cookie jar:
	- size of TT-ram
	- size/start of FX-ram
	- CPU type
It also needs the TOS version (for the clock bug) but this can be
gotten from ROM directly. I already moved the FPU detection to the kernel.
> 
> > I saw that the hp or sun ports had ufsboot code that might
> > be interesting.
> 
> I hope so. Basically we need a very much stripped down ffs
> driver, allowing us to read a file in the root directory.
Subdirectories are quite handy too. I don want too much stuff in my
root directory.
> 
> > No, the loader code won't be trivial I'm afraid.
> 
> I'm more optimistic, the hard work is already done by the
> kernel itself.
If you mean setting up the VM system...yes, I've spend quite some
(hard) time with it ;-) Especially because you don't have a console at that
point.

Leo.