hi stephan-

   based on what you've said it seems that we can't rely on having
the bug provide any service at all.    i have checked the kernel source 
code, and the kernel doesn't make any direct calls [i.e. trap #15] to 
the bug-prom (as long as it thinks it has been booted from sboot).    
the only thing the kernel looks for is key constants in NVRAM.    if 
you look at a current locore.s you will see two lines:

       movl    0xfffe0774,d1           | XXXCDC -- hardwired HEX
       movl    0xfffe0778,_myea        | XXXCDC -- ethernet addr

the first line is where it is trying to get the size of memory from
the NVRAM.   the second is where it extracts its ethernet address from
the NVRAM.   what does OS9 do with the NVRAM?   if you can write to
those addresses the correct info, then you should be able to boot
a normal kernel without a problem (once it is loaded in memory properly).
if you can't write those locations, it would be simple to hardwire
those two items.


   I think the easy way to get things going is to use the NetBSD 1.1
sboot and netboot since they don't make any calls to the ROM either.
(the newer netboot does use the bug-ROM for console I/O and for reading
the real time clock).

   so what you should get is:
	ftp://ftp.netbsd.org//pub/NetBSD/NetBSD-1.1/mvme68k/*

you then need to load sboot into RAM at address 0x4000.   Can you
load S-records in with OS 9?    If not I can generate a raw binary
sboot file for you.  Once you have it loaded you just jump to 0x4000 
and you should get the sboot ">>> " prompt.   from that point you should 
be able to follow the INSTALL instructions.

>oops, how do I tell the kernel, where to 
>look for the NFS server?  Seems to be the wrong approch.

NetBSD uses the standard SunOS bootparamd to obtain this info.   on
your server you should have a /etc/bootparams with an entry that looks
about like this:

vme147  root=dworkin:/export/root/vme147\
        swap=dworkin:/export/swap/vme147


>Any comments?  Am I the first, who ever tried this?

you are the only person I know to try this, but hey, that makes it
more exciting!!! :)



On a related note, at this point I am wondering if it is worthwhile to 
make it a compile time option for -current "netboot" to not rely on trap #15 
being there.    We are currently using trap #15 for console I/O, reading
the real-time clock, getting the cpu type, and for exiting back to the bug.

Chuck