RE: NetBSD/ofppc boots multiuser on Pegasos

["Matt Sealey" <matt%genesi-usa.com@localhost>]

> -----Original Message-----
> From: port-ofppc-owner%NetBSD.org@localhost 
> [mailto:port-ofppc-owner%NetBSD.org@localhost] On Behalf Of Jochen Kunz
> Sent: Friday, July 28, 2006 5:01 PM
> To: port-ofppc%netbsd.org@localhost; port-powerpc%netbsd.org@localhost; 
> netbsd-ports%netbsd.org@localhost
> Subject: Re: NetBSD/ofppc boots multiuser on Pegasos
> 
> On Fri, 28 Jul 2006 11:53:22 +0200
> "Matt Sealey" <matt%genesi-usa.com@localhost> wrote:
> 
> > Do you care that the "ranges" property is empty?
> Yes. My code will call panic(9) if there is a PCI-ISA bridge 
> without or with an invalid "ranges" property. The ISA/EISA 
> binding to OFW clearly states on page 11, section 3.1.1
>     The [ranges] property _shall_ be present for all ISA/EISA bus
>     bridges. There _shall_ be an entry in the "ranges" 
> property for each
>     of the Memory and/or I/O spaces if that address space is mapped
>     through the bridge.
> I am no native englich speaker, but this sounds to me like:
> "It is broken, if it is not there."

Problems here; the ISA bus in the Pegasos is not really an ISA bus.
There is no ISA bus, no ISA slots and no ISA memory. It's actually
a bunch of PCI-connected LPC devices inside the southbridge, and it
is offset from the PCI bus (and handled by the PCI controller in
the northbridge as a PCI IO space, there is no memory there)

Read the spec, and the above, and realise that the "isa" bus address
space is NOT mapped through the bridge.

In theory you should see that ranges is not present, or empty property,
and back up the tree to the parent bus for the I/O space. In this case
it's the PCI0 controller on the Discovery II (/pci@4000000/isa@C). And
in the output you'll see, the PCI IO range is set as 0xFE000000.

The Linux guys are having a hard time with this, I think we did it
per the specification and definitely what our hardware engineer tells
me is perfectly reasonable reasoning for it. But nobody has ever used
an LPC bus under Open Firmware before, the same way we seem to be the
only people who have a /display node of type "serial" (if the framebuffer
is disabled)

The only reason it's in /pci/isa is because nobody looks for an "lpc"
node for example. Legacy ports go in the legacy ISA bus the same way
they misnamed it a PCI to ISA bridge when it doesn't implement ISA
at all.

> BTW: My code relies on the "config-l@" and "config-l!" 
> methods of the PCI device node for PCI configuration space 
> access. I.e. these methods are called from the kernel during 
> (multi user) runtime. If the Pegasos firmware doesn't suport 
> them it needs an other quirk...

Can you throw these out into a simple Forth script, and I will give
you a result?

-- 
Matt Sealey <matt%genesi-usa.com@localhost>
Manager, Genesi, Developer Relations