Hallo Volker,

> >> 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.
> 
> This is true on every Atari system.  But there is a rule for deciding
> from which device the boot sector is chosen.  I think it's like this:
> 
>    1. If it's a reboot, test the device that the last boot was from

Only relevant after a `warm' boot under TOS or MagiC. A reboot (or halt
+ reset key) from NetBSD or Linux always causes a `cold' boot.

>    2. If 1 fails, try the floppy on A:

Yep, the boot code in ROM always tries to boot from floppy first.
Allthough it will be very usefull to boot NetBSD from floppy in an
emergency situation (e.g. corrupted disklabel), I believe this has
lower priority than booting from harddisk. Once we achieve the
latter, the former is probably easy to implement (the main problem
being the limited capacity of a floppy disk).

>    3. If 2 fails, try the first SCSI device [TT/Falcon]
>    4. If 3 fails, try the first ACSI device

TT: SCSI unit 0..7 (only lun 0); ACSI unit 0..7 (only lun 0).
Falon: IDE (only unit 0?); SCSI unit 0..7 (only lun 0).
SCSI arbitration is not supported by the boot code in ROM.

Question: can DMAread() handle IDE harddisks? Or is there some
other XBIOS function which can?

> >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
> 
> I guess this is only valid on TTs, I don't know about the Falcon.

Those bits in NVRAM are *not* evaluated by the boot code in ROM. It
is the root sector code that may (or may not) use this information.
The root sector code installed by HINSTALL (HDX/AHDI) will probably
use this information; other driver software may or may not.

Once again, the boot code in ROM loads the root sector and executes
the boot code in the root sector (if it exists). Everything else is
left to the boot code in the root sector (for example, TOS drivers
will usually check for the Alternate key being pressed).

> >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.
> 
> I think this is a little too much worry!  

I fully agree. Let's look at some possible combinations:

- NetBSD & TOS (or MagiC)
  The loadbsd.ttp program could be slightly changed, to run from the
  AUTO folder, reading arguments from a file (netbsd.cnf?) instead of
  the commandline; not booting NetBSD when some keys (say left+right
  Shift) are pressed.
  This is similar to Linux/Atari at the moment.

- NetBSD & Linux
  For Linux/Amiga there is lilo, I suspect the Linux/Atari developpers
  will follow sooner or later. Lilo is capable of booting other kernels,
  so there's no good reason to do the same (or at least similar) work
  twice. When lilo for Linux/Atari exists, then we can look what we
  have to do to make it work with NetBSD (if anyone cares).
  For now, Linux must be booted from TOS, see the previous case.

- NetBSD & ASV
  Well, ASV is booted from an UNX partition; if NetBSD were to use the
  same identifier, we'ld create a big mess. (Leo, I believe we already
  discussed this long time ago.)

> >> (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.)
> 
> We can also use keyboard input and text display output, for example to
> prompt for bootflags [-s, kernel name, etc].

Yes, we'll have to you TOS functions as much as we can. The maximum size
of the boot loader is rather small (too small to integrate a console
driver).

> >> 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.
> 
> The loader should check out as little as possible, to allow for
> maximum flexibility.  The kernel should do as much as possible.

Agreed. The basic info is provided by TOS (BIOS).

> >> 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.
> 
> Hmmm ... I believe that we shouldn't make it too complicated there.  A
> simple working boot loader that pulls in /netbsd would be a great step
> forward.  Decorations can come later 8-)

You took the words out of my fingers. :-)
But the name of the kernel must not be fixed. Suppose you compile a new
kernel, copy it to /netbsd, reboot, but there's a bug in the new kernel,
preventing a successfull reboot. What next...
Search for your boot floppies!


Waldi