MPC834x PCI problem
Gary Thomas
gary at mlbassoc.com
Thu Feb 26 03:10:16 EST 2009
Gary Thomas wrote:
> I have two [internal] boards with MPC8347. Both have a PCI
> bus, slightly different set of "wired" peripherals.
>
> On one board, the PCI seems to be working fine. I can talk
> to all of my wired devices, plus one in a plugin slot. The
> [PCI portion] DTS for this board looks like this:
> pci0: pci at ff008500 {
> cell-index = <1>;
> interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> interrupt-map = <
> /* IDSEL 0x0A (External slot) */
> 0x5000 0x0 0x0 0x1 &fpga_ic 0
> 0x5000 0x0 0x0 0x2 &fpga_ic 1
> 0x5000 0x0 0x0 0x3 &fpga_ic 2
> 0x5000 0x0 0x0 0x4 &fpga_ic 3
>
> /* IDSEL 0x0B (Promise SATA) */
> 0x5800 0x0 0x0 0x1 &fpga_ic 5
> 0x5800 0x0 0x0 0x2 &fpga_ic 5
> 0x5800 0x0 0x0 0x3 &fpga_ic 5
> 0x5800 0x0 0x0 0x4 &fpga_ic 5
>
> /* IDSEL 0x0C (Fujitsu Coral-P) */
> 0x6000 0x0 0x0 0x1 &fpga_ic 4
> 0x6000 0x0 0x0 0x2 &fpga_ic 4
> 0x6000 0x0 0x0 0x3 &fpga_ic 4
> 0x6000 0x0 0x0 0x4 &fpga_ic 4
>
> /* IDSEL 0x0D (Philips USB) */
> 0x6800 0x0 0x0 0x1 &fpga_ic 12
> 0x6800 0x0 0x0 0x2 &fpga_ic 12
> 0x6800 0x0 0x0 0x3 &fpga_ic 12
> 0x6800 0x0 0x0 0x4 &fpga_ic 12
>
> /* IDSEL 0x1F (External slot) */
> 0xF800 0x0 0x0 0x1 &fpga_ic 0
> 0xF800 0x0 0x0 0x2 &fpga_ic 1
> 0xF800 0x0 0x0 0x3 &fpga_ic 2
> 0xF800 0x0 0x0 0x4 &fpga_ic 3
> >;
> interrupt-parent = <&ipic>;
> interrupts = <0x13 0x8
> 0x14 0x8>;
> bus-range = <0 0>;
> ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x10000000
> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
> clock-frequency = <33333333>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <0xff008500 0x100 /* Internal registers */
> 0xff008300 0x8>; /* Config Space registers */
> compatible = "fsl,mpc8349-pci";
> device_type = "pci";
> };
> This board has a Promise SATA controller in slot 11 (drivers/ata/sata_promise.c)
>
> The second board uses a DTS derived from the first. In fact, the
> *only* difference is in the PCI layout:
> pci0: pci at ff008500 {
> cell-index = <1>;
> interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> interrupt-map = <
> /* IDSEL 0x0B (Promise SATA) */
> 0x5800 0x0 0x0 0x1 &ipic 0x13 8
> 0x5800 0x0 0x0 0x2 &ipic 0x13 8
> 0x5800 0x0 0x0 0x3 &ipic 0x13 8
> 0x5800 0x0 0x0 0x4 &ipic 0x13 8
> >;
> interrupt-parent = <&ipic>;
> interrupts = <0x13 0x8>;
> bus-range = <0 0>;
> ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x10000000
> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
> clock-frequency = <33333333>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <0xff008500 0x100 /* Internal registers */
> 0xff008300 0x8>; /* Config Space registers */
> compatible = "fsl,mpc8349-pci";
> device_type = "pci";
> };
> This board has a slightly different Promise controller (drivers/ata/pata_pdc2027x.c)
> The basic PCI access code in both drivers is the same.
>
> As mentioned, the first board works fine. The second board
> falls apart on PCI access. It's obvious that the PDC2027x
> driver is having access problems. Here are some clues from
> the boot log (PCI related items only):
>
> Found FSL PCI host bridge at 0x00000000ff008500. Firmware bus number: 0->0
> PCI host bridge /pci at ff008500 (primary) ranges:
> MEM 0x00000000c0000000..0x00000000cfffffff -> 0x00000000c0000000
> IO 0x00000000b8000000..0x00000000b80fffff -> 0x0000000000000000
> PCI: Probing PCI hardware
> PCI: Cannot allocate resource region 5 of device 0000:00:0b.0, will remap
> bus: 00 index 0 io port: [0x00-0xfffff]
> bus: 00 index 1 mmio: [0xc0000000-0xcfffffff]
> pdc_detect_pll_input_clock: scr[FFFFFFFF]
> pdc_read_counter: bccrh [7FFF] bccrl [7FFF]
> pdc_read_counter: bccrhv[7FFF] bccrlv[7FFF]
> pdc_read_counter: bccrh [7FFF] bccrl [7FFF]
> pdc_read_counter: bccrhv[7FFF] bccrlv[7FFF]
> pdc_detect_pll_input_clock: scr[FFFFFFFF]
> pdc_detect_pll_input_clock: start[1073741823] end[1073741823]
> pdc_detect_pll_input_clock: PLL input clock[0]Hz
>
> It's pretty obvious that the PDC driver is having troubles.
> The system seems happy otherwise:
>
> root at ppc_target:~ lspci -v
> 00:00.0 Bridge: Unknown device 1957:0085 (rev 11)
> Flags: bus master, 66MHz, fast devsel, latency 248
> Memory at <unassigned> (64-bit, prefetchable)
> Memory at <unassigned> (64-bit, non-prefetchable)
> Capabilities: [48] #06 [0000]
>
> 00:0b.0 Mass storage controller: Promise Technology, Inc. 20275 (rev 01) (prog-if 85)
> Subsystem: Promise Technology, Inc. 20275
> Flags: bus master, 66MHz, slow devsel, latency 0, IRQ 19
> I/O ports at 1000 [size=8]
> I/O ports at 1008 [size=4]
> I/O ports at 1010 [size=8]
> I/O ports at 1018 [size=4]
> I/O ports at 1020 [size=16]
> [virtual] Memory at c0000000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [60] Power Management version 1
>
>
> Any ideas what might be going [wrong] here? I did notice that
> both RedBoot [my boot environment] and an older kernel (2.6.20)
> on this board assigned a non-zero offset in the PCI space for
> this device:
> Bus: 0, PCI Device: 11, PCI Func: 0
> Vendor Id: 0x105A, Device Id: 0x1275, Command: 0x0007, IRQ: 1
> BAR[0] 0x00001001 / probed size 0x00000000 / CPU addr 0xb8001000
> BAR[1] 0x00001009 / probed size 0x00000000 / CPU addr 0xb8001008
> BAR[2] 0x00001011 / probed size 0x00000000 / CPU addr 0xb8001010
> BAR[3] 0x00001019 / probed size 0x00000000 / CPU addr 0xb8001018
> BAR[4] 0x00001021 / probed size 0x00000000 / CPU addr 0xb8001020
> BAR[5] 0x00100000 / probed size 0x00000000 / CPU addr 0xc0100000
>
> Could this be a possible problem (maybe the device doesn't like it)?
Answering my own question; I changed the PCI range to not start
at offset zero:
ranges = <0x02000000 0x0 0xC0100000 0xC0100000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
The PDC driver now talks to the device :-)
I'm still having troubles with the PCI interrupt, but progress nonetheless.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
More information about the Linuxppc-dev
mailing list