Excerpts from mail: 11-Dec-94 Re: IEEE1275 OpenBoot suppo.. Theo de
Raadt@fsa.ca (981)

> > [Please follow up to tech-kern]

> (This is not within the charter of tech-kern, which talks about MI
> kernel internals.  I've deleted it from the list.)

My key point was that there *should* be a machine independant (MI?)
internal-to-kernal interface, available to generic OpenBoot device
drivers.  Then a port only needs to ensure that the interface is present.

> > What is the current (or planned) level of support for the OpenBoot
> > Firmware (IEEE-1275) in NetBSD?

> Why do you feel you need high level kernel access to it?

See above.

> If a machine has an OpenBOOT ROM, the NetBSD/port will use it in a
> machine dependent way.  The sparc port uses the OpenBOOT ROM to
> configure devices and halt/reboot.  All the other ROM interfaces it
> uses are specific to the sparc.  It doesn't use much code to talk to
> the OpenBOOT, but that code will is sparc-specific.

Thanks, I'll drag in ($$$) and check the latest code :-)

> Of course, Sun's OpenBOOT ROM isn't exactly the same as the IEEE
> standard (really, is anyone surprised that they had to change it?)
> Even then, there is much variation in Sun OpenBOOT ROM's.

Thanks for the warning.  Maybe the SPARC port isn't the place to look :-(

> > I think it is going to become a `must have'.

> I don't think so.  If a PPC mac uses OpenBOOT, it isn't going to use
> it the same way that a sparc does.

I think of OpenBoot (among other things) as a mechanism that allows a
kernel to access a device in the absence of a native device driver
(perhaphs I'm wrong).  When looking at devices for a new target, going
down the path of implemting the open boot interface (assuming the rest
was there) would be easier then initially worrying about native devices.

All I know about Mac's is that they have adopted PCI with OpenBoot.  One
assumes that this is so that they can implement plug and play.

If any one can look into this now, I'd be eternally graitfull.

		more 6 months later, Andrew