Problems with PCI on 8280
Hi.
We have e 8280 bioard with PCI. We have three memory ranges set up;
0x8000_ to 0x8fff_ is prefetchable memory
0x9000_ to 0x97ff_ is non-prefetchable memory
0x9800_ to 0x9800_ is IO.
our device tree has
ranges = <4200 0 8000 8000 0 1000// Pre-fetch memory
0200 0 9000 9000 0 0800// Normal Memory
0100 0 9800 9800 0 0001>; // I/O
for the memory ranges in the PCI node (full node at the end)
Our problem is that we can only access the first 128MB of the prefetchable area.
an access to 0x87ff_ works (after ioremap), while an access to 0x8800_
causes an bus error.
trying to access 0x87FC -> 0x
trying to access 0x8800 ->Machine check in kernel mode.
Caused by (from SRR1=49030): Transfer error ack signal
It is like the prefetch area is not set up correctly for ioremap.
The PCI registers are set up correctly in u-boot, and we can access the whole
prefetch area in u-boot without any problems.
pci node in device tree:
[EMAIL PROTECTED] {
device_type = "pci";
reg = ;
compatible = "fsl,mpc8280-pci", "apmax-pci", "fsl,pq2-pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
clock-frequency = ; // For our board.
interrupt-map-mask = ;// Anded with the
interrupt-map values
interrupt-map = <
/* IDSEL 0x11 */
8800 0 0 1 &PCI_INT 5>; // 3 first
numbers pci device specifier are: (buss << 16 | id_sel << 11) 0 0
//buss = 0,
id_sel = 11
// Next number is
interrupt 1-4 mapped A-D (interrupt A for us)
// Last two
numbers are host interrupt specifier (external interrupt 5)
//interrupt-parent = <&PIC>;
interrupt-parent = <&PCI_INT>;
// interrupts = <12 8>;
// Mem type 0 Bus Add Loc. Add 0 Length <<--- Remember the
mem type is little endian
ranges = <4200 0 8000 8000 0 1000//
Pre-fetch memory
0200 0 9000 9000 0 0800// Normal
Memory
0100 0 9800 9800 0 0001>; // I/O
bus-range = <0 ff>;
[EMAIL PROTECTED] {
device_type = "pci";
reg = <9000 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
interrupt-parent = <&PCI_INT>;
interrupt-map-mask = <0f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x10 */
0 0 1 &PCI_INT 1
/* IDSEL 0x11 */
0800 0 0 1 &PCI_INT 2
/* IDSEL 0x12 */
1000 0 0 1 &PCI_INT 3
/* IDSEL 0x13 */
1800 0 0 1 &PCI_INT 4 >;
};
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with PCI on 8280
Rune Torgersen wrote: > >From: Scott Wood > >Are you using cuImage, or a regular uImage with a device-tree-aware u-boot > > cuImage for now. > > >If the former, try commenting out the call to fixup_pci() in > >arch/powerpc/boot/cuboot-pq2.c and let me know if that changes anything. > > Did that, That made our PCI bus fail completely Hmm... that suggests that something in u-boot's setup is either incorrect, or (more likely in this case) doesn't match the device tree. Or maybe it's the bus parking/arbiter tweaking at the end that u-boot is missing. > We have our PCI set up to ONE 512MB outbound range doing all three. > (I can see where you'd save on mem usage by doing two) > > I do see a bug tho. > In our case prefetch is 256MB, memio is 128MB. > the calculation for outbound wiondow 1 sets the size to ~(pref+mmio-1). > That only works if the resulting size is a power of 2. Ah. Yes, I was assuming both windows would be the same size. The code should be changed to check that, and if any conditions for setting PCIBRx/PCIMSKx fail, check to see if the firmware-provided values work (and if not, bail without touching anything). > If we comment out the rewrite of the outbound windows, we get PCI to work. > But since our u-boot sets everything up correctly (Including prefecable > memory) we should not need this? or is it rewriting the device tree in > some way? You shouldn't need it... I'd compare the register values u-boot sets with the values the corrected fixup_pci() sets (including the soc regs at the end). Something must be different. There is no device tree re-writing; it tries to program the hardware to match what's in the device tree. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Problems with PCI on 8280
From: Scott Wood >Hmm... that suggests that something in u-boot's setup is either >incorrect, or (more likely in this case) doesn't match the device tree. Turns out u-boot was not setting u the inbound window size correctly. It was hardcoded to 512MB and we have a gig of ram. Set it correctly, and CPI now works fully even without fixup_pci() >Ah. Yes, I was assuming both windows would be the same size. The code >should be changed to check that, and if any conditions for setting >PCIBRx/PCIMSKx fail, check to see if the firmware-provided values work >(and if not, bail without touching anything). yup. In our case we only need one window. BTW. there is a bug in the inbound window size calculation. The mem_log2 variable sould be the shift value, not 1<< shift. and on the next line the window size mask sould be anded with 0x000f_ before or'ed with 0xa000_ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with PCI on 8280
Rune Torgersen wrote: > Our problem is that we can only access the first 128MB of the > prefetchable area. > an access to 0x87ff_ works (after ioremap), while an access to > 0x8800_ causes an bus error. > > trying to access 0x87FC -> 0x > trying to access 0x8800 ->Machine check in kernel mode. > Caused by (from SRR1=49030): Transfer error ack signal > > It is like the prefetch area is not set up correctly for ioremap. > > The PCI registers are set up correctly in u-boot, and we can access the > whole prefetch area in u-boot without any problems. Are you using cuImage, or a regular uImage with a device-tree-aware u-boot? If the former, try commenting out the call to fixup_pci() in arch/powerpc/boot/cuboot-pq2.c and let me know if that changes anything. Otherwise, are you sure the kernel didn't move BARs around such that there's no longer a PCI device mapped at 0x8800 (or that the device that is there has been disabled)? Can you show the contents of the following big endian registers: TESCR1 (0x10040), TESCR2 (0x10044), PCIBRx (0x101ac, 0x101b0), and PCIMSKx (0x101c4, 0x101c8) and the following little endian registers: POTARx (0x10800, 0x10818, 0x10830), POBARx (0x10808, 0x10820, 0x10838), POCMRx (0x10810, 0x10828, 0x10840), POESR (0x10084), PCI_EACR (0x10890), and PCI_ECCR (0x108a0) after the machine check happens? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Problems with PCI on 8280
>From: Scott Wood >Are you using cuImage, or a regular uImage with a device-tree-aware u-boot cuImage for now. >If the former, try commenting out the call to fixup_pci() in >arch/powerpc/boot/cuboot-pq2.c and let me know if that changes anything. Did that, That made our PCI bus fail completely Looking in fixup_pci, I see it sets up one outbound window to the size of prefechable and non-prefetcabe memory and anoter one to the size of the IO. We have our PCI set up to ONE 512MB outbound range doing all three. (I can see where you'd save on mem usage by doing two) I do see a bug tho. In our case prefetch is 256MB, memio is 128MB. the calculation for outbound wiondow 1 sets the size to ~(pref+mmio-1). That only works if the resulting size is a power of 2. If we comment out the rewrite of the outbound windows, we get PCI to work. But since our u-boot sets everything up correctly (Including prefecable memory) we should not need this? or is it rewriting the device tree in some way? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with PCI on 8280
On Thu, Jan 17, 2008 at 06:27:46PM -0600, Rune Torgersen wrote: > BTW. there is a bug in the inbound window size calculation. The mem_log2 > variable sould be the shift value, not 1<< shift. and on the next line the > window size mask sould be anded with 0x000f_ before or'ed with > 0xa000_ D'oh. Thanks for spotting it! -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
