mpc744x, Marvell mv6446x kernel guidance please

[Stephen Horton]

Hi Dale,

Thanks for the info; it was very informative. To follow-up on my
previous email:

1. I now have a working interrupt-map section in my .dts. PCI bus
initialization works with no visible errors.

2. I've deciphered the magic numbers in the cpu->pci window
configuration. The required information for disabling and re-enabling
BARS is located in the Marvell User's manual, Rev C, page 365, Table
141.

3. I'm a little smarter on the Ethernet configuration. I understand now
that Linux should actually just know about eth0 the RGMII connection
from Marvell to the Broadcom switch. Its upto me to configure the
additional Broadcom ports with whatever configuration (to meet my PICMG
2.16 requirements). I have all the Ethernet stuff initializing properly
(including eth0) with no errors; unfortunately, when I configure for
bootp and nfs boot over the network, there are no bootp requests coming
out of my board (verified with a sniffer, but link is up according to
Broadcom status bits and remote switch). So, I still have something
wrong here in my kernel code...

Thanks, again,
Stephen

-----Original Message-----
From: Dale Farnsworth [mailto:dale at farnsworth.org] 
Sent: Wednesday, July 30, 2008 6:11 PM
To: Stephen Horton
Cc: Mark A. Greer; linuxppc-embedded at ozlabs.org
Subject: Re: mpc744x, Marvell mv6446x kernel guidance please

On Wed, Jul 30, 2008 at 08:56:18AM -0500, Stephen Horton wrote:
> Thanks for your kind encouragement. I now have a mostly booting
kernel.
> I have just a few remaining issues to resolve; perhaps you (or others)
> can give me some tips regarding these:
> 
> 1. In your prpmc2800 .dts configuration, in the PCI bus configuration
> section, you lay-out the IRQ mappings like this:
> 	interrupt-map = <
>                 /* IDSEL 0x0a */
>                 5000 0 0 1 &/mv64x60/pic 50
>                 5000 0 0 2 &/mv64x60/pic 51
> I've read the Open Firmware document on Interrupt Mapping, but I still
> don't really understand the first 3 columns (5000 0 0), especially
where
> the first column comes from. Is this just some arbitrarily selected
> offset address for that device on the pci bus?

An address on the PCI bus is represented by 3 cells (96 bits).

Take a look at page 4 of http://www.openbios.org/data/docs/bus.pci.pdf

You'll see that the PCI device is contained in bits 15-11, selected by
the 0xf800 in interrupt-map-mask.  The 0x5000 corresponds to device 0xa.

-Dale