PCI on 834x

Scott Wood scottwood at freescale.com
Thu Feb 25 07:26:20 EST 2010


Gary Thomas wrote:
> Yes, I'm using the exact same kernel with these two different PCI
> setups (done by the boot loader).
> 
> Restricting the memory via mem=128M has no effect - the PCI layout is 
> the same.
> 
> I think the outbound window size is required because of how the Linux PCI
> remaps the space (note in my dumps that it put the MMIO of the boards 
> starting
> at 0xD0000000 when the inbound window is 0x10000000)

I see where the amount of RAM is mattering -- Linux is assigning 
outbound I/O space to the PCI controller itself (device 00:00.0) and the 
amount that it asks for seems to differ based on memory size.  Linux 
ought to skip that device when assigning resources.  Some platforms do 
this (search for pci_exclude_device), but it seems to be missing on 83xx.

>> Are there any errors indicated in the device, the PCI controller, the 
>> arbiter, etc?
> 
> None that are obvious to me.
> 
> To be clear, here are my observations:
> 
> * total memory 128MB (or less), inbound window 128MB, outbound window 128MB
>   ==> device is happy
> * total memory 256MB, inbound window 128MB, outbound window 128MB
>   ==> device hangs, unable to access RAM (Linux handed it something 
> higher than 128MB)

Linux gets its idea of how much space there is to allocate from the 
ranges property of the pci node in the device tree -- this should be 
made to match what u-boot configures in PIWARn.

> * total memory 256MB, inbound window 256MB, outbound window 128MB
>   ==> segmentation violation when accessing device MMIO space
> * total memory 256MB, inbound window 256MB, outbound window 256MB
>   ==> access to MMIO space fails (Linux can't find device).  In this 
> case, the SATA_SIL reports
>          ata1: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
>          ata2: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
>       which implies that the driver get's junk when accessing the device 
> MMIO space

Are there any other relevant messages earlier in boot, perhaps from the 
PCI code failing to assign a resource?

-Scott


More information about the Linuxppc-dev mailing list