Re: Changing ibm4xx device tree.

[Jachym Holecek <freza%dspfpga.com@localhost>]

Hello,

# Simon Burge 2006-05-05:
> Shigeyuki Fukushima wrote:
> > device tree [before changes]:
> >   plb(root)
> >    |
> >    +-- cpu
> >    +-- ecc
> >    +-- opb  (almost 405GP-specific code)
> >    +-- pchb (405GP-specific)
> > 
> > device tree [after changes]:
> >   mainbus(root)  evbppc/evbppc/mainbus.c
> >    +-- cpu       cpu-depend-setup
> >         +-- plb  config_attach with cpu_attach_args
> >              |     (device infomation each 4xx have)
> >              +-- ecc
> >              +-- opb
> >              +-- pchb
> 
> Most ports have a "mainbus" which is a pseudo bus for the root of the
> device tree.  For a handful of ports, this bus has a "real name".
> On the 4xx PowerPC parts, this is called the PLB.  It's the wrong
> abstraction to hang devices directly off the CPU core itself.

Yep -- at least for the 405, PLB (IPLB and DPLB, actually) is the
main memory bus. Even in a SMP design, which is reasonably doable
at least on higher-class Virtex chips, the central memory controller
connecting individual cores/chips would inevitably live on the PLB
(more then "live on" it would just transparently bridge and arbiter
all PLB traffic -- pretty much like Xilinx's MPMC2 controller I guess).

> If you have a multi-core cpu, and the devices attaching to the cpu,
> which cpu would you have the devices attach cpu0 or cpu1?  It can't
> attach to both.

Well, for the 405 it would be fair to hang DCR and OCM (both general
purpose, user visible, per-core busses on the Virtex) directly on the
CPU. Since neither of them is meaningfully usable in a SMP design (DCR
and OCM are strongly synchronous and lack arbitration protocol, AFAIK),
it would be reasonable to assume they'd be left unconnected in a SMP
design (beyond boot phase at least).

> There's also nothing really 405GP specific in opb.c.  There's a table in
> there that currently has only 405GP and 405GPr entries, but that's where
> entries for devices on other CPUs will also go.  If another CPU doesn't
> have a PCI host controller, then it doesn't get a "pchb" entry in the
> OPB device table and it doesn't show up.
> 
> In short, I can't see that there's anything wrong with the current
> structure.  There's still a little bit of cleanup to be done, but
> nothing fundamentally wrong.

Unrelated to the original point -- what about turning OPB and PLB to
indirect-config busses? From my (Virtex-centric) POV, both of them
are general purpose busses w/o any autodetection mechanism, their
address space layout may be different on every FPGA firmware. Further,
there may be more then one OPB controller connected to the PLB.

I'm actually working with a design where OPB is hooked at different
address and hosts different devices then any existing 4xx port. It
seems more reasonable to hardwire base addresses to kernel config
files (or config fragments, where sharing makes sense) then in the
code itself, IMO.

Or perhaps there's a good way to handle this with plb/opb as-is?

        -- Jachym