On Tue, 22 Jun 1999 Keiki_Sunagawa@yokogawa.co.jp wrote:

> Hi,

Hello,

> 99/06/22 3:42:30, Bill Studenmund  wrote:
> 
> > On Tue, 22 Jun 1999, SUNAGAWA Keiki wrote:
> 
> > Not necessarily. If we can figure out what exactly bootx wants,
> > we might be able to go with it.
> 
> Okay, I take a look at bootx sources.

Cool!

> > 2) Get suport for the hardware in these beasts. Most of this
> > can be stolen from port-mac68k. nubus would become an MI bus
> > (moving from arch/mac68k/nubus to dev/nubus) and other bits of
> > the hardare support would get shared. For now, a kernel compile
> > could just reach into arch/mac68k.
> 
> Or just copy the stuff into arch/macppc/nubus like ADB stuff, in
> the mean time.

That would work, but for most of the files I'd vote against it for
asthetic reasons. By copying, you'll loose the automatic updating as
mac68k learns about more drivers. Also, reachover is REAL easy - you just
specify the files in "files" as being in arch/mac68k/nubus. :-)

> > 3) Figure out how to make the macppc kernel usable both with and
> > without OF. So we can boot the same kernel in both types of
> > system.
> 
> > I think the latter can be achieved by: a) having two different
> > kernel entry points, one for use w/ OF and the other for use when
> > booting onto an OF-less machine.
> 
> I think the machines that have OF and haven't are different enough
> to support separately.  Since early PowerPC Macs without OF are
> similar to 68k Macs than ones have OF in hardware design, sharing
> divice driver on both type of PowerPC Macs is harder.

Not if we do it right. :-) See below.

> > b) make two different mainbus's.
> > The current one would only attach if OF were present, and the new
> > one would only attach if it were absent.
> 
> It might bloat kernel and have bad effect for performance.
> 
> Please correct me if I'm missing something.

It definitly would grow the kernel, and should be a configuration option.
But I don't think it would be bad for performance (beyond the larger
kernel size). And astheticly there's something really nice about having
one (install) kernel which would boot both machines.

Also, we can ask the mklinux folks how much in general supporting pci and
non-pci machines adds.

My thoughts on how to do the device tree for this. Right now kernels have

mainbus* at root

cpu* at mainbus?
pci* at mainbus? bus ?

...
obio0 at pci? dev ? function ?


make it something like (note: the names are suggestions only):

mainbus_of* at root
mainbus_nubus* at root

cpu* at mainbus_of?
cpu* at mainbus_nubus?
pci* at mainbus_of? bus ?
nubus* at mainbus_nubus?


obio_of0 at pci? dev ? function ?
obio_old0 at mainbus_nubus?


As only one of the mainbus_X routines would succeed, we'd only try to
configure the correct devices.

The only "tricky" thing is drivers which would attach to both obio's. But
bus space is designed to handle that, and we can do some of it with magic
in the files file.

i.e. we'd have:

zsc0 at obio_old?
zsc1 at obio_of?		(I don't know if our config would let this
				    be zsc0 also - I doubt it)
zstty* at zsc? channel ?

and in files have:

device	zsc {channel = -1}
attach zsc at obio_old with zsc_old
attach zsc at obio_of  with zsc_of

etc.

So adding this support would just mean renaming the current drivers' probe
& attach routines to a name indicating open firmware, and looking in the
drivers (the parts which would be shared) and seeing where they assume
that they have open firmware.

Pulling this off would be fufilling a lot of design purity. :-) I mean
with bus space, and how all of the drivers attach, etc., we have the
config machinery to do it. :-)

I can't really help test it, but I'd be happy to help with the
integration. :-)

Take care,

Bill