| Message ID | 1368685785-10677-1-git-send-email-haokexin@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
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
On Tue, May 28, 2013 at 05:45:56PM -0500, 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. OK, this sounds reasonable. I can drop the changes for the 36bit dts. But for the 32bit dts, it does cause the kernel hang on my p2020rdb-pca board when the SiI3132 driver probe the on-board pcie to sata controller. I think this issue should apply to all these boards if it has a pci device plugged. So we should fix them ASAP. > > Maybe U-Boot should be fixed? Maybe. I have created patch for kernel to detect this kind of mismatch between kernel and bootloader and then try to reassign the bus address automatically. https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=next&id=cf4d1cf5ac5e7d2b886af6ed906ea0dcdc5b6855 So with this patch the kernel should just work even without this patch and the fix for u-boot. But this patch is just queued for 3.11. So I wish we can tweak the 32bit dts to accommodate to the u-boot now so that we can make sure that these boards are at least bootable for 3.10 or previous kernel. Then we can revert this patch for more DMA address space once the pci patch are merged into mainline. Thanks, Kevin > > -Scott
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. - k
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
On 05/29/2013 10:25:25 PM, Kevin Hao wrote: > On Tue, May 28, 2013 at 05:45:56PM -0500, 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. > > OK, this sounds reasonable. I can drop the changes for the 36bit dts. > But for > the 32bit dts, it does cause the kernel hang on my p2020rdb-pca board > when the > SiI3132 driver probe the on-board pcie to sata controller. I think > this issue > should apply to all these boards if it has a pci device plugged. So > we should > fix them ASAP. Is this what your 3.11 patch fixes, or does it hang even with that? > > Maybe U-Boot should be fixed? > > Maybe. I have created patch for kernel to detect this kind of > mismatch between > kernel and bootloader and then try to reassign the bus address > automatically. > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=next&id=cf4d1cf5ac5e7d2b886af6ed906ea0dcdc5b6855 > > So with this patch the kernel should just work even without this > patch and > the fix for u-boot. But this patch is just queued for 3.11. So I wish > we can > tweak the 32bit dts to accommodate to the u-boot now so that we can > make sure > that these boards are at least bootable for 3.10 or previous kernel. > Then we > can revert this patch for more DMA address space once the pci patch > are > merged into mainline. Is this a regression, or has it been broken for a while? -Scott
On Thu, May 30, 2013 at 01:57:42PM -0500, Scott Wood wrote: > On 05/29/2013 10:25:25 PM, Kevin Hao wrote: > >On Tue, May 28, 2013 at 05:45:56PM -0500, 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. > > > >OK, this sounds reasonable. I can drop the changes for the 36bit > >dts. But for > >the 32bit dts, it does cause the kernel hang on my p2020rdb-pca > >board when the > >SiI3132 driver probe the on-board pcie to sata controller. I think > >this issue > >should apply to all these boards if it has a pci device plugged. > >So we should > >fix them ASAP. > > Is this what your 3.11 patch fixes, Yes, the patch in the pci next tree fix this issue in a more general level. > or does it hang even with that? No. > > >> Maybe U-Boot should be fixed? > > > >Maybe. I have created patch for kernel to detect this kind of > >mismatch between > >kernel and bootloader and then try to reassign the bus address > >automatically. > >https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=next&id=cf4d1cf5ac5e7d2b886af6ed906ea0dcdc5b6855 > > > >So with this patch the kernel should just work even without this > >patch and > >the fix for u-boot. But this patch is just queued for 3.11. So I > >wish we can > >tweak the 32bit dts to accommodate to the u-boot now so that we > >can make sure > >that these boards are at least bootable for 3.10 or previous > >kernel. Then we > >can revert this patch for more DMA address space once the pci > >patch are > >merged into mainline. > > Is this a regression, or has it been broken for a while? It seems that the p2020rdb-pc_32b.dts was not bootable since it was first introduced into the mainline kernel. The reason is that the following patch change the method of doing the translation of the bus->resource and resource->bus and then disclose this mismatch between bootloader and kernel. commit 6c5705fec63d83eeb165fe61e34adc92ecc2ce75 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Thu Feb 23 20:19:03 2012 -0700 powerpc/PCI: get rid of device resource fixups Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Thanks, Kevin > > -Scott
diff --git a/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts b/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts index ab8f076..042bda5 100644 --- a/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts +++ b/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts @@ -56,7 +56,7 @@ pci0: pcie@ffe09000 { reg = <0x0 0xffe09000 0x0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xa0000000 0x0 0xa0000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0x0 0xffc10000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 @@ -71,7 +71,7 @@ pci1: pcie@ffe0a000 { reg = <0x0 0xffe0a000 0x0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0x0 0x80000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0x0 0xffc00000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 diff --git a/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts b/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts index 9e9f401..3afbd1f 100644 --- a/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts +++ b/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts @@ -56,7 +56,7 @@ pci0: pcie@fffe09000 { reg = <0xf 0xffe09000 0x0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 @@ -71,7 +71,7 @@ pci1: pcie@fffe0a000 { reg = <0xf 0xffe0a000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 diff --git a/arch/powerpc/boot/dts/p1020utm-pc_32b.dts b/arch/powerpc/boot/dts/p1020utm-pc_32b.dts index 4bfdd89..27576eb 100644 --- a/arch/powerpc/boot/dts/p1020utm-pc_32b.dts +++ b/arch/powerpc/boot/dts/p1020utm-pc_32b.dts @@ -56,7 +56,7 @@ pci0: pcie@ffe09000 { reg = <0x0 0xffe09000 0x0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xa0000000 0x0 0xa0000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0x0 0xffc10000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 @@ -71,7 +71,7 @@ pci1: pcie@ffe0a000 { reg = <0x0 0xffe0a000 0x0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0x0 0x80000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0x0 0xffc00000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 diff --git a/arch/powerpc/boot/dts/p1020utm-pc_36b.dts b/arch/powerpc/boot/dts/p1020utm-pc_36b.dts index abec535..52eabf9c 100644 --- a/arch/powerpc/boot/dts/p1020utm-pc_36b.dts +++ b/arch/powerpc/boot/dts/p1020utm-pc_36b.dts @@ -56,7 +56,7 @@ pci0: pcie@fffe09000 { reg = <0xf 0xffe09000 0x0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 @@ -71,7 +71,7 @@ pci1: pcie@fffe0a000 { reg = <0xf 0xffe0a000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 diff --git a/arch/powerpc/boot/dts/p1024rdb_32b.dts b/arch/powerpc/boot/dts/p1024rdb_32b.dts index 90e803e..ede1af6 100644 --- a/arch/powerpc/boot/dts/p1024rdb_32b.dts +++ b/arch/powerpc/boot/dts/p1024rdb_32b.dts @@ -53,7 +53,7 @@ pci0: pcie@ffe09000 { reg = <0x0 0xffe09000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xa0000000 0x0 0xa0000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0x0 0xffc10000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 @@ -68,7 +68,7 @@ pci1: pcie@ffe0a000 { reg = <0x0 0xffe0a000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0x0 0x80000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0x0 0xffc00000 0x0 0x10000>; pcie@0 { reg = <0x0 0x0 0x0 0x0 0x0>; diff --git a/arch/powerpc/boot/dts/p1024rdb_36b.dts b/arch/powerpc/boot/dts/p1024rdb_36b.dts index 3656825..7642783 100644 --- a/arch/powerpc/boot/dts/p1024rdb_36b.dts +++ b/arch/powerpc/boot/dts/p1024rdb_36b.dts @@ -53,7 +53,7 @@ pci0: pcie@fffe09000 { reg = <0xf 0xffe09000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 @@ -68,7 +68,7 @@ pci1: pcie@fffe0a000 { reg = <0xf 0xffe0a000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>; pcie@0 { reg = <0x0 0x0 0x0 0x0 0x0>; diff --git a/arch/powerpc/boot/dts/p1025rdb_32b.dts b/arch/powerpc/boot/dts/p1025rdb_32b.dts index ac5729c..6ba7ddd 100644 --- a/arch/powerpc/boot/dts/p1025rdb_32b.dts +++ b/arch/powerpc/boot/dts/p1025rdb_32b.dts @@ -54,7 +54,7 @@ }; pci0: pcie@ffe09000 { - ranges = <0x2000000 0x0 0xe0000000 0 0xe0000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>; reg = <0 0xffe09000 0 0x1000>; pcie@0 { @@ -70,7 +70,7 @@ pci1: pcie@ffe0a000 { reg = <0 0xffe0a000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0 0xe0000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 diff --git a/arch/powerpc/boot/dts/p1025rdb_36b.dts b/arch/powerpc/boot/dts/p1025rdb_36b.dts index 06deb6f..4659e2d 100644 --- a/arch/powerpc/boot/dts/p1025rdb_36b.dts +++ b/arch/powerpc/boot/dts/p1025rdb_36b.dts @@ -55,7 +55,7 @@ pci0: pcie@fffe09000 { reg = <0xf 0xffe09000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xe 0x20000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 @@ -70,7 +70,7 @@ pci1: pcie@fffe0a000 { reg = <0xf 0xffe0a000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 diff --git a/arch/powerpc/boot/dts/p2020rdb-pc_32b.dts b/arch/powerpc/boot/dts/p2020rdb-pc_32b.dts index 57573bd..4ab21f8 100644 --- a/arch/powerpc/boot/dts/p2020rdb-pc_32b.dts +++ b/arch/powerpc/boot/dts/p2020rdb-pc_32b.dts @@ -63,7 +63,7 @@ pci1: pcie@ffe09000 { reg = <0 0xffe09000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0 0xa0000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 @@ -78,7 +78,7 @@ pci0: pcie@ffe0a000 { reg = <0 0xffe0a000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0 0x80000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 diff --git a/arch/powerpc/boot/dts/p2020rdb-pc_36b.dts b/arch/powerpc/boot/dts/p2020rdb-pc_36b.dts index 470247e..488f1ad 100644 --- a/arch/powerpc/boot/dts/p2020rdb-pc_36b.dts +++ b/arch/powerpc/boot/dts/p2020rdb-pc_36b.dts @@ -63,7 +63,7 @@ pci1: pcie@fffe09000 { reg = <0xf 0xffe09000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000 @@ -78,7 +78,7 @@ pci0: pcie@fffe0a000 { reg = <0xf 0xffe0a000 0 0x1000>; - ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000 + ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>; pcie@0 { ranges = <0x2000000 0x0 0xe0000000
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. The cpu address for the pci controller seems also not right in p1025rdb_32b/36b.dts. So fix it at the same time. Signed-off-by: Kevin Hao <haokexin@gmail.com> --- I just tested this on a p2020rdb-pca board. All others just passed build test. arch/powerpc/boot/dts/p1020mbg-pc_32b.dts | 4 ++-- arch/powerpc/boot/dts/p1020mbg-pc_36b.dts | 4 ++-- arch/powerpc/boot/dts/p1020utm-pc_32b.dts | 4 ++-- arch/powerpc/boot/dts/p1020utm-pc_36b.dts | 4 ++-- arch/powerpc/boot/dts/p1024rdb_32b.dts | 4 ++-- arch/powerpc/boot/dts/p1024rdb_36b.dts | 4 ++-- arch/powerpc/boot/dts/p1025rdb_32b.dts | 4 ++-- arch/powerpc/boot/dts/p1025rdb_36b.dts | 4 ++-- arch/powerpc/boot/dts/p2020rdb-pc_32b.dts | 4 ++-- arch/powerpc/boot/dts/p2020rdb-pc_36b.dts | 4 ++-- 10 files changed, 20 insertions(+), 20 deletions(-)