on 11/3/00 8:56 PM, Henry B. Hotz at hotz@jpl.nasa.gov wrote something like:

> SYNOPSIS
> boot {promdev[@addr][:part],}ofwboot.xcf exit
> boot {promdev[@addr][:part],}ofwboot.xcf -{a|s|d}[a|s|d...]
> boot {promdev[@addr][:part],}ofwboot.xcf
> [[promdev[{:|,}partition]]/]filename[ a|s|d...]


Note: this is from 2.0f1 and probably only relevant to OF 2.x and possibly
1.x.

    You might also want to add the syntax for netbooting just for kicks.

boot enet:tftp.boot.server.ip#,[XCOFF/ELF boot file] -[a|s|d] i.e.
boot enet:192.168.0.3,ofwboot.xcf -a

    This would be using a standard bootp/tftp server with (preferably
static) arp entry for the client machine. I haven't personally tested
bootp/DHCP && tftp server, but it most likely works. Thus far I have gotten
tftp service failing (looping) service terminated errors and arp failed
errors on my 1.4.2 i386 bootp/tftp server. Sometimes I get massive numbers
of tftp errors, and it'll take 5 minutes to load despite a static arp entry
even for a 56k ofwboot.xcf file, sometimes It will load an entire 3MB ELF
kernel (even though it can't boot it [Loading ELFdefault catch]) without a
single tftp error. And yet other times, it seems when it can't communicate
with the bootp server properly the first try, it will DoS the network
freezing every machine connected to it until you reboot the Mac.

    And as I mentioned earlier today, OF 2.0f1 resets the real-base once you
boot MacOS. 

    Also it should be noted specifically that OFW does not like white
spaces. As well as the fact that if you butcher a boot command it will try
to boot with whatever is in the boot-file and boot-device paths.

    And I personally have seen ofwboot.xcf not behave quite as it should.
When specifying boot fd:0 -a to load ofwboot.xcf from the 1.4.2 boot floppy.
The boot prompt was appending /netbsd to anything I typed. In this case
because "netbsd" (though NOT "/netbsd" which is weird) was in the boot-file
environment. Perhaps a check is needed when -a is specified to not append
the boot-file environment. Can anyone else verify this behavior?

<snip>
> SEE ALSO
> intro(9), install(8), the FAQ for the MacPPC port, IEEE
> standard 1275 Open Firmware.

                   ^^^^^^ We should probably point out that even in the odd
event that Apple does follow standards, they usually don't work. :-)