Re: PCI device not working
Hi Kumar, I try to summarize the problem in the hope to fix it for good: Linux Kernel (2.6.34-6) did not detect one of the two pci devices that instead u-boot could see. This was worakounded by defining CONFIG_PCI_NOSCAN in u-boot as per [1] To find out the root cause of the problem, you've suggested to dump all the controller registers between the case that works and doesn't and see what changes. Te following registers have different values in the faulty situation (u-boot compiled without CONFIG_PCI_NOSCAN definition) vs the working case (u-boot compiled with CONFIG_PCI_NOSCAN defined): 0x9000: 0x8048 (not working) - 0x8003007c (ok) 0x9004: 0x (not working) - 0x0800 (ok) The register values were obtained with the devmem utility. Thanx very much for your help, Davide [1] http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/20140 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
Hi Kumar, On Fri, Oct 05, 2012 at 07:47:24AM -0500, Kumar Gala wrote: On Oct 5, 2012, at 3:54 AM, Davide Viti wrote: On Oct 4, 2012, at 7:24 AM, Davide Viti wrote: Hi, it turns out that if define CONFIG_PCI_NOSCAN in u-boot (as per [1]), the device behind the second controller is detected by the Linux kernel. Would you suggest any particular patch I should apply to fix this (I'm using kernel 2.6.34) thanx alot in advance Davide [1] http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/20140 My suggestion would be to try and dump all the controller registers between the case that works and doesn't and compare. There's some minor setting difference that I'm guessing is causing issues. - k When I said controller registers, I meant the FSL PCI controller and the CCSR registers not the PCI cfg register space I've collected a complete dump of the registers in the working and not working cases 0x9000: 0x8048 (not working) - 0x8003007c (ok) 0x9004: 0x (not working) - 0x0800 (ok) According to the p1020 manual, the register fall in the PCI Express controller 2 area, in particular: 0x9000 PEX_CONFIG_ADDR—PCI Express configuration address register 0x9004 PEX_CONFIG_DATA—PCI Express configuration data register does that ring any bell? thank you in advance Davide ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Fwd: PCI device not working
(just realized I did not send this to the mailing list: sorry for the noise) Hi Kumar, 2012/10/4 Kumar Gala ga...@kernel.crashing.org: On Oct 4, 2012, at 7:24 AM, Davide Viti wrote: Hi, it turns out that if define CONFIG_PCI_NOSCAN in u-boot (as per [1]), the device behind the second controller is detected by the Linux kernel. Would you suggest any particular patch I should apply to fix this (I'm using kernel 2.6.34) thanx alot in advance Davide [1] http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/20140 My suggestion would be to try and dump all the controller registers between the case that works and doesn't and compare. There's some minor setting difference that I'm guessing is causing issues. - k Here's a diff for the configurations for the controller, obtained via hexdump -C /sys/bus/pci/devices/0001\:02\:00.0/config --- cfg0_2_NOK.txt 2012-10-05 09:37:44.854607000 +0200 +++ cfg0_2_OK.txt 2012-10-05 09:36:58.337399000 +0200 0400 00 00 00 00 16 00 00 00 e2 04 00 00 00 00 00 00 || 0410 04 00 00 00 01 00 00 00 00 00 00 00 40 40 00 00 |@@..| 0420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || -0430 00 00 00 00 00 00 00 00 21 81 9e 00 1a 90 01 00 |!...| +0430 00 00 00 00 00 00 00 00 21 81 9e 00 83 20 08 00 |! ..| 0440 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0450 ce d7 14 00 20 1e fc 01 00 00 00 00 5c 0c 00 00 | ...\...| 0460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0470 57 19 00 01 11 00 20 0b 00 00 00 00 01 00 00 00 |W. .| 0480 44 3d 00 00 00 00 00 00 f0 07 00 00 00 00 00 00 |D=..| 0490 c0 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || -04a0 00 00 00 00 00 00 00 00 00 00 00 00 3c 01 00 00 |...| +04a0 00 00 00 00 00 00 00 00 00 00 00 00 7e 01 00 00 |~...| 04b0 00 00 00 00 00 00 00 00 28 04 01 80 85 20 00 00 |( ..| 04c0 ff 00 00 00 00 00 00 00 00 00 00 00 11 00 00 00 || 04d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 04e0 00 00 00 00 01 01 00 00 01 01 00 00 00 00 00 00 || -04f0 0a 00 00 00 01 00 20 04 00 00 00 00 79 47 0e eb |.. .yG..| +04f0 4a 00 00 01 03 00 00 04 00 00 00 00 01 00 01 00 |J...| 0500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0510 00 00 00 00 00 00 00 00 21 01 00 00 00 00 00 00 |!...| 0520 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || Hope this mail client will not screw up the text... Just in case, I've pasted the entire register dumps to [1]. thank you so much for your time, D. [1] http://pastebin.com/zzAtzCeS ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
On Oct 5, 2012, at 3:54 AM, Davide Viti wrote: (just realized I did not send this to the mailing list: sorry for the noise) Hi Kumar, 2012/10/4 Kumar Gala ga...@kernel.crashing.org: On Oct 4, 2012, at 7:24 AM, Davide Viti wrote: Hi, it turns out that if define CONFIG_PCI_NOSCAN in u-boot (as per [1]), the device behind the second controller is detected by the Linux kernel. Would you suggest any particular patch I should apply to fix this (I'm using kernel 2.6.34) thanx alot in advance Davide [1] http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/20140 My suggestion would be to try and dump all the controller registers between the case that works and doesn't and compare. There's some minor setting difference that I'm guessing is causing issues. - k When I said controller registers, I meant the FSL PCI controller and the CCSR registers not the PCI cfg register space - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
R: Re: PCI device not working
Hi, it turns out that if define CONFIG_PCI_NOSCAN in u-boot (as per [1]), the devide behind the second controller is detected by the Linux kernel. Would you suggest any particular patch I should apply to fix this (I'm using kernel 2.6.34) thanx alot in advance Davide [1] http://permalink.gmane.org/gmane. linux.ports.ppc.embedded/20140 Messaggio originale Da: zino...@tiscali.it Data: 28/09/2012 16.48 A: ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org Ogg: R: Re: PCI device not working Hi Kumar, It was, can you figure out in u-boot what exact config read on the bus would return the correct thing. The fact that when we probe the device at 0001:03 we should get back something like cfg_data=0xabba1b65 here follow some details about what is going on inside u-boot; verbosity increases from [1] to [3] [1] PCI printouts when the board come up [2] output of pci [0-3] long u-boot command [3] same as [1] but with debug print inside indirect_read_config_##size() [drivers/pci/pci_indirect.c] if you were curious about our u-boot board settings, please refer to: http: //www.mail-archive. com/linuxppc-dev@lists.ozlabs.org/msg62007.html thanx alot, Davide * *[1]* * PCIE1 used as Root Complex (base addr ffe09000) Scanning PCI bus 01 01 00 1b65 abba 0280 00 cfg_addr:ffe09000 cfg_data: ffe09004 indirect_type:0 PCIE1 on bus 00 - 01 PCIE2 used as Root Complex (base addr ffe0a000) Scanning PCI bus 03 03 00 1b65 abba 0280 00 cfg_addr:ffe0a000 cfg_data: ffe0a004 indirect_type:0 PCIE2 on bus 02 - 03 * * [2]* * = pci 0 long Scanning PCI devices on bus 0 Found PCI device 00.00.00: vendor ID = 0x1957 device ID = 0x0100 command register =0x0006 status register = 0x0010 revision ID = 0x11 class code = 0x0b (Processor) sub class code = 0x20 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x01 BIST =0x00 base address 0 = 0xfff0 base address 1 = 0x primary bus number = 0x00 secondary bus number =0x01 subordinate bus number = 0x01 secondary latency timer = 0x00 IO base = 0x00 IO limit =0x00 secondary status =0x memory base = 0xa000 memory limit =0xa000 prefetch memory base = 0x1001 prefetch memory limit = 0x0001 prefetch memory base upper = 0x prefetch memory limit upper = 0x IO base upper 16 bits = 0x IO limit upper 16 bits = 0x expansion ROM base address = 0x interrupt line = 0x00 interrupt pin = 0x00 bridge control = 0x = pci 1 long Scanning PCI devices on bus 1 Found PCI device 01.00.00:kk vendor ID = 0x1b65 device ID = 0xabba command register =0x0006 status register = 0x0010 revision ID = 0x01 class code = 0x02 (Network controller) sub class code = 0x80 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x00 BIST =0x00 base address 0 = 0xa000 base address 1 = 0xa001 base address 2 = 0x base address 3 = 0x base address 4 = 0x base address 5 = 0x cardBus CIS pointer = 0x sub system vendor ID = 0x sub system ID = 0x expansion ROM base address = 0x interrupt line = 0x00 interrupt pin = 0x01 min Grant = 0x00 max Latency = 0x00 = pci 2 long Scanning PCI devices on bus 2 Found PCI device 02.00.00: vendor ID = 0x1957 device ID = 0x0100 command register =0x0006 status register = 0x0010 revision ID = 0x11 class code = 0x0b (Processor) sub class code = 0x20 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x01 BIST =0x00 base address 0 = 0xfff0 base address 1 = 0x primary bus number = 0x00 secondary bus number =0x01
Re: PCI device not working
On Oct 4, 2012, at 7:24 AM, Davide Viti wrote: Hi, it turns out that if define CONFIG_PCI_NOSCAN in u-boot (as per [1]), the devide behind the second controller is detected by the Linux kernel. Would you suggest any particular patch I should apply to fix this (I'm using kernel 2.6.34) thanx alot in advance Davide [1] http://permalink.gmane.org/gmane. linux.ports.ppc.embedded/20140 My suggestion would be to try and dump all the controller registers between the case that works and doesn't and compare. There's some minor setting difference that I'm guessing is causing issues. - k Messaggio originale Da: zino...@tiscali.it Data: 28/09/2012 16.48 A: ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org Ogg: R: Re: PCI device not working Hi Kumar, It was, can you figure out in u-boot what exact config read on the bus would return the correct thing. The fact that when we probe the device at 0001:03 we should get back something like cfg_data=0xabba1b65 here follow some details about what is going on inside u-boot; verbosity increases from [1] to [3] [1] PCI printouts when the board come up [2] output of pci [0-3] long u-boot command [3] same as [1] but with debug print inside indirect_read_config_##size() [drivers/pci/pci_indirect.c] if you were curious about our u-boot board settings, please refer to: http: //www.mail-archive. com/linuxppc-dev@lists.ozlabs.org/msg62007.html thanx alot, Davide * *[1]* * PCIE1 used as Root Complex (base addr ffe09000) Scanning PCI bus 01 01 00 1b65 abba 0280 00 cfg_addr:ffe09000 cfg_data: ffe09004 indirect_type:0 PCIE1 on bus 00 - 01 PCIE2 used as Root Complex (base addr ffe0a000) Scanning PCI bus 03 03 00 1b65 abba 0280 00 cfg_addr:ffe0a000 cfg_data: ffe0a004 indirect_type:0 PCIE2 on bus 02 - 03 * * [2]* * = pci 0 long Scanning PCI devices on bus 0 Found PCI device 00.00.00: vendor ID = 0x1957 device ID = 0x0100 command register =0x0006 status register = 0x0010 revision ID = 0x11 class code = 0x0b (Processor) sub class code = 0x20 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x01 BIST =0x00 base address 0 = 0xfff0 base address 1 = 0x primary bus number = 0x00 secondary bus number =0x01 subordinate bus number = 0x01 secondary latency timer = 0x00 IO base = 0x00 IO limit =0x00 secondary status =0x memory base = 0xa000 memory limit =0xa000 prefetch memory base = 0x1001 prefetch memory limit = 0x0001 prefetch memory base upper = 0x prefetch memory limit upper = 0x IO base upper 16 bits = 0x IO limit upper 16 bits = 0x expansion ROM base address = 0x interrupt line = 0x00 interrupt pin = 0x00 bridge control = 0x = pci 1 long Scanning PCI devices on bus 1 Found PCI device 01.00.00:kk vendor ID = 0x1b65 device ID = 0xabba command register =0x0006 status register = 0x0010 revision ID = 0x01 class code = 0x02 (Network controller) sub class code = 0x80 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x00 BIST =0x00 base address 0 = 0xa000 base address 1 = 0xa001 base address 2 = 0x base address 3 = 0x base address 4 = 0x base address 5 = 0x cardBus CIS pointer = 0x sub system vendor ID = 0x sub system ID = 0x expansion ROM base address = 0x interrupt line = 0x00 interrupt pin = 0x01 min Grant = 0x00 max Latency = 0x00 = pci 2 long Scanning PCI devices on bus 2 Found PCI device 02.00.00: vendor ID = 0x1957 device ID = 0x0100 command register =0x0006 status register = 0x0010 revision ID = 0x11 class code = 0x0b (Processor) sub class code = 0x20 programming
R: Re: PCI device not working
Hi Kumar, It was, can you figure out in u-boot what exact config read on the bus would return the correct thing. The fact that when we probe the device at 0001:03 we should get back something like cfg_data=0xabba1b65 here follow some details about what is going on inside u-boot; verbosity increases from [1] to [3] [1] PCI printouts when the board come up [2] output of pci [0-3] long u-boot command [3] same as [1] but with debug print inside indirect_read_config_##size() [drivers/pci/pci_indirect.c] if you were curious about our u-boot board settings, please refer to: http://www.mail-archive. com/linuxppc-dev@lists.ozlabs.org/msg62007.html thanx alot, Davide * *[1]* * PCIE1 used as Root Complex (base addr ffe09000) Scanning PCI bus 01 01 00 1b65 abba 0280 00 cfg_addr:ffe09000 cfg_data:ffe09004 indirect_type:0 PCIE1 on bus 00 - 01 PCIE2 used as Root Complex (base addr ffe0a000) Scanning PCI bus 03 03 00 1b65 abba 0280 00 cfg_addr:ffe0a000 cfg_data:ffe0a004 indirect_type:0 PCIE2 on bus 02 - 03 * *[2]* * = pci 0 long Scanning PCI devices on bus 0 Found PCI device 00.00.00: vendor ID = 0x1957 device ID = 0x0100 command register =0x0006 status register = 0x0010 revision ID = 0x11 class code = 0x0b (Processor) sub class code = 0x20 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x01 BIST =0x00 base address 0 = 0xfff0 base address 1 = 0x primary bus number = 0x00 secondary bus number =0x01 subordinate bus number = 0x01 secondary latency timer = 0x00 IO base = 0x00 IO limit =0x00 secondary status =0x memory base = 0xa000 memory limit =0xa000 prefetch memory base =0x1001 prefetch memory limit = 0x0001 prefetch memory base upper = 0x prefetch memory limit upper = 0x IO base upper 16 bits = 0x IO limit upper 16 bits = 0x expansion ROM base address = 0x interrupt line = 0x00 interrupt pin = 0x00 bridge control = 0x = pci 1 long Scanning PCI devices on bus 1 Found PCI device 01.00.00:kk vendor ID = 0x1b65 device ID = 0xabba command register =0x0006 status register = 0x0010 revision ID = 0x01 class code = 0x02 (Network controller) sub class code = 0x80 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x00 BIST =0x00 base address 0 = 0xa000 base address 1 = 0xa001 base address 2 = 0x base address 3 = 0x base address 4 = 0x base address 5 = 0x cardBus CIS pointer = 0x sub system vendor ID =0x sub system ID = 0x expansion ROM base address = 0x interrupt line = 0x00 interrupt pin = 0x01 min Grant = 0x00 max Latency = 0x00 = pci 2 long Scanning PCI devices on bus 2 Found PCI device 02.00.00: vendor ID = 0x1957 device ID = 0x0100 command register =0x0006 status register = 0x0010 revision ID = 0x11 class code = 0x0b (Processor) sub class code = 0x20 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x01 BIST =0x00 base address 0 = 0xfff0 base address 1 = 0x primary bus number = 0x00 secondary bus number =0x01 subordinate bus number = 0x01 secondary latency timer = 0x00 IO base = 0x00 IO limit =0x00 secondary status =0x memory base = 0xb000 memory limit =0xb000 prefetch memory base =0x1001 prefetch memory limit = 0x0001 prefetch memory base upper = 0x prefetch memory limit upper = 0x IO base upper 16 bits = 0x IO limit upper 16 bits = 0x expansion ROM base address = 0x interrupt line =
R: Re: PCI device not working
Hi, So its odd that scanning of the second bus didn't report any devices. Do you have code that implements ppc_md.pci_exclude_device ? not that I'm aware of You might also want to put some code in the indirect PCI ops (indirect.c) to see what actual values you are getting from various indirect_read_config() calls. To make sure that ppc_md.pci_exclude_device is not implemented, I've put some printouts inside indirect_read_config(): I print various parameters when the function is called, and when it returns and note that: 1. indirect_read_config() is called 422 times: 174 times for [/pcie@ffe0a000] (controller where the device is not detected) 248 times for [/pcie@ffe09000] 2. ppc_md.pci_exclude_device is always NULL 3. the function always returns with PCIBIOS_SUCCESSFUL 4. the only call to indirect_read_config() inside which bus_no=0x3, returns with the following log: pci_bus 0001:03: scanning bus - ind_r_config - [/pcie@ffe0a000] devfn=0x0 len=0x4 hose-indirect_type=0x16 hose-first_busno=0x2 bus- number=0x3 - ind_r_config [/pcie@ffe0a000] - (bus_no=0x3 reg=0x0 cfg_data=0x len=0xff7eb004) val=0x4 PCIBIOS_SUCCESSFUL the entire log is about 116Kb and is available in [1] or [2] (didn't feel like pasting so much data on the ML) thanx alot, Davide [1] http://pastebin.com/JaPGmmfs [2] http://paste2.org/p/2273728 Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
On Sep 27, 2012, at 6:43 AM, Davide Viti wrote: Hi, So its odd that scanning of the second bus didn't report any devices. Do you have code that implements ppc_md.pci_exclude_device ? not that I'm aware of You might also want to put some code in the indirect PCI ops (indirect.c) to see what actual values you are getting from various indirect_read_config() calls. To make sure that ppc_md.pci_exclude_device is not implemented, I've put some printouts inside indirect_read_config(): I print various parameters when the function is called, and when it returns and note that: 1. indirect_read_config() is called 422 times: 174 times for [/pcie@ffe0a000] (controller where the device is not detected) 248 times for [/pcie@ffe09000] 2. ppc_md.pci_exclude_device is always NULL 3. the function always returns with PCIBIOS_SUCCESSFUL 4. the only call to indirect_read_config() inside which bus_no=0x3, returns with the following log: pci_bus 0001:03: scanning bus - ind_r_config - [/pcie@ffe0a000] devfn=0x0 len=0x4 hose-indirect_type=0x16 hose-first_busno=0x2 bus- number=0x3 - ind_r_config [/pcie@ffe0a000] - (bus_no=0x3 reg=0x0 cfg_data=0x len=0xff7eb004) val=0x4 PCIBIOS_SUCCESSFUL Can you see what bus_no actually gets set to in the case we scan 0001:03 ? If its set to 03, can you try hack it to 1. - k the entire log is about 116Kb and is available in [1] or [2] (didn't feel like pasting so much data on the ML) thanx alot, Davide [1] http://pastebin.com/JaPGmmfs [2] http://paste2.org/p/2273728 Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
R: Re: PCI device not working
Hi Kumar,
Messaggio originale
Da: ga...@kernel.crashing.org
Data:
27/09/2012 14.27
A: Davide Vitizino...@tiscali.it
Cc: linuxppc-dev@lists.
ozlabs.org
Ogg: Re: PCI device not working
...
Can you see what bus_no
actually gets set to in the case we scan 0001:03 ?
If its set to 03, can you
try hack it to 1.
is this what you mean?
---
a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
bus_no = (bus-number == hose-first_busno) ?
hose-self_busno : bus-number;
+ if (bus_no == 3) {
+ printk
(*** force bus_no 3 - 1 ***\n);
+ bus_no = 1;
+ }
+
I've
tested a kernel with the above patch and this is what is printed on the log:
pci_bus 0001:03: scanning bus
- ind_r_config - [/pcie@ffe0a000] devfn=0x0
offset=0x0 len=0x4 hose-indirect_type=0x16 hose-first_busno=0x2 bus-
number=0x3
*** force bus_no 3 - 1 ***
- ind_r_config [/pcie@ffe0a000] -
(bus_no=0x1 reg=0x0 cfg_data=0xff7eb004 len=0x4 hose-cfg_addr=0xff7eb000)
val=0x PCIBIOS_SUCCESSFUL
the entire log (132Kb) is available in [1]
and [2]
thanx for your help,
Davide
[1] http://pastebin.com/3mcbDzwY
[2] http:
//paste2.org/p/2274032
Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di
uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un
amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
On Sep 27, 2012, at 8:14 AM, Davide Viti wrote:
Hi Kumar,
Messaggio originale
Da: ga...@kernel.crashing.org
Data:
27/09/2012 14.27
A: Davide Vitizino...@tiscali.it
Cc: linuxppc-dev@lists.
ozlabs.org
Ogg: Re: PCI device not working
...
Can you see what bus_no
actually gets set to in the case we scan 0001:03 ?
If its set to 03, can you
try hack it to 1.
is this what you mean?
It was, can you figure out in u-boot what exact config read on the bus would
return the correct thing.
The fact that when we probe the device at 0001:03 we should get back something
like cfg_data=0xabba1b65
- k
---
a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
bus_no = (bus-number == hose-first_busno) ?
hose-self_busno : bus-number;
+ if (bus_no == 3) {
+ printk
(*** force bus_no 3 - 1 ***\n);
+ bus_no = 1;
+ }
+
I've
tested a kernel with the above patch and this is what is printed on the log:
pci_bus 0001:03: scanning bus
- ind_r_config - [/pcie@ffe0a000] devfn=0x0
offset=0x0 len=0x4 hose-indirect_type=0x16 hose-first_busno=0x2 bus-
number=0x3
*** force bus_no 3 - 1 ***
- ind_r_config [/pcie@ffe0a000] -
(bus_no=0x1 reg=0x0 cfg_data=0xff7eb004 len=0x4 hose-cfg_addr=0xff7eb000)
val=0x PCIBIOS_SUCCESSFUL
the entire log (132Kb) is available in [1]
and [2]
thanx for your help,
Davide
[1] http://pastebin.com/3mcbDzwY
[2] http:
//paste2.org/p/2274032
Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di
uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un
amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
2012/9/24 Davide Viti zino...@tiscali.it Hi, does the output I've included show anything wrong or should I post something else to help identifying the cause of the problem? thank you in advance, Davide 2012/9/21 Davide Viti zino...@tiscali.it I mean there are two controllers and both of them have a device subtended (both 0x1b65:0xabba). u-boot can see both devices, linux detects only the device attached to the first controller. Here's the output of lspci and /proc/iomem : root@(none):/# lspci -v :00:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: a000-afff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting :01:00.0 Class 0280: Device 1b65:abba (rev 01) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at a000 (32-bit, non-prefetchable) [size=1K] Memory at a001 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Power Management version 3 Capabilities: [80] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel ? Capabilities: [800] Advanced Error Reporting 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: b000-bfff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting Its possible that in linux the 2nd controller does not believe it has link status. Can you see if there is a function like fsl_pcie_check_link() in your kernel. If so maybe add a printk debug message there and see what gets return. Also helpful to post a full boot log. root@(none):/# cat /proc/iomem a000-afff : /pcie@ffe09000 a000-afff : PCI Bus :01 a000-a3ff : :01:00.0 a001-a001 : :01:00.0 b000-bfff : /pcie@ffe0a000 b000-bfff : PCI Bus 0001:03 ef00-efff : ef00.nor ffe04500-ffe04507 : serial ffe04600-ffe04607 : serial thanx for your help, Davide I mean that the kernel detects the first controller and the device attached to it, plus the second controller: the device on the second controller is not detected (same device as the one detected on the first controller) 2012/9/21 Kumar Gala ga...@kernel.crashing.org On Sep 21, 2012, at 6:33 AM, Davide Viti wrote: Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b65 0xabba Network controller 0x80 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x1b65 0xabba Network controller 0x80 The kernel detects only the first instance of the device. What do you mean by first instance of the device ? Didn't get very far while looking at dts file and kernel logs, so I'm asking for some help on narrowing down the problem. I'm wondering if I can assume that the problem is restricted to kernel/dts and avoid concentrating on uboot. I can provide any log (didn't want to post tons of details on the first message) Probably a dts issue. What does lspci in linux say? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org
Re: PCI device not working
Hi, as you've suggested, I've added a printout inside fsl_pcie_check_link() which is called twice and returns 0 both times. Here follows the PCI-related part of dmesg with some extra printouts enabled. thank you, Davide ... Adding PCI host bridge /pcie@ffe09000 *** [/pcie@ffe09000] fsl_pcie_check_link() val=0x16 = return 0 ^^^ Found FSL PCI host bridge at 0xffe09000. Firmware bus number: 0-255 -Hose at 0xc05a2000, cfg_addr=0xff7fd000,cfg_data=0xff7fd004 PCI host bridge /pcie@ffe09000 ranges: MEM 0xa000..0xafff - 0xa000 IO 0xffc1..0xffc1 - 0x PCI memory map start 0xffe09000, size 0x1000 PCI MEM resource start 0xa000, size 0x1000. PCI IO resource start 0x, size 0x0001, phy base 0xffc1. /pcie@ffe09000: PCICSRBAR @ 0xfff0 Adding PCI host bridge /pcie@ffe0a000 *** [/pcie@ffe0a000] fsl_pcie_check_link() val=0x16 = return 0 ^^^ Found FSL PCI host bridge at 0xffe0a000. Firmware bus number: 0-255 -Hose at 0xc05a20e0, cfg_addr=0xff7eb000,cfg_data=0xff7eb004 PCI host bridge /pcie@ffe0a000 ranges: MEM 0xb000..0xbfff - 0xb000 IO 0xffc0..0xffc0 - 0x PCI memory map start 0xffe0a000, size 0x1000 PCI MEM resource start 0xb000, size 0x1000. PCI IO resource start 0x, size 0x0001, phy base 0xffc0. /pcie@ffe0a000: PCICSRBAR @ 0xfff0 ... PCI: Probing PCI hardware PCI: Scanning PHB /pcie@ffe09000 PCI: PHB IO resource= ff7ed000-ff7fcfff [100] PCI: PHB MEM resource 0 = a000-afff [200] PCI: PHB MEM offset = PCI: PHB IO offset = ff7ed000 probe mode: 0 pci_bus :00: scanning bus pci :00:00.0: found [1957:0100] class 000b20 header type 01 pci :00:00.0: ignoring class b20 (doesn't match header type 01) pci :00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x54 pci :00:00.0: calling pcibios_fixup_resources+0x0/0x19c pci :00:00.0: calling quirk_fsl_pcie_header+0x0/0x50 pci :00:00.0: calling quirk_resource_alignment+0x0/0x1a8 pci :00:00.0: supports D1 D2 pci :00:00.0: PME# supported from D0 D1 D2 D3hot D3cold pci :00:00.0: PME# disabled pci_bus :00: fixups for bus PCI: Fixup bus devices 0 (PHB) pci_busdev_to_OF_node(0,0x0) parent is /pcie@ffe09000 *** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0 result is /pcie@ffe09000/pcie@0 PCI: Try to map irq for :00:00.0... pci_busdev_to_OF_node(0,0x0) parent is /pcie@ffe09000 *** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0 result is /pcie@ffe09000/pcie@0 pci :00:00.0: scanning [bus 01-01] behind bridge, pass 0 pci :00:00.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus :01: scanning bus pci :01:00.0: found [1b65:abba] class 000280 header type 00 pci :01:00.0: reg 10: [mem 0xa000-0xa3ff] pci :01:00.0: reg 14: [mem 0xa001-0xa001] pci :01:00.0: calling pcibios_fixup_resources+0x0/0x19c PCI::01:00.0 Resource 0 a000-a3ff [40200] fixup... PCI::01:00.0a000-a3ff PCI::01:00.0 Resource 1 a001-a001 [40200] fixup... PCI::01:00.0a001-a001 pci :01:00.0: calling quirk_resource_alignment+0x0/0x1a8 pci_bus :01: fixups for bus pci :00:00.0: PCI bridge to [bus 01-ff] pci :00:00.0: bridge window [io 0x-0x] (disabled) pci :00:00.0: bridge window [mem 0xa000-0xa00f] pci :00:00.0: bridge window [mem 0x1000-0x000f pref] (disabled) PCI::00:00.0 Bus rsrc 1 a000-a00f [200] fixup... PCI::00:00.0a000-a00f PCI: Fixup bus devices 1 (:00:00.0) pci_busdev_to_OF_node(1,0x0) *** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0 parent is /pcie@ffe09000/pcie@0 result is NULL PCI: Try to map irq for :01:00.0... pci_busdev_to_OF_node(1,0x0) *** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0 parent is /pcie@ffe09000/pcie@0 result is NULL pci_busdev_to_OF_node(0,0x0) parent is /pcie@ffe09000 *** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0 result is /pcie@ffe09000/pcie@0 Got one, spec 1 cells (0x0001 0x...) on /soc@ffe0/pic@4 alloc irq_desc for 16 on node 0 alloc kstat_irqs on node 0 irq: irq 1 on host /soc@ffe0/pic@4 mapped to virtual irq 16 Mapped to linux irq 16 pci_bus :01: bus scan returning with max=01 pci_bus :00: bus scan returning with max=01 PCI: Scanning PHB /pcie@ffe0a000 PCI: PHB IO resource=
Re: PCI device not working
On Sep 26, 2012, at 10:25 AM, Davide Viti wrote: Hi, as you've suggested, I've added a printout inside fsl_pcie_check_link() which is called twice and returns 0 both times. Here follows the PCI-related part of dmesg with some extra printouts enabled. thank you, Davide So its odd that scanning of the second bus didn't report any devices. Do you have code that implements ppc_md.pci_exclude_device ? If so, what does it do? You might also want to put some code in the indirect PCI ops (indirect.c) to see what actual values you are getting from various indirect_read_config() calls. - k ... Adding PCI host bridge /pcie@ffe09000 *** [/pcie@ffe09000] fsl_pcie_check_link() val=0x16 = return 0 ^^^ Found FSL PCI host bridge at 0xffe09000. Firmware bus number: 0-255 -Hose at 0xc05a2000, cfg_addr=0xff7fd000,cfg_data=0xff7fd004 PCI host bridge /pcie@ffe09000 ranges: MEM 0xa000..0xafff - 0xa000 IO 0xffc1..0xffc1 - 0x PCI memory map start 0xffe09000, size 0x1000 PCI MEM resource start 0xa000, size 0x1000. PCI IO resource start 0x, size 0x0001, phy base 0xffc1. /pcie@ffe09000: PCICSRBAR @ 0xfff0 Adding PCI host bridge /pcie@ffe0a000 *** [/pcie@ffe0a000] fsl_pcie_check_link() val=0x16 = return 0 ^^^ Found FSL PCI host bridge at 0xffe0a000. Firmware bus number: 0-255 -Hose at 0xc05a20e0, cfg_addr=0xff7eb000,cfg_data=0xff7eb004 PCI host bridge /pcie@ffe0a000 ranges: MEM 0xb000..0xbfff - 0xb000 IO 0xffc0..0xffc0 - 0x PCI memory map start 0xffe0a000, size 0x1000 PCI MEM resource start 0xb000, size 0x1000. PCI IO resource start 0x, size 0x0001, phy base 0xffc0. /pcie@ffe0a000: PCICSRBAR @ 0xfff0 ... PCI: Probing PCI hardware PCI: Scanning PHB /pcie@ffe09000 PCI: PHB IO resource= ff7ed000-ff7fcfff [100] PCI: PHB MEM resource 0 = a000-afff [200] PCI: PHB MEM offset = PCI: PHB IO offset = ff7ed000 probe mode: 0 pci_bus :00: scanning bus pci :00:00.0: found [1957:0100] class 000b20 header type 01 pci :00:00.0: ignoring class b20 (doesn't match header type 01) pci :00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x54 pci :00:00.0: calling pcibios_fixup_resources+0x0/0x19c pci :00:00.0: calling quirk_fsl_pcie_header+0x0/0x50 pci :00:00.0: calling quirk_resource_alignment+0x0/0x1a8 pci :00:00.0: supports D1 D2 pci :00:00.0: PME# supported from D0 D1 D2 D3hot D3cold pci :00:00.0: PME# disabled pci_bus :00: fixups for bus PCI: Fixup bus devices 0 (PHB) pci_busdev_to_OF_node(0,0x0) parent is /pcie@ffe09000 *** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0 result is /pcie@ffe09000/pcie@0 PCI: Try to map irq for :00:00.0... pci_busdev_to_OF_node(0,0x0) parent is /pcie@ffe09000 *** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0 result is /pcie@ffe09000/pcie@0 pci :00:00.0: scanning [bus 01-01] behind bridge, pass 0 pci :00:00.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus :01: scanning bus pci :01:00.0: found [1b65:abba] class 000280 header type 00 pci :01:00.0: reg 10: [mem 0xa000-0xa3ff] pci :01:00.0: reg 14: [mem 0xa001-0xa001] pci :01:00.0: calling pcibios_fixup_resources+0x0/0x19c PCI::01:00.0 Resource 0 a000-a3ff [40200] fixup... PCI::01:00.0a000-a3ff PCI::01:00.0 Resource 1 a001-a001 [40200] fixup... PCI::01:00.0a001-a001 pci :01:00.0: calling quirk_resource_alignment+0x0/0x1a8 pci_bus :01: fixups for bus pci :00:00.0: PCI bridge to [bus 01-ff] pci :00:00.0: bridge window [io 0x-0x] (disabled) pci :00:00.0: bridge window [mem 0xa000-0xa00f] pci :00:00.0: bridge window [mem 0x1000-0x000f pref] (disabled) PCI::00:00.0 Bus rsrc 1 a000-a00f [200] fixup... PCI::00:00.0a000-a00f PCI: Fixup bus devices 1 (:00:00.0) pci_busdev_to_OF_node(1,0x0) *** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0 parent is /pcie@ffe09000/pcie@0 result is NULL PCI: Try to map irq for :01:00.0... pci_busdev_to_OF_node(1,0x0) *** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0 parent is /pcie@ffe09000/pcie@0 result is NULL pci_busdev_to_OF_node(0,0x0) parent is /pcie@ffe09000 *** scan_OF_for_pci_dev()
Re: PCI device not working
2012/9/21 Davide Viti zino...@tiscali.it I mean there are two controllers and both of them have a device subtended (both 0x1b65:0xabba). u-boot can see both devices, linux detects only the device attached to the first controller. Here's the output of lspci and /proc/iomem : root@(none):/# lspci -v :00:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: a000-afff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting :01:00.0 Class 0280: Device 1b65:abba (rev 01) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at a000 (32-bit, non-prefetchable) [size=1K] Memory at a001 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Power Management version 3 Capabilities: [80] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel ? Capabilities: [800] Advanced Error Reporting 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: b000-bfff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting root@(none):/# cat /proc/iomem a000-afff : /pcie@ffe09000 a000-afff : PCI Bus :01 a000-a3ff : :01:00.0 a001-a001 : :01:00.0 b000-bfff : /pcie@ffe0a000 b000-bfff : PCI Bus 0001:03 ef00-efff : ef00.nor ffe04500-ffe04507 : serial ffe04600-ffe04607 : serial thanx for your help, Davide I mean that the kernel detects the first controller and the device attached to it, plus the second controller: the device on the second controller is not detected (same device as the one detected on the first controller) 2012/9/21 Kumar Gala ga...@kernel.crashing.org On Sep 21, 2012, at 6:33 AM, Davide Viti wrote: Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b65 0xabba Network controller 0x80 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x1b65 0xabba Network controller 0x80 The kernel detects only the first instance of the device. What do you mean by first instance of the device ? Didn't get very far while looking at dts file and kernel logs, so I'm asking for some help on narrowing down the problem. I'm wondering if I can assume that the problem is restricted to kernel/dts and avoid concentrating on uboot. I can provide any log (didn't want to post tons of details on the first message) Probably a dts issue. What does lspci in linux say? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
Hi, does the output I've included show anything wrong or should I post something else to help identifying the cause of the problem? thank you in advance, Davide 2012/9/21 Davide Viti zino...@tiscali.it I mean there are two controllers and both of them have a device subtended (both 0x1b65:0xabba). u-boot can see both devices, linux detects only the device attached to the first controller. Here's the output of lspci and /proc/iomem : root@(none):/# lspci -v :00:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: a000-afff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting :01:00.0 Class 0280: Device 1b65:abba (rev 01) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at a000 (32-bit, non-prefetchable) [size=1K] Memory at a001 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Power Management version 3 Capabilities: [80] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel ? Capabilities: [800] Advanced Error Reporting 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: b000-bfff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting root@(none):/# cat /proc/iomem a000-afff : /pcie@ffe09000 a000-afff : PCI Bus :01 a000-a3ff : :01:00.0 a001-a001 : :01:00.0 b000-bfff : /pcie@ffe0a000 b000-bfff : PCI Bus 0001:03 ef00-efff : ef00.nor ffe04500-ffe04507 : serial ffe04600-ffe04607 : serial thanx for your help, Davide I mean that the kernel detects the first controller and the device attached to it, plus the second controller: the device on the second controller is not detected (same device as the one detected on the first controller) 2012/9/21 Kumar Gala ga...@kernel.crashing.org On Sep 21, 2012, at 6:33 AM, Davide Viti wrote: Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b65 0xabba Network controller 0x80 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x1b65 0xabba Network controller 0x80 The kernel detects only the first instance of the device. What do you mean by first instance of the device ? Didn't get very far while looking at dts file and kernel logs, so I'm asking for some help on narrowing down the problem. I'm wondering if I can assume that the problem is restricted to kernel/dts and avoid concentrating on uboot. I can provide any log (didn't want to post tons of details on the first message) Probably a dts issue. What does lspci in linux say? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
Here are the settings for PCI we currently have in uboot: #define CONFIG_PCI 1/* Enable PCI/PCIE */ #define CONFIG_PCIE1 1/* PCIE controler 1 (slot 1) */ #define CONFIG_PCIE2 1/* PCIE controler 2 (slot 2) */ #define CONFIG_FSL_PCI_INIT 1/* Use common FSL init code */ #define CONFIG_FSL_PCIE_RESET 1/* need PCIe reset errata */ #define CONFIG_FSL_LAW1/* Use common FSL init code */ #define CONFIG_SYS_PCIE1_ADDR(CONFIG_SYS_CCSRBAR+0x9000) #define CONFIG_SYS_PCIE2_ADDR(CONFIG_SYS_CCSRBAR+0xa000) /* * General PCI */ #define CONFIG_SYS_PCIE1_MEM_VIRT 0xA000 #define CONFIG_SYS_PCIE1_MEM_BUS 0xA000 #define CONFIG_SYS_PCIE1_MEM_PHYS 0xA000 #define CONFIG_SYS_PCIE1_MEM_SIZE 0x1000 #define CONFIG_SYS_PCIE1_IO_VIRT 0xFFC1 #define CONFIG_SYS_PCIE1_IO_BUS0x #define CONFIG_SYS_PCIE1_IO_PHYS 0xFFC1 #define CONFIG_SYS_PCIE1_IO_SIZE 0x0001/* 64k */ #define CONFIG_SYS_PCIE2_MEM_VIRT 0xB000 #define CONFIG_SYS_PCIE2_MEM_BUS 0xB000 #define CONFIG_SYS_PCIE2_MEM_PHYS 0xB000 #define CONFIG_SYS_PCIE2_MEM_SIZE 0x1000 #define CONFIG_SYS_PCIE2_IO_VIRT 0xFFC0 #define CONFIG_SYS_PCIE2_IO_BUS0x #define CONFIG_SYS_PCIE2_IO_PHYS 0xFFC0 #define CONFIG_SYS_PCIE2_IO_SIZE 0x0001/* 64k */ I'd really appreciate I you could take a look at it Thanx alot in advance Davide 2012/9/24 Davide Viti zino...@tiscali.it Hi, does the output I've included show anything wrong or should I post something else to help identifying the cause of the problem? thank you in advance, Davide 2012/9/21 Davide Viti zino...@tiscali.it I mean there are two controllers and both of them have a device subtended (both 0x1b65:0xabba). u-boot can see both devices, linux detects only the device attached to the first controller. Here's the output of lspci and /proc/iomem : root@(none):/# lspci -v :00:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: a000-afff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting :01:00.0 Class 0280: Device 1b65:abba (rev 01) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at a000 (32-bit, non-prefetchable) [size=1K] Memory at a001 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Power Management version 3 Capabilities: [80] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel ? Capabilities: [800] Advanced Error Reporting 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: b000-bfff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting root@(none):/# cat /proc/iomem a000-afff : /pcie@ffe09000 a000-afff : PCI Bus :01 a000-a3ff : :01:00.0 a001-a001 : :01:00.0 b000-bfff : /pcie@ffe0a000 b000-bfff : PCI Bus 0001:03 ef00-efff : ef00.nor ffe04500-ffe04507 : serial ffe04600-ffe04607 : serial thanx for your help, Davide I mean that the kernel detects the first controller and the device attached to it, plus the second controller: the device on the second controller is not detected (same device as the one detected on the first controller) 2012/9/21 Kumar Gala ga...@kernel.crashing.org On Sep 21, 2012, at 6:33 AM, Davide Viti wrote: Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100
PCI device not working
Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b65 0xabba Network controller 0x80 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x1b65 0xabba Network controller 0x80 The kernel detects only the first instance of the device. Didn't get very far while looking at dts file and kernel logs, so I'm asking for some help on narrowing down the problem. I'm wondering if I can assume that the problem is restricted to kernel/dts and avoid concentrating on uboot. I can provide any log (didn't want to post tons of details on the first message) Thanx in advance for your help, regards Davide ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
On Sep 21, 2012, at 6:33 AM, Davide Viti wrote: Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b65 0xabba Network controller 0x80 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x1b65 0xabba Network controller 0x80 The kernel detects only the first instance of the device. What do you mean by first instance of the device ? Didn't get very far while looking at dts file and kernel logs, so I'm asking for some help on narrowing down the problem. I'm wondering if I can assume that the problem is restricted to kernel/dts and avoid concentrating on uboot. I can provide any log (didn't want to post tons of details on the first message) Probably a dts issue. What does lspci in linux say? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
I mean there are two controllers and both of them have a device subtended (both 0x1b65:0xabba). u-boot can see both devices, linux detects only the device attached to the first controller. Here's the output of lspci and /proc/iomem : root@(none):/# lspci -v :00:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: a000-afff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting :01:00.0 Class 0280: Device 1b65:abba (rev 01) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at a000 (32-bit, non-prefetchable) [size=1K] Memory at a001 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Power Management version 3 Capabilities: [80] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel ? Capabilities: [800] Advanced Error Reporting 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: b000-bfff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting root@(none):/# cat /proc/iomem a000-afff : /pcie@ffe09000 a000-afff : PCI Bus :01 a000-a3ff : :01:00.0 a001-a001 : :01:00.0 b000-bfff : /pcie@ffe0a000 b000-bfff : PCI Bus 0001:03 ef00-efff : ef00.nor ffe04500-ffe04507 : serial ffe04600-ffe04607 : serial thanx for your help, Davide I mean that the kernel detects the first controller and the device attached to it, plus the second controller: the device on the second controller is not detected (same device as the one detected on the first controller) 2012/9/21 Kumar Gala ga...@kernel.crashing.org On Sep 21, 2012, at 6:33 AM, Davide Viti wrote: Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b65 0xabba Network controller 0x80 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x1b65 0xabba Network controller 0x80 The kernel detects only the first instance of the device. What do you mean by first instance of the device ? Didn't get very far while looking at dts file and kernel logs, so I'm asking for some help on narrowing down the problem. I'm wondering if I can assume that the problem is restricted to kernel/dts and avoid concentrating on uboot. I can provide any log (didn't want to post tons of details on the first message) Probably a dts issue. What does lspci in linux say? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
