For those who are interested...

The MacOS boot process works roughly as follows.  I ignore the hardware
diagnostics, and other superfluous activities, and focus on how
booting and the PCI stuff is handled.

Apple offers the PCI DDK for folks who want to know more, It contains some
good info and handy tools, like PCIpeek and Display Name Registry.
Great for MacOS, of dubious value under NetBSD.

The OFW controls the early boot.  It configures the PCI, and gathers
information from each card in PCI that it finds.  This includes
configuring them.  It looks for ROMs
on these cards, and if it finds OFW "stuff" on them, it will use
some of the information to build an appropriate entry for the device tree
for that device.  (This is the "probe time" stuff)

If there is no OFW on the card, then it "makes up" an entry and a
device name based on the vendor ID and device.  An adaptec
2930, which has "full" OFW support, is called "pci9004,7260"
(or something like that) if there is nothing in the ROM.  It's
called "ADPT,2930CU" or somesuch.  The "probe-time" OFW on the card
sets up the name, and a few other properties in the device tree.

Other properties that are in the ROM are extracted and placed in the device
tree.  If the OFW contains a driver for MacOS, this is also extracted and
placed as a property in the device tree. (driver property will
be named "driver,AAPL,MacOS,PowerPC")

When people talk about PCI cards having OFW support, what they normally
mean is that the ROM on the card contains code, normally written in
Forth, that can run at OFW time to access the functions of the card.
Having this code will allow the card to be used at boot time, and is also referred to in the Apple literature as "full" OFW support.

Note that this means that there are two drivers present on such cards.
One is written in forth, and the other is written in C/C++/Pascal/COBOL
and is a code fragment for MacOS.  The latter is the MacOS runtime driver.

(fork)

For older machines, (prior to B&W G3) the ROM on the motherboard is used
as the boot "device" and the MacOS ROM is loaded and run.

For more recent machines (B&W G3 and later - the "new world architecture")
the boot process must find a MacOS ROM file/device somewhere.  The OFW
will use these "OFW drivers" on the PCI cards to either search for
a MacOS ROM, or go specifically to a selected device.  The boot-file
and boot-device vars in OFW point to this file/device.  The search is
for a file of type "tbxi" as I recall.

(join)

The OFW drivers provided on a card do not get used unless you somehow
try to boot from that card.  Once the machine is booted the OFW drivers
are useless because they only function in the OFW environment, which
gets blown away completely by the OS, once booted.

When switching from OFW to MacOS, the Mac performs some magic to
preserve the device tree.  (I'm not sure how... ;-> )

Once the MacOS ROM is loaded, it uses the PCI config
as set up by OFW to talk to the cards.  It also looks in the device
tree for the "driver,AAPL,MacOS,PowerPC" properties, and if present,
these are loaded into MacOS - they are the MacOS run-time drivers.

So, to respond to some of the comments below:

o	The OFW does the card configuration, and it does it regardless
	of whether there is a ROM or anything in it.

o	MacOS requires some sort of driver for every device.
	Some devices have drivers built into MacOS, but I don't
	know of any PCI cards like this.  Cards that have
	no drivers are ignored by MacOS.

	A driver can either be found in the OFW-style property
	on the ROM on the card, or can be installed as an
	extension and can match to the card via the
	"pci9004,9999" name.  Either will work.

	So, it is not required to have an OFW driver (boot time)
	nor have the driver present in the ROM to make the
	card work on MacOS.

o	The main (only?) reason to have forth/OFW drivers in the ROM on a
	PCI card is if you want to use the card at boot time.
	The OFW drivers (in theory) will work at boot time regardless
	of the OS being booted.  Once the OS is up, these OFW
	drivers are useless.

o	Given the above, it is unlikly that a random PCI card
	from the wintel shelf will work in the mac for MacOS.  If the
	manufacturer did a driver, they'd say so.  If they don't say so,
	chances are they didn't write one, so it won't work.

o	I don't know of any reason that the mac should hang at
	boot when a card without a driver is placed in a
	PCI slot.  It may be that the integrity checking of
	ROM info in OFW is poor, and if it's not actually OFW
	ROM stuff, OFW will get horribly confused.

o	I *believe* that the MacOS is wholly dependent on the
	BAR information in the device tree, and is not capable
	of doing PCI config.

my 2 cents, (OK, maybe 4 or 6 cents ;-> )

-dgl-




--- begin forwarded text


To: Bill Studenmund <wrstuden@nas.nasa.gov>
Cc: Monroe Williams <monroe@pobox.com>, port-macppc@netbsd.org
Subject: Re: puc device in 1.4.1 -release 
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Sat, 06 Nov 1999 20:11:00 -0800
Sender: port-macppc-owner@netbsd.org

On Sat, 6 Nov 1999 19:24:15 -0800 (PST) 
 Bill Studenmund <wrstuden@nas.nasa.gov> wrote:

 [ monroe said... ]
 > > Actually, MacOS will completely ignore most PCI cards that don't have an
 > > OF driver.  

That wouldn't make much sense, because then 3rd party vendors couldn't
make effective use of loadable drivers in MacOS :-)

I think it's a matter of "those things which OFW doesn't talk to MacOS
doesn't talk to because they have no reason to" :-)  I.e. they're not
standard Mac devices.

 > I'm not sure, but I think it will actually configure them (i.e. set up the
 > memory and i.o spaces they want) even without an OF driver. It won't do
 > much else with them, though. :-)

OFW will configure the PCI bus (though, sometimes, incorrectly :-), but
still makes the BARs available in the device's OFW properties (even if
the OFW doesn't have a driver for the device).  I seriously doubt that
MacOS has PCI bus configuration code in it, given the behavior Bill and
I have observed on his G3 :-)

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>

--- end forwarded text