On Sat, 27 Feb 1999, Mike Frager wrote:

> Hello,
> 
> I've read the responses to my original ideas and it seems that people are
> very interested it this. Most people who responded favored creating an
> imposter Apple_Driver partition that would be loaded by the Start Manager
> and would then boot NetBSD. If this is how people want to do it than
> that's what we should do.
> 
> This my current plan for implementing this imposter Apple_Driver:
> 
> It will be a two stage system. The first stage will be the actual
> Apple_Driver partition. If will (probably) be written completely in
> assembler. When run, this first stage will know the current SCSI id (this
> is passed in by the Start Manager according to I.M.) and the physical
> location on the disk of the second stage loader.

I really like the fact you decided to go w/ boot blocks rather than a fake
driver. Other reasons for this change: floppies don't have partitions, but
can have boot blocks, and the boot blocks will have all scsi drivers
loaded. So if the disk w/ this loader is probed before a disk w/ custom
MacOS drivers (say decrypting ones), then boot blocks could still get at
the MacOS info as the special drivers for other drives will be loaded.

> The second stage loader will have knowlegde of the ffs filesystem and will
> be able to find the kernel without the physical location. This stage will
> then actually load the kernel into memory, setup the environment, detect
> and pre-configure the hardware then execute the kernel (please tell me if
> I missed something ;).

The kernel can take care of configuring the hardware, you don't have to.
All you need to be able to do is get the kernel, and to get user input.
Thus at most you need adb set up (probably is), at least one video display
set up (done as the NuBus manager will have done its first-pass of setup),
the disk drives set up (done). That's it.

Keeps your life simple. :-)

Oh, I think that ethernet cards would also be set up (stage 1 NuBus init). 
An IP stack wouldn't though. 

> The second stage loader will be easier and could probably be written in C
> (or Pascal... hehehe).

We don't ship a pascal compiler, though. :-)

> Before we try to actually write this thing we should find solutions for
> the problems that we KNOW we will run into. If you have a way (preferably
> an assembler or C routine) to do any of these things PLEASE post it:
> 
> Detect and/or switch to 32-bit addressing

Look at what's available for the SE/30. It should be in there.

> Read and write to/from PRAM

Why?

> Access to SCSI from assembler

SCSI manager calls.

> Using Toolbox traps from ROM without the MacOS

But you DO have MacOS, just a very rudimentary form. The trap system
should be up and running.

> Detect hardware without the MacOS (or are Gestalts in ROM?)

Some of the Gestalts should be in ROM. More for the later ones.

The trap to get the address of a trap routine should be operational too.
Then you just get the trap of the undefinedtrap trap, and compare your
desired trap with it. I.E. if your trap's address == undefinedtrap, it's
not available yet.

> Access partitions from NetBSD in raw (no filesystem) mode

?? Look at how other two stage booters do it. libsa has filesystem code in
it, so it's available.

> Setup the display/serial ports without the MacOS

I'd say don't bother. At most all you need to do is clear the screen and
use the Text Manager to put some info up. That much of QuickDraw should be
live at that point.

> Using assembler to move a chunck of data from disk to RAM (should be easy)

SCSI or .Sony driver calls.

> If we can get a few of these worked out then we can begin coding. Also,
> does anyone have an idea of how we can debug this thing since Macsbug
> won't be loaded yet.

printf's (which get mapped into TextManager calls).

Take care,
Bill