On 05/30/2013 09:21:19 AM, Kumar Gala wrote:
On May 28, 2013, at 5:45 PM, Scott Wood wrote:
> On 05/16/2013 01:29:45 AM, Kevin Hao wrote:
>> All these boards use the same configuration file p1_p2_rdb_pc.h in
>> u-boot. So they have the same pci bus address set by the u-boot.
>> But in some of these boards the bus address set in dtb don't match
>> the one used by u-boot. And this will trigger a kernel bug in 32bit
>> kernel and cause the pci device malfunction. For example, on a
>> p2020rdb-pc board the u-boot use the 0xa0000000 as both bus address
>> and cpu address for one pci controller and then assign bus address
>> such as 0xa00004000 to some pci device. But in the kernel, the dtb
>> set the bus address to 0xe0000000 and the cpu address to
0xa0000000.
>> The kernel assumes mistakenly the assigned bus address 0xa0004000
>> in pci device is correct and keep it unchanged. This will
definitely
>> cause the pci device malfunction. I have made two patches to fix
>> this in the pci subsystem.
>> http://patchwork.ozlabs.org/patch/243702/
>> http://patchwork.ozlabs.org/patch/243703/
>> But I still think it makes sense to set these bus address to match
>> with the u-boot. This issue can't be reproduced on 36bit kernel.
>> But I also tweak the 36bit dtb for the above reason.
>
> IIRC the reason for using 0xe0000000 on all PCIe roots is to
maximize the memory that is DMA-addressable without involving swiotlb.
>
> Maybe U-Boot should be fixed?
>
> -Scott
I feel that u-boot was the way it is to allow accessing each bus from
the command line in u-boot w/o big changes for >32-bit addressing.
Linux was able to handle the PCI bus addresses all being the same.
It's a bit of a hack though, in that you're using the device tree to
indicate how you want the hardware programmed rather than to describe
the hardware or even what U-Boot's done to it, and in that you can't
arbitrarily change what U-Boot chose -- it only works because you're
picking an address that U-Boot used for one of the PCIe controllers and
thus U-Boot covered it with a LAW.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
