* device not available because of BAR 0 collisions
@ 2011-04-25 20:10 Steven A. Falco
2011-04-26 0:01 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 11+ messages in thread
From: Steven A. Falco @ 2011-04-25 20:10 UTC (permalink / raw)
To: linuxppc-dev
I'm getting an error message when trying to talk to some custom hardware:
dx83xx 0001:43:00.0: device not available because of BAR 0 [0xa1000000-0xa1ffffff] collisions
I see in setup-res.c that this message comes out when there is no parent for
a device resource.
I've been digging around in the code, and I confess that I cannot figure out
where the parent member is assigned. Can someone please give me a hint as to
where the assignment happens?
The hardware consists of a pair of ASICs attached to a PPC405EX via a PCIe switch.
The device tree is based on the Kilauea evaluation board. The device tree does not
specify the PCIe switch or ASICs.
Do I need to add something to the device tree to represent the PCIe switch, or
should it be automatically discovered and configured?
U-Boot reports the PCI hardware as:
PCIE0: successfully set as root-complex
01 00 1172 0004 ff00 00
PCIE1: successfully set as root-complex
05 00 1b03 7000 0000 ff
04 01 10b5 8613 0604 00
06 00 1b03 7000 0000 ff
04 02 10b5 8613 0604 00
03 00 10b5 8613 0604 00
The PCIe switch shows up as 03:00, 04:01, and 04:02. The ASICs show up as 05:00 and
06:00, so there is no problem with config-space that I can see.
Similar hardware (an evaluation board for the ASICs) works ok on an x86 PC. The
PCIe switch is recognized, and the ASIC driver probes and enables the device
without any problems. Sadly, I cannot plug it into the Kilauea because it needs a
PCIe x16 slot.
Guidance gratefully accepted!
Steve
--
A: Because it makes the logic of the discussion difficult to follow.
Q: Why shouldn't I top post?
A: No.
Q: Should I top post?
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: device not available because of BAR 0 collisions 2011-04-25 20:10 device not available because of BAR 0 collisions Steven A. Falco @ 2011-04-26 0:01 ` Benjamin Herrenschmidt 2011-04-26 13:38 ` Steven A. Falco 0 siblings, 1 reply; 11+ messages in thread From: Benjamin Herrenschmidt @ 2011-04-26 0:01 UTC (permalink / raw) To: Steven A. Falco; +Cc: linuxppc-dev On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote: > I'm getting an error message when trying to talk to some custom > hardware: > > dx83xx 0001:43:00.0: device not available because of BAR 0 > [0xa1000000-0xa1ffffff] collisions > > I see in setup-res.c that this message comes out when there is no > parent for > a device resource. .../... It mostly happens in arch/powerpc/kernel/pci-common.c and the generic setup-res.c Try #define DEBUG at the top (before the #includes) of pci-common.c and pci_32.c (remove the exiting #undef in the last one) and send us the full dmesg log, along with the output of cat /proc/iomem Cheers, Ben. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: device not available because of BAR 0 collisions 2011-04-26 0:01 ` Benjamin Herrenschmidt @ 2011-04-26 13:38 ` Steven A. Falco 2011-04-26 23:39 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 11+ messages in thread From: Steven A. Falco @ 2011-04-26 13:38 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote: > On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote: >> I'm getting an error message when trying to talk to some custom >> hardware: >> >> dx83xx 0001:43:00.0: device not available because of BAR 0 >> [0xa1000000-0xa1ffffff] collisions >> >> I see in setup-res.c that this message comes out when there is no >> parent for >> a device resource. > > .../... > > It mostly happens in arch/powerpc/kernel/pci-common.c and the generic > setup-res.c > > Try #define DEBUG at the top (before the #includes) of pci-common.c and > pci_32.c (remove the exiting #undef in the last one) and send us the > full dmesg log, along with the output of cat /proc/iomem > > Cheers, > Ben. > > > Thanks for the help! PCIe 0 has an FPGA connected - it is behaving as expected. PCIe 1 has the PLX PCIe switch followed by a pair of ASICs - they are the ones generating the error. Here is /proc/iomem: 90000000-9fffffff : /plb/pciex@0c0000000 90000000-93ffffff : PCI Bus 0001:41 90000000-93ffffff : PCI Bus 0001:42 90000000-91ffffff : PCI Bus 0001:43 92000000-93ffffff : PCI Bus 0001:44 94000000-940fffff : PCI Bus 0001:41 94000000-9401ffff : 0001:41:00.0 e0000000-e7ffffff : /plb/pciex@0a0000000 e0000000-e5ffffff : PCI Bus 0000:01 e0000000-e3ffffff : 0000:01:00.0 e4000000-e40fffff : 0000:01:00.0 e4100000-e41fffff : 0000:01:00.0 ef600200-ef600207 : serial ef600300-ef600307 : serial ef600600-ef600606 : spi_ppc4xx_of ef6c0000-ef6cffff : dwc_otg.0 ef6c0000-ef6cffff : dwc_otg fc000000-ffffffff : fc000000.nor_flash And here is dmesg, captured after the failed modprobe, so you can see those error messages (DEBUG enabled in pci-common.c and pci_32.c): Using Flex-AM machine description Linux version 2.6.30.3-00063-g0af2edc-dirty (sfalco@hw1.cs.myharris.net) (gcc version 4.2.2) #35 Tue Apr 26 09:20:23 EDT 2011 Found initrd at 0xcfba0000:0xcfea1872 Found legacy serial port 0 for /plb/opb/serial@ef600200 mem=ef600200, taddr=ef600200, irq=0, clk=33333333, speed=0 Found legacy serial port 1 for /plb/opb/serial@ef600300 mem=ef600300, taddr=ef600300, irq=0, clk=33333333, speed=0 Top of RAM: 0x10000000, Total RAM: 0x10000000 Memory hole size: 0MB Zone PFN ranges: DMA 0x00000000 -> 0x00010000 Normal 0x00010000 -> 0x00010000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00010000 On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c0406bdc, node_mem_map c0443000 DMA zone: 512 pages used for memmap DMA zone: 0 pages reserved DMA zone: 65024 pages, LIFO batch:15 MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/sda2 rw ip=137.237.178.150:137.237.178.9:137.237.178.1:255.255.255.0:flx-am:eth0:off panic=1 console=ttyS1,115200 debug NR_IRQS:512 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 irq: irq 30 on host /interrupt-controller mapped to virtual irq 30 UIC2 (32 IRQ sources) at DCR 0xe0 irq: irq 28 on host /interrupt-controller mapped to virtual irq 28 PID hash table entries: 1024 (order: 10, 4096 bytes) time_init: decrementer frequency = 400.000000 MHz time_init: processor frequency = 400.000000 MHz clocksource: timebase mult[a00000] shift[22] registered clockevent: decrementer mult[6666] shift[16] cpu[0] I-pipe 2.7-02: pipeline enabled. Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 252092k/262144k available (3944k kernel code, 9744k reserved, 184k data, 204k bss, 164k init) Kernel virtual memory layout: * 0xffffe000..0xfffff000 : fixmap * 0xfde00000..0xfe000000 : consistent mem * 0xfde00000..0xfde00000 : early ioremap * 0xd1000000..0xfde00000 : vmalloc & ioremap SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 798.72 BogoMIPS (lpj=1597440) Mount-cache hash table entries: 512 net_namespace: 520 bytes NET: Registered protocol family 16 PCIE0: Checking link... PCIE0: Device detected, waiting for link... PCIE0: link is up ! PCI host bridge /plb/pciex@0a0000000 (primary) ranges: MEM 0x00000000e0000000..0x00000000e7ffffff -> 0x0000000080000000 IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000 4xx PCI DMA offset set to 0x00000000 PCIE0: successfully set as root-complex PCIE1: Checking link... PCIE1: Device detected, waiting for link... PCIE1: link is up ! PCI host bridge /plb/pciex@0c0000000 (primary) ranges: MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000080000000 IO 0x00000000e8010000..0x00000000e801ffff -> 0x0000000000000000 4xx PCI DMA offset set to 0x00000000 PCIE1: successfully set as root-complex PCI: Probing PCI hardware PCI: Scanning PHB /plb/pciex@0a0000000 PCI: PHB IO resource = 00000000fffe0000-00000000fffeffff [100] PCI: PHB MEM resource 0 = 00000000e0000000-00000000e7ffffff [200] PCI: PHB MEM offset = 0000000060000000 PCI: PHB IO offset = fffe0000 pci 0000:00:00.0: reg 10 32bit mmio: [0x000000-0x7fffffff] PCI:0000:00:00.0 Resource 0 0000000000000000-000000007fffffff [21208] is unassigned PCI: Hiding 4xx host bridge resources 0000:00:00.0 PCI: Fixup bus devices 0 (PHB) pci_busdev_to_OF_node(0,0x0) parent is /plb/pciex@0a0000000 result is <NULL> PCI: Try to map irq for 0000:00:00.0... pci_busdev_to_OF_node(0,0x0) parent is /plb/pciex@0a0000000 result is <NULL> pci 0000:01:00.0: reg 10 32bit mmio: [0x80000000-0x800fffff] pci 0000:01:00.0: reg 14 32bit mmio: [0x80100000-0x801fffff] pci 0000:01:00.0: reg 18 32bit mmio: [0x84000000-0x87ffffff] PCI:0000:01:00.0 Resource 0 0000000080000000-00000000800fffff [20200] fixup... PCI:0000:01:00.0 00000000e0000000-00000000e00fffff PCI:0000:01:00.0 Resource 1 0000000080100000-00000000801fffff [20200] fixup... PCI:0000:01:00.0 00000000e0100000-00000000e01fffff PCI:0000:01:00.0 Resource 2 0000000084000000-0000000087ffffff [20200] fixup... PCI:0000:01:00.0 00000000e4000000-00000000e7ffffff pci 0000:00:00.0: bridge io port: [0x00-0xfff] pci 0000:00:00.0: bridge 32bit mmio: [0x80000000-0x87ffffff] PCI:0000:00:00.0 Bus rsrc 0 0000000000000000-0000000000000fff [101] fixup... PCI:0000:00:00.0 00000000fffe0000-00000000fffe0fff PCI:0000:00:00.0 Bus rsrc 1 0000000080000000-0000000087ffffff [200] fixup... PCI:0000:00:00.0 00000000e0000000-00000000e7ffffff PCI: Fixup bus devices 1 (0000:00:00.0) pci_busdev_to_OF_node(1,0x0) PCI: Try to map irq for 0000:01:00.0... pci_busdev_to_OF_node(1,0x0) pci_busdev_to_OF_node(0,0x0) parent is /plb/pciex@0a0000000 result is <NULL> Got one, spec 2 cells (0x00000000 0x00000004...) on /interrupt-controller2 irq: irq 0 on host /interrupt-controller2 mapped to virtual irq 16 Mapped to linux irq 16 PCI: Scanning PHB /plb/pciex@0c0000000 PCI: PHB IO resource = 0000000000000000-000000000000ffff [100] PCI: PHB MEM resource 0 = 0000000090000000-000000009fffffff [200] PCI: PHB MEM offset = 0000000010000000 PCI: PHB IO offset = 00000000 pci 0001:40:00.0: reg 10 32bit mmio: [0x000000-0x7fffffff] PCI:0001:40:00.0 Resource 0 0000000000000000-000000007fffffff [21208] is unassigned PCI: Hiding 4xx host bridge resources 0001:40:00.0 PCI: Fixup bus devices 64 (PHB) pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is <NULL> PCI: Try to map irq for 0001:40:00.0... pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is <NULL> pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] PCI:0001:41:00.0 Resource 0 0000000090000000-000000009001ffff [20200] fixup... PCI:0001:41:00.0 00000000a0000000-00000000a001ffff pci 0001:41:00.0: PME# supported from D0 D3hot D3cold pci 0001:41:00.0: PME# disabled pci 0001:40:00.0: bridge io port: [0x00-0xfff] pci 0001:40:00.0: bridge 32bit mmio: [0x90000000-0x94ffffff] PCI:0001:40:00.0 Bus rsrc 0 0000000000000000-0000000000000fff [101] fixup... PCI:0001:40:00.0 0000000000000000-0000000000000fff PCI:0001:40:00.0 Bus rsrc 1 0000000090000000-0000000094ffffff [200] fixup... PCI:0001:40:00.0 00000000a0000000-00000000a4ffffff PCI: Fixup bus devices 65 (0001:40:00.0) pci_busdev_to_OF_node(65,0x0) PCI: Try to map irq for 0001:41:00.0... pci_busdev_to_OF_node(65,0x0) pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is <NULL> Got one, spec 2 cells (0x0000000b 0x00000004...) on /interrupt-controller2 irq: irq 11 on host /interrupt-controller2 mapped to virtual irq 17 Mapped to linux irq 17 pci 0001:42:01.0: PME# supported from D0 D3hot D3cold pci 0001:42:01.0: PME# disabled pci 0001:42:02.0: PME# supported from D0 D3hot D3cold pci 0001:42:02.0: PME# disabled pci 0001:41:00.0: bridge 32bit mmio: [0x90100000-0x94ffffff] PCI:0001:41:00.0 Bus rsrc 1 0000000090100000-0000000094ffffff [200] fixup... PCI:0001:41:00.0 00000000a0100000-00000000a4ffffff PCI: Fixup bus devices 66 (0001:41:00.0) pci_busdev_to_OF_node(66,0x8) PCI: Try to map irq for 0001:42:01.0... pci_busdev_to_OF_node(66,0x8) pci_busdev_to_OF_node(65,0x0) pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is <NULL> Got one, spec 2 cells (0x0000000c 0x00000004...) on /interrupt-controller2 irq: irq 12 on host /interrupt-controller2 mapped to virtual irq 18 Mapped to linux irq 18 pci_busdev_to_OF_node(66,0x10) PCI: Try to map irq for 0001:42:02.0... pci_busdev_to_OF_node(66,0x10) pci_busdev_to_OF_node(65,0x0) pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is <NULL> Got one, spec 2 cells (0x0000000d 0x00000004...) on /interrupt-controller2 irq: irq 13 on host /interrupt-controller2 mapped to virtual irq 19 Mapped to linux irq 19 pci 0001:43:00.0: reg 10 32bit mmio: [0x91000000-0x91ffffff] pci 0001:43:00.0: reg 14 32bit mmio: [0x92000000-0x92ffffff] PCI:0001:43:00.0 Resource 0 0000000091000000-0000000091ffffff [21208] fixup... PCI:0001:43:00.0 00000000a1000000-00000000a1ffffff PCI:0001:43:00.0 Resource 1 0000000092000000-0000000092ffffff [21208] fixup... PCI:0001:43:00.0 00000000a2000000-00000000a2ffffff pci 0001:42:01.0: bridge 32bit mmio: [0x90100000-0x92ffffff] PCI:0001:42:01.0 Bus rsrc 1 0000000090100000-0000000092ffffff [200] fixup... PCI:0001:42:01.0 00000000a0100000-00000000a2ffffff PCI: Fixup bus devices 67 (0001:42:01.0) pci_busdev_to_OF_node(67,0x0) PCI: Try to map irq for 0001:43:00.0... pci_busdev_to_OF_node(67,0x0) pci_busdev_to_OF_node(66,0x8) pci_busdev_to_OF_node(65,0x0) pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is <NULL> Got one, spec 2 cells (0x0000000c 0x00000004...) on /interrupt-controller2 Mapped to linux irq 18 pci 0001:44:00.0: reg 10 32bit mmio: [0x93000000-0x93ffffff] pci 0001:44:00.0: reg 14 32bit mmio: [0x94000000-0x94ffffff] PCI:0001:44:00.0 Resource 0 0000000093000000-0000000093ffffff [21208] fixup... PCI:0001:44:00.0 00000000a3000000-00000000a3ffffff PCI:0001:44:00.0 Resource 1 0000000094000000-0000000094ffffff [21208] fixup... PCI:0001:44:00.0 00000000a4000000-00000000a4ffffff pci 0001:42:02.0: bridge 32bit mmio: [0x93000000-0x94ffffff] PCI:0001:42:02.0 Bus rsrc 1 0000000093000000-0000000094ffffff [200] fixup... PCI:0001:42:02.0 00000000a3000000-00000000a4ffffff PCI: Fixup bus devices 68 (0001:42:02.0) pci_busdev_to_OF_node(68,0x0) PCI: Try to map irq for 0001:44:00.0... pci_busdev_to_OF_node(68,0x0) pci_busdev_to_OF_node(66,0x10) pci_busdev_to_OF_node(65,0x0) pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is <NULL> Got one, spec 2 cells (0x0000000d 0x00000004...) on /interrupt-controller2 Mapped to linux irq 19 PCI: Allocating bus resources for 0000:00... PCI: PHB (bus 0) bridge rsrc 0: 00000000fffe0000-00000000fffeffff [0x100], parent c03de440 (PCI IO) PCI: PHB (bus 0) bridge rsrc 1: 00000000e0000000-00000000e7ffffff [0x200], parent c03de424 (PCI mem) PCI: Allocating bus resources for 0000:01... PCI: Allocating bus resources for 0001:40... PCI: PHB (bus 64) bridge rsrc 0: 0000000000000000-000000000000ffff [0x100], parent c03de440 (PCI IO) PCI: PHB (bus 64) bridge rsrc 1: 0000000090000000-000000009fffffff [0x200], parent c03de424 (PCI mem) PCI: Allocating bus resources for 0001:41... PCI: Allocating bus resources for 0001:42... PCI: Allocating bus resources for 0001:43... PCI: Allocating bus resources for 0001:44... Reserving legacy ranges for domain 0000 Candidate legacy IO: [0xfffe0000-0xfffe0fff] hose mem offset: 0000000060000000 hose mem res: [0xe0000000-0xe7ffffff] Reserving legacy ranges for domain 0001 Candidate legacy IO: [0x00-0xfff] hose mem offset: 0000000010000000 hose mem res: [0x90000000-0x9fffffff] PCI: Assigning unassigned resources... pci 0000:00:00.0: PCI bridge, secondary bus 0000:01 pci 0000:00:00.0: IO window: disabled pci 0000:00:00.0: MEM window: 0x80000000-0x85ffffff pci 0000:00:00.0: PREFETCH window: disabled pci 0001:42:01.0: PCI bridge, secondary bus 0001:43 pci 0001:42:01.0: IO window: disabled pci 0001:42:01.0: MEM window: disabled pci 0001:42:01.0: PREFETCH window: 0x00000080000000-0x00000081ffffff pci 0001:42:02.0: PCI bridge, secondary bus 0001:44 pci 0001:42:02.0: IO window: disabled pci 0001:42:02.0: MEM window: disabled pci 0001:42:02.0: PREFETCH window: 0x00000082000000-0x00000083ffffff pci 0001:41:00.0: PCI bridge, secondary bus 0001:42 pci 0001:41:00.0: IO window: disabled pci 0001:41:00.0: MEM window: disabled pci 0001:41:00.0: PREFETCH window: 0x00000080000000-0x00000083ffffff pci 0001:40:00.0: PCI bridge, secondary bus 0001:41 pci 0001:40:00.0: IO window: disabled pci 0001:40:00.0: MEM window: 0x84000000-0x840fffff pci 0001:40:00.0: PREFETCH window: 0x00000080000000-0x00000083ffffff pci_bus 0000:00: resource 0 io: [0xfffe0000-0xfffeffff] pci_bus 0000:00: resource 1 mem: [0xe0000000-0xe7ffffff] pci_bus 0000:01: resource 0 mem: [0xfffe0000-0xfffe0fff] pci_bus 0000:01: resource 1 mem: [0xe0000000-0xe5ffffff] pci_bus 0001:40: resource 0 io: [0x00-0xffff] pci_bus 0001:40: resource 1 mem: [0x90000000-0x9fffffff] pci_bus 0001:41: resource 0 mem: [0x0-0xfff] pci_bus 0001:41: resource 1 mem: [0x94000000-0x940fffff] pci_bus 0001:41: resource 2 pref mem [0x90000000-0x93ffffff] pci_bus 0001:42: resource 1 mem: [0xa0100000-0xa4ffffff] pci_bus 0001:42: resource 2 pref mem [0x90000000-0x93ffffff] pci_bus 0001:43: resource 1 mem: [0xa0100000-0xa2ffffff] pci_bus 0001:43: resource 2 pref mem [0x90000000-0x91ffffff] pci_bus 0001:44: resource 1 mem: [0xa3000000-0xa4ffffff] pci_bus 0001:44: resource 2 pref mem [0x92000000-0x93ffffff] bio: create slab <bio-0> at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Switched to high resolution mode on CPU 0 NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered NET: Registered protocol family 1 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 3078k freed irq: irq 26 on host /interrupt-controller mapped to virtual irq 26 irq: irq 1 on host /interrupt-controller mapped to virtual irq 20 irq: irq 30 on host /interrupt-controller2 mapped to virtual irq 21 irq: irq 26 on host /interrupt-controller1 mapped to virtual irq 22 irq: irq 12 on host /interrupt-controller mapped to virtual irq 23 I-pipe: Domain Xenomai registered. Xenomai: hal/powerpc started. Xenomai: real-time nucleus v2.4.10 (Flavor Crystal 7) loaded. Xenomai: starting native API services. Xenomai: starting POSIX services. Xenomai: starting RTDM services. Installing knfsd (copyright (C) 1996 okir@monad.swb.de). fuse init (API version 7.11) msgmni has been set to 498 alg: No test for stdrng (krng) io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered aer 0001:41:00.0:pcie12: service driver aer loaded aer 0001:42:01.0:pcie22: service driver aer loaded aer 0001:42:02.0:pcie22: service driver aer loaded pci_hotplug: PCI Hot Plug PCI Core version: 0.5 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0xef600200 (irq = 26) is a 16550A serial8250.0: ttyS1 at MMIO 0xef600300 (irq = 20) is a 16550A console [ttyS1] enabled ef600200.serial: ttyS0 at MMIO 0xef600200 (irq = 26) is a 16550A ef600300.serial: ttyS1 at MMIO 0xef600300 (irq = 20) is a 16550A brd: module loaded Driver 'sd' needs updating - please use bus_type methods PPC 4xx OCP EMAC driver, version 3.54 irq: irq 10 on host /interrupt-controller mapped to virtual irq 24 irq: irq 11 on host /interrupt-controller mapped to virtual irq 25 irq: irq 0 on host /interrupt-controller1 mapped to virtual irq 27 irq: irq 1 on host /interrupt-controller1 mapped to virtual irq 29 irq: irq 2 on host /interrupt-controller1 mapped to virtual irq 31 MAL v2 /plb/mcmal, 2 TX channels, 2 RX channels RGMII /plb/opb/emac-rgmii@ef600b00 initialized with MDIO support irq: irq 24 on host /interrupt-controller mapped to virtual irq 32 irq: irq 29 on host /interrupt-controller1 mapped to virtual irq 33 /plb/opb/emac-rgmii@ef600b00: input 0 in RGMII mode eth0: EMAC-0 /plb/opb/ethernet@ef600900, MAC 00:90:f9:10:1a:08 eth0: found Marvell 88E1111 Ethernet PHY (0x04) irq: irq 25 on host /interrupt-controller mapped to virtual irq 34 irq: irq 31 on host /interrupt-controller1 mapped to virtual irq 35 /plb/opb/emac-rgmii@ef600b00: input 1 in RGMII mode eth1: EMAC-1 /plb/opb/ethernet@ef600a00, MAC 00:90:f9:10:1a:09 eth1: found Marvell 88E1111 Ethernet PHY (0x05) fc000000.nor_flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled erase region 0: offset=0x0,size=0x8000,blocks=4 erase region 1: offset=0x20000,size=0x20000,blocks=511 RedBoot partition parsing not available Creating 7 MTD partitions on "fc000000.nor_flash": 0x000000000000-0x000000800000 : "kernel0" 0x000000800000-0x000001000000 : "kernel1" 0x000001000000-0x000001800000 : "kernel2" 0x000001800000-0x000003f40000 : "install" 0x000003f40000-0x000003f60000 : "env0" 0x000003f60000-0x000003f80000 : "env1" 0x000003f80000-0x000004000000 : "u-boot" irq: irq 8 on host /interrupt-controller mapped to virtual irq 36 spi_ppc4xx_of ef600600.spi: driver initialized Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. dwc_otg: version 2.60a 22-NOV-2006 dwc_otg: Shared Tx FIFO mode dwc_otg: Using DMA mode dwc_otg dwc_otg.0: DWC OTG Controller dwc_otg dwc_otg.0: new USB bus registered, assigned bus number 1 dwc_otg dwc_otg.0: irq 21, io mem 0x00000000 dwc_otg: Init: Port Power? op_state=1 dwc_otg: Init: Power Port (0) usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: DWC OTG Controller usb usb1: Manufacturer: Linux 2.6.30.3-00063-g0af2edc-dirty dwc_otg_hcd usb usb1: SerialNumber: dwc_otg.0 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected i2c /dev entries driver irq: irq 2 on host /interrupt-controller mapped to virtual irq 37 ibm-iic ef600400.i2c: using standard (100 kHz) mode irq: irq 7 on host /interrupt-controller mapped to virtual irq 38 ibm-iic ef600500.i2c: using standard (100 kHz) mode lm75: probe of 0-0048 failed with error -121 hwmon-vid: Unknown VRM version of your CPU PowerPC Book-E Watchdog Timer Loaded TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 NET: Registered protocol family 15 RPC: Registered udp transport module. RPC: Registered tcp transport module. 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com> All bugs added by David S. Miller <davem@redhat.com> usb 1-1: new high speed USB device using dwc_otg and address 2 usb 1-1: New USB device found, idVendor=0634, idProduct=0655 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: Real SSD eUSB 2GB usb 1-1: Manufacturer: Micron Technology usb 1-1: SerialNumber: 4BF0022700035321 usb 1-1: configuration #1 chosen from 1 choice scsi0 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning eth0: link is down eth0: link is up, 100 HDX IP-Config: Complete: device=eth0, addr=137.237.178.150, mask=255.255.255.0, gw=137.237.178.1, host=flx-am, domain=, nis-domain=(none), bootserver=137.237.178.9, rootserver=137.237.178.9, rootpath= Freeing unused kernel memory: 164k init at24 0-0050: 512 byte 24c04 EEPROM (writable) at24 0-0052: 512 byte 24c04 EEPROM (writable) scsi 0:0:0:0: Direct-Access MICRON eUSB DISK 1110 PQ: 0 ANSI: 0 CCS sd 0:0:0:0: Attached scsi generic sg0 type 0 usb-storage: device scan complete sd 0:0:0:0: [sda] 3964928 512-byte hardware sectors: (2.03 GB/1.89 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] Attached SCSI disk kjournald starting. Commit interval 5 seconds EXT3 FS on sda2, internal journal EXT3-fs: mounted filesystem with journal data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sda1, internal journal EXT3-fs: mounted filesystem with journal data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sda3, internal journal EXT3-fs: mounted filesystem with journal data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sda4, internal journal EXT3-fs: mounted filesystem with journal data mode. at24 0-0050: 512 byte 24c04 EEPROM (writable) at24 0-0052: 512 byte 24c04 EEPROM (writable) dx83xx 0001:43:00.0: device not available because of BAR 0 [0xa1000000-0xa1ffffff] collisions dx83xx: probe of 0001:43:00.0 failed with error -22 dx83xx 0001:44:00.0: device not available because of BAR 0 [0xa3000000-0xa3ffffff] collisions dx83xx: probe of 0001:44:00.0 failed with error -22 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: device not available because of BAR 0 collisions 2011-04-26 13:38 ` Steven A. Falco @ 2011-04-26 23:39 ` Benjamin Herrenschmidt 2011-04-27 14:22 ` Steven A. Falco 2011-04-27 19:51 ` Steven A. Falco 0 siblings, 2 replies; 11+ messages in thread From: Benjamin Herrenschmidt @ 2011-04-26 23:39 UTC (permalink / raw) To: Steven A. Falco; +Cc: linuxppc-dev On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote: > On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote: > > On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote: > >> I'm getting an error message when trying to talk to some custom > >> hardware: > >> > >> dx83xx 0001:43:00.0: device not available because of BAR 0 > >> [0xa1000000-0xa1ffffff] collisions > >> > >> I see in setup-res.c that this message comes out when there is no > >> parent for > >> a device resource. > > > > .../... > > > > It mostly happens in arch/powerpc/kernel/pci-common.c and the generic > > setup-res.c > > > > Try #define DEBUG at the top (before the #includes) of pci-common.c and > > pci_32.c (remove the exiting #undef in the last one) and send us the > > full dmesg log, along with the output of cat /proc/iomem Have you set any specific flags ? IE. Modified the value of ppc_pci_flags from what the 4xx code sets originally ? It does look to me like some of your device BARs have been setup already by the firmware in a way that conflict with the way you configure your ranges, and the kernel doesn't appear to detect nor try to remap that which would happen if you have the "probe only" flag set. IE. On your c0000000 bus, you have memory at 90000000 CPU space mapped to 80000000 PCI space. However, when probing, the kernel finds: pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] IE. A BAR was already set with a value of 90000000 PCI-side which is out of the bounds you have for your bus. Maybe you really want to configure that second bus to have CPU 90000000 mapped to 90000000 PCI-side ? (IE. a 1:1 mapping). That would be something to fix in your "ranges" property. Cheers, Ben. > > Cheers, > > Ben. > > > > > > > > Thanks for the help! > > PCIe 0 has an FPGA connected - it is behaving as expected. PCIe 1 has the > PLX PCIe switch followed by a pair of ASICs - they are the ones generating > the error. > > Here is /proc/iomem: > > 90000000-9fffffff : /plb/pciex@0c0000000 > 90000000-93ffffff : PCI Bus 0001:41 > 90000000-93ffffff : PCI Bus 0001:42 > 90000000-91ffffff : PCI Bus 0001:43 > 92000000-93ffffff : PCI Bus 0001:44 > 94000000-940fffff : PCI Bus 0001:41 > 94000000-9401ffff : 0001:41:00.0 > e0000000-e7ffffff : /plb/pciex@0a0000000 > e0000000-e5ffffff : PCI Bus 0000:01 > e0000000-e3ffffff : 0000:01:00.0 > e4000000-e40fffff : 0000:01:00.0 > e4100000-e41fffff : 0000:01:00.0 > ef600200-ef600207 : serial > ef600300-ef600307 : serial > ef600600-ef600606 : spi_ppc4xx_of > ef6c0000-ef6cffff : dwc_otg.0 > ef6c0000-ef6cffff : dwc_otg > fc000000-ffffffff : fc000000.nor_flash > > And here is dmesg, captured after the failed modprobe, so you can see > those error messages (DEBUG enabled in pci-common.c and pci_32.c): > > Using Flex-AM machine description > Linux version 2.6.30.3-00063-g0af2edc-dirty (sfalco@hw1.cs.myharris.net) (gcc version 4.2.2) #35 Tue Apr 26 09:20:23 EDT 2011 > Found initrd at 0xcfba0000:0xcfea1872 > Found legacy serial port 0 for /plb/opb/serial@ef600200 > mem=ef600200, taddr=ef600200, irq=0, clk=33333333, speed=0 > Found legacy serial port 1 for /plb/opb/serial@ef600300 > mem=ef600300, taddr=ef600300, irq=0, clk=33333333, speed=0 > Top of RAM: 0x10000000, Total RAM: 0x10000000 > Memory hole size: 0MB > Zone PFN ranges: > DMA 0x00000000 -> 0x00010000 > Normal 0x00010000 -> 0x00010000 > Movable zone start PFN for each node > early_node_map[1] active PFN ranges > 0: 0x00000000 -> 0x00010000 > On node 0 totalpages: 65536 > free_area_init_node: node 0, pgdat c0406bdc, node_mem_map c0443000 > DMA zone: 512 pages used for memmap > DMA zone: 0 pages reserved > DMA zone: 65024 pages, LIFO batch:15 > MMU: Allocated 1088 bytes of context maps for 255 contexts > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 > Kernel command line: root=/dev/sda2 rw ip=137.237.178.150:137.237.178.9:137.237.178.1:255.255.255.0:flx-am:eth0:off panic=1 console=ttyS1,115200 debug > NR_IRQS:512 > UIC0 (32 IRQ sources) at DCR 0xc0 > UIC1 (32 IRQ sources) at DCR 0xd0 > irq: irq 30 on host /interrupt-controller mapped to virtual irq 30 > UIC2 (32 IRQ sources) at DCR 0xe0 > irq: irq 28 on host /interrupt-controller mapped to virtual irq 28 > PID hash table entries: 1024 (order: 10, 4096 bytes) > time_init: decrementer frequency = 400.000000 MHz > time_init: processor frequency = 400.000000 MHz > clocksource: timebase mult[a00000] shift[22] registered > clockevent: decrementer mult[6666] shift[16] cpu[0] > I-pipe 2.7-02: pipeline enabled. > Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) > Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) > Memory: 252092k/262144k available (3944k kernel code, 9744k reserved, 184k data, 204k bss, 164k init) > Kernel virtual memory layout: > * 0xffffe000..0xfffff000 : fixmap > * 0xfde00000..0xfe000000 : consistent mem > * 0xfde00000..0xfde00000 : early ioremap > * 0xd1000000..0xfde00000 : vmalloc & ioremap > SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > Calibrating delay loop... 798.72 BogoMIPS (lpj=1597440) > Mount-cache hash table entries: 512 > net_namespace: 520 bytes > NET: Registered protocol family 16 > PCIE0: Checking link... > PCIE0: Device detected, waiting for link... > PCIE0: link is up ! > PCI host bridge /plb/pciex@0a0000000 (primary) ranges: > MEM 0x00000000e0000000..0x00000000e7ffffff -> 0x0000000080000000 > IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000 > 4xx PCI DMA offset set to 0x00000000 > PCIE0: successfully set as root-complex > PCIE1: Checking link... > PCIE1: Device detected, waiting for link... > PCIE1: link is up ! > PCI host bridge /plb/pciex@0c0000000 (primary) ranges: > MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000080000000 > IO 0x00000000e8010000..0x00000000e801ffff -> 0x0000000000000000 > 4xx PCI DMA offset set to 0x00000000 > PCIE1: successfully set as root-complex > PCI: Probing PCI hardware > PCI: Scanning PHB /plb/pciex@0a0000000 > PCI: PHB IO resource = 00000000fffe0000-00000000fffeffff [100] > PCI: PHB MEM resource 0 = 00000000e0000000-00000000e7ffffff [200] > PCI: PHB MEM offset = 0000000060000000 > PCI: PHB IO offset = fffe0000 > pci 0000:00:00.0: reg 10 32bit mmio: [0x000000-0x7fffffff] > PCI:0000:00:00.0 Resource 0 0000000000000000-000000007fffffff [21208] is unassigned > PCI: Hiding 4xx host bridge resources 0000:00:00.0 > PCI: Fixup bus devices 0 (PHB) > pci_busdev_to_OF_node(0,0x0) > parent is /plb/pciex@0a0000000 > result is <NULL> > PCI: Try to map irq for 0000:00:00.0... > pci_busdev_to_OF_node(0,0x0) > parent is /plb/pciex@0a0000000 > result is <NULL> > pci 0000:01:00.0: reg 10 32bit mmio: [0x80000000-0x800fffff] > pci 0000:01:00.0: reg 14 32bit mmio: [0x80100000-0x801fffff] > pci 0000:01:00.0: reg 18 32bit mmio: [0x84000000-0x87ffffff] > PCI:0000:01:00.0 Resource 0 0000000080000000-00000000800fffff [20200] fixup... > PCI:0000:01:00.0 00000000e0000000-00000000e00fffff > PCI:0000:01:00.0 Resource 1 0000000080100000-00000000801fffff [20200] fixup... > PCI:0000:01:00.0 00000000e0100000-00000000e01fffff > PCI:0000:01:00.0 Resource 2 0000000084000000-0000000087ffffff [20200] fixup... > PCI:0000:01:00.0 00000000e4000000-00000000e7ffffff > pci 0000:00:00.0: bridge io port: [0x00-0xfff] > pci 0000:00:00.0: bridge 32bit mmio: [0x80000000-0x87ffffff] > PCI:0000:00:00.0 Bus rsrc 0 0000000000000000-0000000000000fff [101] fixup... > PCI:0000:00:00.0 00000000fffe0000-00000000fffe0fff > PCI:0000:00:00.0 Bus rsrc 1 0000000080000000-0000000087ffffff [200] fixup... > PCI:0000:00:00.0 00000000e0000000-00000000e7ffffff > PCI: Fixup bus devices 1 (0000:00:00.0) > pci_busdev_to_OF_node(1,0x0) > PCI: Try to map irq for 0000:01:00.0... > pci_busdev_to_OF_node(1,0x0) > pci_busdev_to_OF_node(0,0x0) > parent is /plb/pciex@0a0000000 > result is <NULL> > Got one, spec 2 cells (0x00000000 0x00000004...) on /interrupt-controller2 > irq: irq 0 on host /interrupt-controller2 mapped to virtual irq 16 > Mapped to linux irq 16 > PCI: Scanning PHB /plb/pciex@0c0000000 > PCI: PHB IO resource = 0000000000000000-000000000000ffff [100] > PCI: PHB MEM resource 0 = 0000000090000000-000000009fffffff [200] > PCI: PHB MEM offset = 0000000010000000 > PCI: PHB IO offset = 00000000 > pci 0001:40:00.0: reg 10 32bit mmio: [0x000000-0x7fffffff] > PCI:0001:40:00.0 Resource 0 0000000000000000-000000007fffffff [21208] is unassigned > PCI: Hiding 4xx host bridge resources 0001:40:00.0 > PCI: Fixup bus devices 64 (PHB) > pci_busdev_to_OF_node(64,0x0) > parent is /plb/pciex@0c0000000 > result is <NULL> > PCI: Try to map irq for 0001:40:00.0... > pci_busdev_to_OF_node(64,0x0) > parent is /plb/pciex@0c0000000 > result is <NULL> > pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] > PCI:0001:41:00.0 Resource 0 0000000090000000-000000009001ffff [20200] fixup... > PCI:0001:41:00.0 00000000a0000000-00000000a001ffff > pci 0001:41:00.0: PME# supported from D0 D3hot D3cold > pci 0001:41:00.0: PME# disabled > pci 0001:40:00.0: bridge io port: [0x00-0xfff] > pci 0001:40:00.0: bridge 32bit mmio: [0x90000000-0x94ffffff] > PCI:0001:40:00.0 Bus rsrc 0 0000000000000000-0000000000000fff [101] fixup... > PCI:0001:40:00.0 0000000000000000-0000000000000fff > PCI:0001:40:00.0 Bus rsrc 1 0000000090000000-0000000094ffffff [200] fixup... > PCI:0001:40:00.0 00000000a0000000-00000000a4ffffff > PCI: Fixup bus devices 65 (0001:40:00.0) > pci_busdev_to_OF_node(65,0x0) > PCI: Try to map irq for 0001:41:00.0... > pci_busdev_to_OF_node(65,0x0) > pci_busdev_to_OF_node(64,0x0) > parent is /plb/pciex@0c0000000 > result is <NULL> > Got one, spec 2 cells (0x0000000b 0x00000004...) on /interrupt-controller2 > irq: irq 11 on host /interrupt-controller2 mapped to virtual irq 17 > Mapped to linux irq 17 > pci 0001:42:01.0: PME# supported from D0 D3hot D3cold > pci 0001:42:01.0: PME# disabled > pci 0001:42:02.0: PME# supported from D0 D3hot D3cold > pci 0001:42:02.0: PME# disabled > pci 0001:41:00.0: bridge 32bit mmio: [0x90100000-0x94ffffff] > PCI:0001:41:00.0 Bus rsrc 1 0000000090100000-0000000094ffffff [200] fixup... > PCI:0001:41:00.0 00000000a0100000-00000000a4ffffff > PCI: Fixup bus devices 66 (0001:41:00.0) > pci_busdev_to_OF_node(66,0x8) > PCI: Try to map irq for 0001:42:01.0... > pci_busdev_to_OF_node(66,0x8) > pci_busdev_to_OF_node(65,0x0) > pci_busdev_to_OF_node(64,0x0) > parent is /plb/pciex@0c0000000 > result is <NULL> > Got one, spec 2 cells (0x0000000c 0x00000004...) on /interrupt-controller2 > irq: irq 12 on host /interrupt-controller2 mapped to virtual irq 18 > Mapped to linux irq 18 > pci_busdev_to_OF_node(66,0x10) > PCI: Try to map irq for 0001:42:02.0... > pci_busdev_to_OF_node(66,0x10) > pci_busdev_to_OF_node(65,0x0) > pci_busdev_to_OF_node(64,0x0) > parent is /plb/pciex@0c0000000 > result is <NULL> > Got one, spec 2 cells (0x0000000d 0x00000004...) on /interrupt-controller2 > irq: irq 13 on host /interrupt-controller2 mapped to virtual irq 19 > Mapped to linux irq 19 > pci 0001:43:00.0: reg 10 32bit mmio: [0x91000000-0x91ffffff] > pci 0001:43:00.0: reg 14 32bit mmio: [0x92000000-0x92ffffff] > PCI:0001:43:00.0 Resource 0 0000000091000000-0000000091ffffff [21208] fixup... > PCI:0001:43:00.0 00000000a1000000-00000000a1ffffff > PCI:0001:43:00.0 Resource 1 0000000092000000-0000000092ffffff [21208] fixup... > PCI:0001:43:00.0 00000000a2000000-00000000a2ffffff > pci 0001:42:01.0: bridge 32bit mmio: [0x90100000-0x92ffffff] > PCI:0001:42:01.0 Bus rsrc 1 0000000090100000-0000000092ffffff [200] fixup... > PCI:0001:42:01.0 00000000a0100000-00000000a2ffffff > PCI: Fixup bus devices 67 (0001:42:01.0) > pci_busdev_to_OF_node(67,0x0) > PCI: Try to map irq for 0001:43:00.0... > pci_busdev_to_OF_node(67,0x0) > pci_busdev_to_OF_node(66,0x8) > pci_busdev_to_OF_node(65,0x0) > pci_busdev_to_OF_node(64,0x0) > parent is /plb/pciex@0c0000000 > result is <NULL> > Got one, spec 2 cells (0x0000000c 0x00000004...) on /interrupt-controller2 > Mapped to linux irq 18 > pci 0001:44:00.0: reg 10 32bit mmio: [0x93000000-0x93ffffff] > pci 0001:44:00.0: reg 14 32bit mmio: [0x94000000-0x94ffffff] > PCI:0001:44:00.0 Resource 0 0000000093000000-0000000093ffffff [21208] fixup... > PCI:0001:44:00.0 00000000a3000000-00000000a3ffffff > PCI:0001:44:00.0 Resource 1 0000000094000000-0000000094ffffff [21208] fixup... > PCI:0001:44:00.0 00000000a4000000-00000000a4ffffff > pci 0001:42:02.0: bridge 32bit mmio: [0x93000000-0x94ffffff] > PCI:0001:42:02.0 Bus rsrc 1 0000000093000000-0000000094ffffff [200] fixup... > PCI:0001:42:02.0 00000000a3000000-00000000a4ffffff > PCI: Fixup bus devices 68 (0001:42:02.0) > pci_busdev_to_OF_node(68,0x0) > PCI: Try to map irq for 0001:44:00.0... > pci_busdev_to_OF_node(68,0x0) > pci_busdev_to_OF_node(66,0x10) > pci_busdev_to_OF_node(65,0x0) > pci_busdev_to_OF_node(64,0x0) > parent is /plb/pciex@0c0000000 > result is <NULL> > Got one, spec 2 cells (0x0000000d 0x00000004...) on /interrupt-controller2 > Mapped to linux irq 19 > PCI: Allocating bus resources for 0000:00... > PCI: PHB (bus 0) bridge rsrc 0: 00000000fffe0000-00000000fffeffff [0x100], parent c03de440 (PCI IO) > PCI: PHB (bus 0) bridge rsrc 1: 00000000e0000000-00000000e7ffffff [0x200], parent c03de424 (PCI mem) > PCI: Allocating bus resources for 0000:01... > PCI: Allocating bus resources for 0001:40... > PCI: PHB (bus 64) bridge rsrc 0: 0000000000000000-000000000000ffff [0x100], parent c03de440 (PCI IO) > PCI: PHB (bus 64) bridge rsrc 1: 0000000090000000-000000009fffffff [0x200], parent c03de424 (PCI mem) > PCI: Allocating bus resources for 0001:41... > PCI: Allocating bus resources for 0001:42... > PCI: Allocating bus resources for 0001:43... > PCI: Allocating bus resources for 0001:44... > Reserving legacy ranges for domain 0000 > Candidate legacy IO: [0xfffe0000-0xfffe0fff] > hose mem offset: 0000000060000000 > hose mem res: [0xe0000000-0xe7ffffff] > Reserving legacy ranges for domain 0001 > Candidate legacy IO: [0x00-0xfff] > hose mem offset: 0000000010000000 > hose mem res: [0x90000000-0x9fffffff] > PCI: Assigning unassigned resources... > pci 0000:00:00.0: PCI bridge, secondary bus 0000:01 > pci 0000:00:00.0: IO window: disabled > pci 0000:00:00.0: MEM window: 0x80000000-0x85ffffff > pci 0000:00:00.0: PREFETCH window: disabled > pci 0001:42:01.0: PCI bridge, secondary bus 0001:43 > pci 0001:42:01.0: IO window: disabled > pci 0001:42:01.0: MEM window: disabled > pci 0001:42:01.0: PREFETCH window: 0x00000080000000-0x00000081ffffff > pci 0001:42:02.0: PCI bridge, secondary bus 0001:44 > pci 0001:42:02.0: IO window: disabled > pci 0001:42:02.0: MEM window: disabled > pci 0001:42:02.0: PREFETCH window: 0x00000082000000-0x00000083ffffff > pci 0001:41:00.0: PCI bridge, secondary bus 0001:42 > pci 0001:41:00.0: IO window: disabled > pci 0001:41:00.0: MEM window: disabled > pci 0001:41:00.0: PREFETCH window: 0x00000080000000-0x00000083ffffff > pci 0001:40:00.0: PCI bridge, secondary bus 0001:41 > pci 0001:40:00.0: IO window: disabled > pci 0001:40:00.0: MEM window: 0x84000000-0x840fffff > pci 0001:40:00.0: PREFETCH window: 0x00000080000000-0x00000083ffffff > pci_bus 0000:00: resource 0 io: [0xfffe0000-0xfffeffff] > pci_bus 0000:00: resource 1 mem: [0xe0000000-0xe7ffffff] > pci_bus 0000:01: resource 0 mem: [0xfffe0000-0xfffe0fff] > pci_bus 0000:01: resource 1 mem: [0xe0000000-0xe5ffffff] > pci_bus 0001:40: resource 0 io: [0x00-0xffff] > pci_bus 0001:40: resource 1 mem: [0x90000000-0x9fffffff] > pci_bus 0001:41: resource 0 mem: [0x0-0xfff] > pci_bus 0001:41: resource 1 mem: [0x94000000-0x940fffff] > pci_bus 0001:41: resource 2 pref mem [0x90000000-0x93ffffff] > pci_bus 0001:42: resource 1 mem: [0xa0100000-0xa4ffffff] > pci_bus 0001:42: resource 2 pref mem [0x90000000-0x93ffffff] > pci_bus 0001:43: resource 1 mem: [0xa0100000-0xa2ffffff] > pci_bus 0001:43: resource 2 pref mem [0x90000000-0x91ffffff] > pci_bus 0001:44: resource 1 mem: [0xa3000000-0xa4ffffff] > pci_bus 0001:44: resource 2 pref mem [0x92000000-0x93ffffff] > bio: create slab <bio-0> at 0 > SCSI subsystem initialized > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > Switched to high resolution mode on CPU 0 > NET: Registered protocol family 2 > IP route cache hash table entries: 2048 (order: 1, 8192 bytes) > TCP established hash table entries: 8192 (order: 4, 65536 bytes) > TCP bind hash table entries: 8192 (order: 3, 32768 bytes) > TCP: Hash tables configured (established 8192 bind 8192) > TCP reno registered > NET: Registered protocol family 1 > Trying to unpack rootfs image as initramfs... > Freeing initrd memory: 3078k freed > irq: irq 26 on host /interrupt-controller mapped to virtual irq 26 > irq: irq 1 on host /interrupt-controller mapped to virtual irq 20 > irq: irq 30 on host /interrupt-controller2 mapped to virtual irq 21 > irq: irq 26 on host /interrupt-controller1 mapped to virtual irq 22 > irq: irq 12 on host /interrupt-controller mapped to virtual irq 23 > I-pipe: Domain Xenomai registered. > Xenomai: hal/powerpc started. > Xenomai: real-time nucleus v2.4.10 (Flavor Crystal 7) loaded. > Xenomai: starting native API services. > Xenomai: starting POSIX services. > Xenomai: starting RTDM services. > Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > fuse init (API version 7.11) > msgmni has been set to 498 > alg: No test for stdrng (krng) > io scheduler noop registered > io scheduler anticipatory registered (default) > io scheduler deadline registered > io scheduler cfq registered > aer 0001:41:00.0:pcie12: service driver aer loaded > aer 0001:42:01.0:pcie22: service driver aer loaded > aer 0001:42:02.0:pcie22: service driver aer loaded > pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > serial8250.0: ttyS0 at MMIO 0xef600200 (irq = 26) is a 16550A > serial8250.0: ttyS1 at MMIO 0xef600300 (irq = 20) is a 16550A > console [ttyS1] enabled > ef600200.serial: ttyS0 at MMIO 0xef600200 (irq = 26) is a 16550A > ef600300.serial: ttyS1 at MMIO 0xef600300 (irq = 20) is a 16550A > brd: module loaded > Driver 'sd' needs updating - please use bus_type methods > PPC 4xx OCP EMAC driver, version 3.54 > irq: irq 10 on host /interrupt-controller mapped to virtual irq 24 > irq: irq 11 on host /interrupt-controller mapped to virtual irq 25 > irq: irq 0 on host /interrupt-controller1 mapped to virtual irq 27 > irq: irq 1 on host /interrupt-controller1 mapped to virtual irq 29 > irq: irq 2 on host /interrupt-controller1 mapped to virtual irq 31 > MAL v2 /plb/mcmal, 2 TX channels, 2 RX channels > RGMII /plb/opb/emac-rgmii@ef600b00 initialized with MDIO support > irq: irq 24 on host /interrupt-controller mapped to virtual irq 32 > irq: irq 29 on host /interrupt-controller1 mapped to virtual irq 33 > /plb/opb/emac-rgmii@ef600b00: input 0 in RGMII mode > eth0: EMAC-0 /plb/opb/ethernet@ef600900, MAC 00:90:f9:10:1a:08 > eth0: found Marvell 88E1111 Ethernet PHY (0x04) > irq: irq 25 on host /interrupt-controller mapped to virtual irq 34 > irq: irq 31 on host /interrupt-controller1 mapped to virtual irq 35 > /plb/opb/emac-rgmii@ef600b00: input 1 in RGMII mode > eth1: EMAC-1 /plb/opb/ethernet@ef600a00, MAC 00:90:f9:10:1a:09 > eth1: found Marvell 88E1111 Ethernet PHY (0x05) > fc000000.nor_flash: Found 1 x16 devices at 0x0 in 16-bit bank > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Using buffer write method > Using auto-unlock on power-up/resume > cfi_cmdset_0001: Erase suspend on write enabled > erase region 0: offset=0x0,size=0x8000,blocks=4 > erase region 1: offset=0x20000,size=0x20000,blocks=511 > RedBoot partition parsing not available > Creating 7 MTD partitions on "fc000000.nor_flash": > 0x000000000000-0x000000800000 : "kernel0" > 0x000000800000-0x000001000000 : "kernel1" > 0x000001000000-0x000001800000 : "kernel2" > 0x000001800000-0x000003f40000 : "install" > 0x000003f40000-0x000003f60000 : "env0" > 0x000003f60000-0x000003f80000 : "env1" > 0x000003f80000-0x000004000000 : "u-boot" > irq: irq 8 on host /interrupt-controller mapped to virtual irq 36 > spi_ppc4xx_of ef600600.spi: driver initialized > Initializing USB Mass Storage driver... > usbcore: registered new interface driver usb-storage > USB Mass Storage support registered. > dwc_otg: version 2.60a 22-NOV-2006 > dwc_otg: Shared Tx FIFO mode > dwc_otg: Using DMA mode > dwc_otg dwc_otg.0: DWC OTG Controller > dwc_otg dwc_otg.0: new USB bus registered, assigned bus number 1 > dwc_otg dwc_otg.0: irq 21, io mem 0x00000000 > dwc_otg: Init: Port Power? op_state=1 > dwc_otg: Init: Power Port (0) > usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: DWC OTG Controller > usb usb1: Manufacturer: Linux 2.6.30.3-00063-g0af2edc-dirty dwc_otg_hcd > usb usb1: SerialNumber: dwc_otg.0 > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 1 port detected > i2c /dev entries driver > irq: irq 2 on host /interrupt-controller mapped to virtual irq 37 > ibm-iic ef600400.i2c: using standard (100 kHz) mode > irq: irq 7 on host /interrupt-controller mapped to virtual irq 38 > ibm-iic ef600500.i2c: using standard (100 kHz) mode > lm75: probe of 0-0048 failed with error -121 > hwmon-vid: Unknown VRM version of your CPU > PowerPC Book-E Watchdog Timer Loaded > TCP cubic registered > Initializing XFRM netlink socket > NET: Registered protocol family 17 > NET: Registered protocol family 15 > RPC: Registered udp transport module. > RPC: Registered tcp transport module. > 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com> > All bugs added by David S. Miller <davem@redhat.com> > usb 1-1: new high speed USB device using dwc_otg and address 2 > usb 1-1: New USB device found, idVendor=0634, idProduct=0655 > usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 1-1: Product: Real SSD eUSB 2GB > usb 1-1: Manufacturer: Micron Technology > usb 1-1: SerialNumber: 4BF0022700035321 > usb 1-1: configuration #1 chosen from 1 choice > scsi0 : SCSI emulation for USB Mass Storage devices > usb-storage: device found at 2 > usb-storage: waiting for device to settle before scanning > eth0: link is down > eth0: link is up, 100 HDX > IP-Config: Complete: > device=eth0, addr=137.237.178.150, mask=255.255.255.0, gw=137.237.178.1, > host=flx-am, domain=, nis-domain=(none), > bootserver=137.237.178.9, rootserver=137.237.178.9, rootpath= > Freeing unused kernel memory: 164k init > at24 0-0050: 512 byte 24c04 EEPROM (writable) > at24 0-0052: 512 byte 24c04 EEPROM (writable) > scsi 0:0:0:0: Direct-Access MICRON eUSB DISK 1110 PQ: 0 ANSI: 0 CCS > sd 0:0:0:0: Attached scsi generic sg0 type 0 > usb-storage: device scan complete > sd 0:0:0:0: [sda] 3964928 512-byte hardware sectors: (2.03 GB/1.89 GiB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 > sd 0:0:0:0: [sda] Assuming drive cache: write through > sd 0:0:0:0: [sda] Assuming drive cache: write through > sda: sda1 sda2 sda3 sda4 > sd 0:0:0:0: [sda] Attached SCSI disk > kjournald starting. Commit interval 5 seconds > EXT3 FS on sda2, internal journal > EXT3-fs: mounted filesystem with journal data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on sda1, internal journal > EXT3-fs: mounted filesystem with journal data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on sda3, internal journal > EXT3-fs: mounted filesystem with journal data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on sda4, internal journal > EXT3-fs: mounted filesystem with journal data mode. > at24 0-0050: 512 byte 24c04 EEPROM (writable) > at24 0-0052: 512 byte 24c04 EEPROM (writable) > dx83xx 0001:43:00.0: device not available because of BAR 0 [0xa1000000-0xa1ffffff] collisions > dx83xx: probe of 0001:43:00.0 failed with error -22 > dx83xx 0001:44:00.0: device not available because of BAR 0 [0xa3000000-0xa3ffffff] collisions > dx83xx: probe of 0001:44:00.0 failed with error -22 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: device not available because of BAR 0 collisions 2011-04-26 23:39 ` Benjamin Herrenschmidt @ 2011-04-27 14:22 ` Steven A. Falco 2011-04-27 19:51 ` Steven A. Falco 1 sibling, 0 replies; 11+ messages in thread From: Steven A. Falco @ 2011-04-27 14:22 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote: > On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote: >> On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote: >>> On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote: >>>> I'm getting an error message when trying to talk to some custom >>>> hardware: >>>> >>>> dx83xx 0001:43:00.0: device not available because of BAR 0 >>>> [0xa1000000-0xa1ffffff] collisions >>>> >>>> I see in setup-res.c that this message comes out when there is no >>>> parent for >>>> a device resource. >>> >>> .../... >>> >>> It mostly happens in arch/powerpc/kernel/pci-common.c and the generic >>> setup-res.c >>> >>> Try #define DEBUG at the top (before the #includes) of pci-common.c and >>> pci_32.c (remove the exiting #undef in the last one) and send us the >>> full dmesg log, along with the output of cat /proc/iomem > > Have you set any specific flags ? IE. Modified the value of > ppc_pci_flags from what the 4xx code sets originally ? The only flag that is set is the same as what is in Kilauea: ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC); > It does look to me like some of your device BARs have been setup already > by the firmware in a way that conflict with the way you configure your > ranges, and the kernel doesn't appear to detect nor try to remap that > which would happen if you have the "probe only" flag set. That is possible. The PLX PCIe switch chip does use some memory for its own purposes - namely to expose the PCIe config space in memory. I believe that is where the extra 128 k bytes are coming from. Do I need to represent the PCIe switch in the device tree? If so, is there an example of what it might look like? I took a stab at it, shown below. I believe you are correct - that PLX switch's own memory appears to be confusing the allocation process. Perhaps the allocation code does not expect bridges/switches to require memory of their own. > IE. On your c0000000 bus, you have memory at 90000000 CPU space mapped > to 80000000 PCI space. However, when probing, the kernel finds: > > pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] > > IE. A BAR was already set with a value of 90000000 PCI-side which is out > of the bounds you have for your bus. > > Maybe you really want to configure that second bus to have CPU 90000000 > mapped to 90000000 PCI-side ? (IE. a 1:1 mapping). That would be > something to fix in your "ranges" property. I've taken a shot at representing the PCIe switch in the device tree, and I've gone to a 1:1 mapping. Here is what the device tree now has: PCIE1: pciex@0c0000000 { device_type = "pci"; #interrupt-cells = <1>; #size-cells = <2>; #address-cells = <3>; compatible = "ibm,plb-pciex-405ex", "ibm,plb-pciex"; primary; port = <0x1>; /* port number */ reg = <0xc0000000 0x20000000 /* Config space access */ 0xef001000 0x00001000>; /* Registers */ dcr-reg = <0x060 0x020>; sdr-base = <0x440>; ranges = <0x02000000 0x00000000 0x90000000 0x90000000 0x00000000 0x10000000 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x80000000>; bus-range = <0x40 0x7f>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; interrupt-map = < 0x0 0x0 0x0 0x1 &UIC2 0xb 0x4 /* swizzled int A */ 0x0 0x0 0x0 0x2 &UIC2 0xc 0x4 /* swizzled int B */ 0x0 0x0 0x0 0x3 &UIC2 0xd 0x4 /* swizzled int C */ 0x0 0x0 0x0 0x4 &UIC2 0xe 0x4 /* swizzled int D */>; /* PLX PCIe switch - no idea if this is correct / necessary yet */ pcie@0 { #size-cells = <2>; #address-cells = <3>; device_type = "pci"; reg = <0 0 0 0 0>; ranges = <0x02000000 0x00000000 0x90000000 0x02000000 0x00000000 0x90000000 0x00000000 0x10000000 0x01000000 0x00000000 0x00000000 0x01000000 0x00000000 0x00000000 0x00000000 0x00010000>; }; }; /proc/iomem is unchanged. It looks a bit strange. I see space reserved for bus 0001:43 and 0001:44, but I don't see the actual device BARs. I.e. I'd expect to see four extra lines: 90000000-90ffffff : 0001:43.00.0 // ASIC 0 BAR 0 91000000-91ffffff : 0001:43.00.0 // ASIC 0 BAR 1 92000000-92ffffff : 0001:44.00.0 // ASIC 1 BAR 0 93000000-93ffffff : 0001:44.00.0 // ASIC 1 BAR 1 Here is what I do see. Notice that the above lines are missing: 90000000-9fffffff : /plb/pciex@0c0000000 90000000-93ffffff : PCI Bus 0001:41 90000000-93ffffff : PCI Bus 0001:42 90000000-91ffffff : PCI Bus 0001:43 // Bus is shown but no device connected 92000000-93ffffff : PCI Bus 0001:44 // Bus is shown but no device connected 94000000-940fffff : PCI Bus 0001:41 94000000-9401ffff : 0001:41:00.0 // PLX PCIe switch BAR 0 - 128 kB e0000000-e7ffffff : /plb/pciex@0a0000000 e0000000-e5ffffff : PCI Bus 0000:01 e0000000-e3ffffff : 0000:01:00.0 e4000000-e40fffff : 0000:01:00.0 e4100000-e41fffff : 0000:01:00.0 ef600200-ef600207 : serial ef600300-ef600307 : serial ef600600-ef600606 : spi_ppc4xx_of ef6c0000-ef6cffff : dwc_otg.0 ef6c0000-ef6cffff : dwc_otg fc000000-ffffffff : fc000000.nor_flash Here is a new dmesg log. What you will see is that the various fixups now produce CPU addresses identical to the bus addresses. But the "order" is messed up. In the /proc/iomem above, the PCIe switch resources show up as 94000000-9401ffff : 0001:41:00.0, but in the log below, you will see PCI:0001:41:00.0 Resource 0 0000000090000000-000000009001ffff So somehow it moved. And that in turn moves the ASICs also. /proc/iomem has: 90000000-91ffffff : PCI Bus 0001:43 92000000-93ffffff : PCI Bus 0001:44 but the log below has: pci 0001:43:00.0: reg 10 32bit mmio: [0x91000000-0x91ffffff] pci 0001:43:00.0: reg 14 32bit mmio: [0x92000000-0x92ffffff] pci 0001:44:00.0: reg 10 32bit mmio: [0x93000000-0x93ffffff] pci 0001:44:00.0: reg 14 32bit mmio: [0x94000000-0x94ffffff] Since this is embedded hardware, I have no objection to completely specifying things in the dts. My problem is that I have not found any examples of how I would do this. And my attempts to come up with the right magic on my own have so far not worked. :-) Steve Using Flex-AM machine description Linux version 2.6.30.3-00063-g0af2edc-dirty (sfalco@hw1.cs.myharris.net) (gcc version 4.2.2) #49 Wed Apr 27 09:32:09 EDT 2011 Found legacy serial port 0 for /plb/opb/serial@ef600200 mem=ef600200, taddr=ef600200, irq=0, clk=33333333, speed=0 Found legacy serial port 1 for /plb/opb/serial@ef600300 mem=ef600300, taddr=ef600300, irq=0, clk=33333333, speed=0 Top of RAM: 0x10000000, Total RAM: 0x10000000 Memory hole size: 0MB Zone PFN ranges: DMA 0x00000000 -> 0x00010000 Normal 0x00010000 -> 0x00010000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00010000 On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c0406bdc, node_mem_map c053b000 DMA zone: 512 pages used for memmap DMA zone: 0 pages reserved DMA zone: 65024 pages, LIFO batch:15 MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/nfs rw nfsroot=/sandbox/hydra/sfalco/flx-codec/rootfs ip=137.237.178.150:137.237.179.21:137.237.178.1:255.255.255.0:flx-am:eth0:off console=ttyS1,115200 debug NR_IRQS:512 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 irq: irq 30 on host /interrupt-controller mapped to virtual irq 30 UIC2 (32 IRQ sources) at DCR 0xe0 irq: irq 28 on host /interrupt-controller mapped to virtual irq 28 PID hash table entries: 1024 (order: 10, 4096 bytes) time_init: decrementer frequency = 400.000000 MHz time_init: processor frequency = 400.000000 MHz clocksource: timebase mult[a00000] shift[22] registered clockevent: decrementer mult[6666] shift[16] cpu[0] I-pipe 2.7-02: pipeline enabled. Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 254208k/262144k available (3944k kernel code, 7656k reserved, 184k data, 1196k bss, 164k init) Kernel virtual memory layout: * 0xffffe000..0xfffff000 : fixmap * 0xfde00000..0xfe000000 : consistent mem * 0xfde00000..0xfde00000 : early ioremap * 0xd1000000..0xfde00000 : vmalloc & ioremap SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 798.72 BogoMIPS (lpj=1597440) Mount-cache hash table entries: 512 net_namespace: 520 bytes NET: Registered protocol family 16 PCIE0: Checking link... PCIE0: Device detected, waiting for link... PCIE0: link is up ! PCI host bridge /plb/pciex@0a0000000 (primary) ranges: MEM 0x00000000e0000000..0x00000000e7ffffff -> 0x00000000e0000000 IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000 4xx PCI DMA offset set to 0x00000000 PCIE0: successfully set as root-complex PCIE1: Checking link... PCIE1: Device detected, waiting for link... PCIE1: link is up ! PCI host bridge /plb/pciex@0c0000000 (primary) ranges: MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000 IO 0x00000000e8010000..0x00000000e801ffff -> 0x0000000000000000 4xx PCI DMA offset set to 0x00000000 PCIE1: successfully set as root-complex PCI: Probing PCI hardware PCI: Scanning PHB /plb/pciex@0a0000000 PCI: PHB IO resource = 00000000fffe0000-00000000fffeffff [100] PCI: PHB MEM resource 0 = 00000000e0000000-00000000e7ffffff [200] PCI: PHB MEM offset = 0000000000000000 PCI: PHB IO offset = fffe0000 pci 0000:00:00.0: reg 10 32bit mmio: [0x000000-0x7fffffff] PCI:0000:00:00.0 Resource 0 0000000000000000-000000007fffffff [21208] is unassigned PCI: Hiding 4xx host bridge resources 0000:00:00.0 PCI: Fixup bus devices 0 (PHB) pci_busdev_to_OF_node(0,0x0) parent is /plb/pciex@0a0000000 result is <NULL> PCI: Try to map irq for 0000:00:00.0... pci_busdev_to_OF_node(0,0x0) parent is /plb/pciex@0a0000000 result is <NULL> pci 0000:01:00.0: reg 10 32bit mmio: [0x80000000-0x800fffff] pci 0000:01:00.0: reg 14 32bit mmio: [0x80100000-0x801fffff] pci 0000:01:00.0: reg 18 32bit mmio: [0x84000000-0x87ffffff] PCI:0000:01:00.0 Resource 0 0000000080000000-00000000800fffff [20200] fixup... PCI:0000:01:00.0 0000000080000000-00000000800fffff PCI:0000:01:00.0 Resource 1 0000000080100000-00000000801fffff [20200] fixup... PCI:0000:01:00.0 0000000080100000-00000000801fffff PCI:0000:01:00.0 Resource 2 0000000084000000-0000000087ffffff [20200] fixup... PCI:0000:01:00.0 0000000084000000-0000000087ffffff pci 0000:00:00.0: bridge io port: [0x00-0xfff] pci 0000:00:00.0: bridge 32bit mmio: [0x80000000-0x87ffffff] PCI:0000:00:00.0 Bus rsrc 0 0000000000000000-0000000000000fff [101] fixup... PCI:0000:00:00.0 00000000fffe0000-00000000fffe0fff PCI:0000:00:00.0 Bus rsrc 1 0000000080000000-0000000087ffffff [200] fixup... PCI:0000:00:00.0 0000000080000000-0000000087ffffff PCI: Fixup bus devices 1 (0000:00:00.0) pci_busdev_to_OF_node(1,0x0) PCI: Try to map irq for 0000:01:00.0... pci_busdev_to_OF_node(1,0x0) pci_busdev_to_OF_node(0,0x0) parent is /plb/pciex@0a0000000 result is <NULL> Got one, spec 2 cells (0x00000000 0x00000004...) on /interrupt-controller2 irq: irq 0 on host /interrupt-controller2 mapped to virtual irq 16 Mapped to linux irq 16 PCI: Scanning PHB /plb/pciex@0c0000000 PCI: PHB IO resource = 0000000000000000-000000000000ffff [100] PCI: PHB MEM resource 0 = 0000000090000000-000000009fffffff [200] PCI: PHB MEM offset = 0000000000000000 PCI: PHB IO offset = 00000000 pci 0001:40:00.0: reg 10 32bit mmio: [0x000000-0x7fffffff] PCI:0001:40:00.0 Resource 0 0000000000000000-000000007fffffff [21208] is unassigned PCI: Hiding 4xx host bridge resources 0001:40:00.0 PCI: Fixup bus devices 64 (PHB) pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is /plb/pciex@0c0000000/pcie@0 PCI: Try to map irq for 0001:40:00.0... pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is /plb/pciex@0c0000000/pcie@0 pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] PCI:0001:41:00.0 Resource 0 0000000090000000-000000009001ffff [20200] fixup... PCI:0001:41:00.0 0000000090000000-000000009001ffff pci 0001:41:00.0: PME# supported from D0 D3hot D3cold pci 0001:41:00.0: PME# disabled pci 0001:40:00.0: bridge io port: [0x00-0xfff] pci 0001:40:00.0: bridge 32bit mmio: [0x90000000-0x94ffffff] PCI:0001:40:00.0 Bus rsrc 0 0000000000000000-0000000000000fff [101] fixup... PCI:0001:40:00.0 0000000000000000-0000000000000fff PCI:0001:40:00.0 Bus rsrc 1 0000000090000000-0000000094ffffff [200] fixup... PCI:0001:40:00.0 0000000090000000-0000000094ffffff PCI: Fixup bus devices 65 (0001:40:00.0) pci_busdev_to_OF_node(65,0x0) parent is /plb/pciex@0c0000000/pcie@0 result is <NULL> PCI: Try to map irq for 0001:41:00.0... pci_busdev_to_OF_node(65,0x0) parent is /plb/pciex@0c0000000/pcie@0 result is <NULL> pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is /plb/pciex@0c0000000/pcie@0 Got one, spec 2 cells (0x0000000b 0x00000004...) on /interrupt-controller2 irq: irq 11 on host /interrupt-controller2 mapped to virtual irq 17 Mapped to linux irq 17 pci 0001:42:01.0: PME# supported from D0 D3hot D3cold pci 0001:42:01.0: PME# disabled pci 0001:42:02.0: PME# supported from D0 D3hot D3cold pci 0001:42:02.0: PME# disabled pci 0001:41:00.0: bridge 32bit mmio: [0x90100000-0x94ffffff] PCI:0001:41:00.0 Bus rsrc 1 0000000090100000-0000000094ffffff [200] fixup... PCI:0001:41:00.0 0000000090100000-0000000094ffffff PCI: Fixup bus devices 66 (0001:41:00.0) pci_busdev_to_OF_node(66,0x8) PCI: Try to map irq for 0001:42:01.0... pci_busdev_to_OF_node(66,0x8) pci_busdev_to_OF_node(65,0x0) parent is /plb/pciex@0c0000000/pcie@0 result is <NULL> pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is /plb/pciex@0c0000000/pcie@0 Got one, spec 2 cells (0x0000000c 0x00000004...) on /interrupt-controller2 irq: irq 12 on host /interrupt-controller2 mapped to virtual irq 18 Mapped to linux irq 18 pci_busdev_to_OF_node(66,0x10) PCI: Try to map irq for 0001:42:02.0... pci_busdev_to_OF_node(66,0x10) pci_busdev_to_OF_node(65,0x0) parent is /plb/pciex@0c0000000/pcie@0 result is <NULL> pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is /plb/pciex@0c0000000/pcie@0 Got one, spec 2 cells (0x0000000d 0x00000004...) on /interrupt-controller2 irq: irq 13 on host /interrupt-controller2 mapped to virtual irq 19 Mapped to linux irq 19 pci 0001:43:00.0: reg 10 32bit mmio: [0x91000000-0x91ffffff] pci 0001:43:00.0: reg 14 32bit mmio: [0x92000000-0x92ffffff] PCI:0001:43:00.0 Resource 0 0000000091000000-0000000091ffffff [21208] fixup... PCI:0001:43:00.0 0000000091000000-0000000091ffffff PCI:0001:43:00.0 Resource 1 0000000092000000-0000000092ffffff [21208] fixup... PCI:0001:43:00.0 0000000092000000-0000000092ffffff pci 0001:42:01.0: bridge 32bit mmio: [0x90100000-0x92ffffff] PCI:0001:42:01.0 Bus rsrc 1 0000000090100000-0000000092ffffff [200] fixup... PCI:0001:42:01.0 0000000090100000-0000000092ffffff PCI: Fixup bus devices 67 (0001:42:01.0) pci_busdev_to_OF_node(67,0x0) PCI: Try to map irq for 0001:43:00.0... pci_busdev_to_OF_node(67,0x0) pci_busdev_to_OF_node(66,0x8) pci_busdev_to_OF_node(65,0x0) parent is /plb/pciex@0c0000000/pcie@0 result is <NULL> pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is /plb/pciex@0c0000000/pcie@0 Got one, spec 2 cells (0x0000000c 0x00000004...) on /interrupt-controller2 Mapped to linux irq 18 pci 0001:44:00.0: reg 10 32bit mmio: [0x93000000-0x93ffffff] pci 0001:44:00.0: reg 14 32bit mmio: [0x94000000-0x94ffffff] PCI:0001:44:00.0 Resource 0 0000000093000000-0000000093ffffff [21208] fixup... PCI:0001:44:00.0 0000000093000000-0000000093ffffff PCI:0001:44:00.0 Resource 1 0000000094000000-0000000094ffffff [21208] fixup... PCI:0001:44:00.0 0000000094000000-0000000094ffffff pci 0001:42:02.0: bridge 32bit mmio: [0x93000000-0x94ffffff] PCI:0001:42:02.0 Bus rsrc 1 0000000093000000-0000000094ffffff [200] fixup... PCI:0001:42:02.0 0000000093000000-0000000094ffffff PCI: Fixup bus devices 68 (0001:42:02.0) pci_busdev_to_OF_node(68,0x0) PCI: Try to map irq for 0001:44:00.0... pci_busdev_to_OF_node(68,0x0) pci_busdev_to_OF_node(66,0x10) pci_busdev_to_OF_node(65,0x0) parent is /plb/pciex@0c0000000/pcie@0 result is <NULL> pci_busdev_to_OF_node(64,0x0) parent is /plb/pciex@0c0000000 result is /plb/pciex@0c0000000/pcie@0 Got one, spec 2 cells (0x0000000d 0x00000004...) on /interrupt-controller2 Mapped to linux irq 19 PCI: Allocating bus resources for 0000:00... PCI: PHB (bus 0) bridge rsrc 0: 00000000fffe0000-00000000fffeffff [0x100], parent c03de440 (PCI IO) PCI: PHB (bus 0) bridge rsrc 1: 00000000e0000000-00000000e7ffffff [0x200], parent c03de424 (PCI mem) PCI: Allocating bus resources for 0000:01... PCI: Allocating bus resources for 0001:40... PCI: PHB (bus 64) bridge rsrc 0: 0000000000000000-000000000000ffff [0x100], parent c03de440 (PCI IO) PCI: PHB (bus 64) bridge rsrc 1: 0000000090000000-000000009fffffff [0x200], parent c03de424 (PCI mem) PCI: Allocating bus resources for 0001:41... PCI: Allocating bus resources for 0001:42... PCI: Allocating bus resources for 0001:43... PCI: Allocating bus resources for 0001:44... Reserving legacy ranges for domain 0000 Candidate legacy IO: [0xfffe0000-0xfffe0fff] hose mem offset: 0000000000000000 hose mem res: [0xe0000000-0xe7ffffff] Reserving legacy ranges for domain 0001 Candidate legacy IO: [0x00-0xfff] hose mem offset: 0000000000000000 hose mem res: [0x90000000-0x9fffffff] PCI: Assigning unassigned resources... pci 0000:00:00.0: PCI bridge, secondary bus 0000:01 pci 0000:00:00.0: IO window: disabled pci 0000:00:00.0: MEM window: 0xe0000000-0xe5ffffff pci 0000:00:00.0: PREFETCH window: disabled pci 0001:42:01.0: PCI bridge, secondary bus 0001:43 pci 0001:42:01.0: IO window: disabled pci 0001:42:01.0: MEM window: disabled pci 0001:42:01.0: PREFETCH window: 0x00000090000000-0x00000091ffffff pci 0001:42:02.0: PCI bridge, secondary bus 0001:44 pci 0001:42:02.0: IO window: disabled pci 0001:42:02.0: MEM window: disabled pci 0001:42:02.0: PREFETCH window: 0x00000092000000-0x00000093ffffff pci 0001:41:00.0: PCI bridge, secondary bus 0001:42 pci 0001:41:00.0: IO window: disabled pci 0001:41:00.0: MEM window: disabled pci 0001:41:00.0: PREFETCH window: 0x00000090000000-0x00000093ffffff pci 0001:40:00.0: PCI bridge, secondary bus 0001:41 pci 0001:40:00.0: IO window: disabled pci 0001:40:00.0: MEM window: 0x94000000-0x940fffff pci 0001:40:00.0: PREFETCH window: 0x00000090000000-0x00000093ffffff pci_bus 0000:00: resource 0 io: [0xfffe0000-0xfffeffff] pci_bus 0000:00: resource 1 mem: [0xe0000000-0xe7ffffff] pci_bus 0000:01: resource 0 mem: [0xfffe0000-0xfffe0fff] pci_bus 0000:01: resource 1 mem: [0xe0000000-0xe5ffffff] pci_bus 0001:40: resource 0 io: [0x00-0xffff] pci_bus 0001:40: resource 1 mem: [0x90000000-0x9fffffff] pci_bus 0001:41: resource 0 mem: [0x0-0xfff] pci_bus 0001:41: resource 1 mem: [0x94000000-0x940fffff] pci_bus 0001:41: resource 2 pref mem [0x90000000-0x93ffffff] pci_bus 0001:42: resource 1 mem: [0x90100000-0x94ffffff] pci_bus 0001:42: resource 2 pref mem [0x90000000-0x93ffffff] pci_bus 0001:43: resource 1 mem: [0x90100000-0x92ffffff] pci_bus 0001:43: resource 2 pref mem [0x90000000-0x91ffffff] pci_bus 0001:44: resource 1 mem: [0x93000000-0x94ffffff] pci_bus 0001:44: resource 2 pref mem [0x92000000-0x93ffffff] bio: create slab <bio-0> at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Switched to high resolution mode on CPU 0 NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered NET: Registered protocol family 1 irq: irq 26 on host /interrupt-controller mapped to virtual irq 26 irq: irq 1 on host /interrupt-controller mapped to virtual irq 20 irq: irq 30 on host /interrupt-controller2 mapped to virtual irq 21 irq: irq 26 on host /interrupt-controller1 mapped to virtual irq 22 irq: irq 12 on host /interrupt-controller mapped to virtual irq 23 I-pipe: Domain Xenomai registered. Xenomai: hal/powerpc started. Xenomai: real-time nucleus v2.4.10 (Flavor Crystal 7) loaded. Xenomai: starting native API services. Xenomai: starting POSIX services. Xenomai: starting RTDM services. Installing knfsd (copyright (C) 1996 okir@monad.swb.de). fuse init (API version 7.11) msgmni has been set to 497 alg: No test for stdrng (krng) io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered aer 0001:41:00.0:pcie12: service driver aer loaded aer 0001:42:01.0:pcie22: service driver aer loaded aer 0001:42:02.0:pcie22: service driver aer loaded pci_hotplug: PCI Hot Plug PCI Core version: 0.5 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0xef600200 (irq = 26) is a 16550A serial8250.0: ttyS1 at MMIO 0xef600300 (irq = 20) is a 16550A console [ttyS1] enabled ef600200.serial: ttyS0 at MMIO 0xef600200 (irq = 26) is a 16550A ef600300.serial: ttyS1 at MMIO 0xef600300 (irq = 20) is a 16550A brd: module loaded Driver 'sd' needs updating - please use bus_type methods PPC 4xx OCP EMAC driver, version 3.54 irq: irq 10 on host /interrupt-controller mapped to virtual irq 24 irq: irq 11 on host /interrupt-controller mapped to virtual irq 25 irq: irq 0 on host /interrupt-controller1 mapped to virtual irq 27 irq: irq 1 on host /interrupt-controller1 mapped to virtual irq 29 irq: irq 2 on host /interrupt-controller1 mapped to virtual irq 31 MAL v2 /plb/mcmal, 2 TX channels, 2 RX channels RGMII /plb/opb/emac-rgmii@ef600b00 initialized with MDIO support irq: irq 24 on host /interrupt-controller mapped to virtual irq 32 irq: irq 29 on host /interrupt-controller1 mapped to virtual irq 33 /plb/opb/emac-rgmii@ef600b00: input 0 in RGMII mode eth0: EMAC-0 /plb/opb/ethernet@ef600900, MAC 00:90:f9:10:1a:08 eth0: found Marvell 88E1111 Ethernet PHY (0x04) irq: irq 25 on host /interrupt-controller mapped to virtual irq 34 irq: irq 31 on host /interrupt-controller1 mapped to virtual irq 35 /plb/opb/emac-rgmii@ef600b00: input 1 in RGMII mode eth1: EMAC-1 /plb/opb/ethernet@ef600a00, MAC 00:90:f9:10:1a:09 eth1: found Marvell 88E1111 Ethernet PHY (0x05) fc000000.nor_flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled erase region 0: offset=0x0,size=0x8000,blocks=4 erase region 1: offset=0x20000,size=0x20000,blocks=511 RedBoot partition parsing not available Creating 7 MTD partitions on "fc000000.nor_flash": 0x000000000000-0x000000800000 : "kernel0" 0x000000800000-0x000001000000 : "kernel1" 0x000001000000-0x000001800000 : "kernel2" 0x000001800000-0x000003f40000 : "install" 0x000003f40000-0x000003f60000 : "env0" 0x000003f60000-0x000003f80000 : "env1" 0x000003f80000-0x000004000000 : "u-boot" irq: irq 8 on host /interrupt-controller mapped to virtual irq 36 spi_ppc4xx_of ef600600.spi: driver initialized Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. dwc_otg: version 2.60a 22-NOV-2006 dwc_otg: Shared Tx FIFO mode dwc_otg: Using DMA mode dwc_otg dwc_otg.0: DWC OTG Controller dwc_otg dwc_otg.0: new USB bus registered, assigned bus number 1 dwc_otg dwc_otg.0: irq 21, io mem 0x00000000 dwc_otg: Init: Port Power? op_state=1 dwc_otg: Init: Power Port (0) usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: DWC OTG Controller usb usb1: Manufacturer: Linux 2.6.30.3-00063-g0af2edc-dirty dwc_otg_hcd usb usb1: SerialNumber: dwc_otg.0 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected i2c /dev entries driver irq: irq 2 on host /interrupt-controller mapped to virtual irq 37 ibm-iic ef600400.i2c: using standard (100 kHz) mode irq: irq 7 on host /interrupt-controller mapped to virtual irq 38 ibm-iic ef600500.i2c: using standard (100 kHz) mode lm75: probe of 0-0048 failed with error -121 hwmon-vid: Unknown VRM version of your CPU PowerPC Book-E Watchdog Timer Loaded TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 NET: Registered protocol family 15 RPC: Registered udp transport module. RPC: Registered tcp transport module. 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com> All bugs added by David S. Miller <davem@redhat.com> usb 1-1: new high speed USB device using dwc_otg and address 2 usb 1-1: New USB device found, idVendor=0634, idProduct=0655 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: Real SSD eUSB 2GB usb 1-1: Manufacturer: Micron Technology usb 1-1: SerialNumber: 4BF0022700035321 usb 1-1: configuration #1 chosen from 1 choice scsi0 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning eth0: link is down eth0: link is up, 100 HDX IP-Config: Complete: device=eth0, addr=137.237.178.150, mask=255.255.255.0, gw=137.237.178.1, host=flx-am, domain=, nis-domain=(none), bootserver=137.237.179.21, rootserver=137.237.179.21, rootpath= Looking up port of RPC 100003/2 on 137.237.179.21 Looking up port of RPC 100005/1 on 137.237.179.21 VFS: Mounted root (nfs filesystem) on device 0:14. Freeing unused kernel memory: 164k init INIT: version 2.86 booting scsi 0:0:0:0: Direct-Access MICRON eUSB DISK 1110 PQ: 0 ANSI: 0 CCS sd 0:0:0:0: Attached scsi generic sg0 type 0 usb-storage: device scan complete sd 0:0:0:0: [sda] 3964928 512-byte hardware sectors: (2.03 GB/1.89 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] Attached SCSI disk Welcome to DENX Embedded Linux Environment Press 'I' to enter interactive startup. Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Setting clock : Wed Dec 31 19:00:10 EST 1969 [ OK ] Building the cache [ OK ] Setting hostname flx-am: [ OK ] Mounting local filesystems: [ OK ] Enabling /etc/fstab swaps: [ OK ] INIT: Entering runlevel: 3 Entering non-interactive startup FATAL: Module ipv6 not found. Bringing up loopback interface: [ OK ] FATAL: Module ipv6 not found. Starting system logger: [ OK ] Starting kernel logger: [ OK ] Starting rpcbind: [ OK ] Mounting NFS filesystems: [ OK ] Mounting other filesystems: [ OK ] Starting xinetd: [ OK ] DENX ELDK version 4.2 build 2008-04-01 Linux 2.6.30.3-00063-g0af2edc-dirty on a ppc flx-am login: root Password: Last login: Wed Dec 31 19:06:54 on console -bash-3.2# modprobe d7 dx83xx 0001:43:00.0: device not available because of BAR 0 [0x91000000-0x91ffffff] collisions dx83xx: probe of 0001:43:00.0 failed with error -22 dx83xx 0001:44:00.0: device not available because of BAR 0 [0x93000000-0x93ffffff] collisions dx83xx: probe of 0001:44:00.0 failed with error -22 -bash-3.2# > > Cheers, > Ben. > -- A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: device not available because of BAR 0 collisions 2011-04-26 23:39 ` Benjamin Herrenschmidt 2011-04-27 14:22 ` Steven A. Falco @ 2011-04-27 19:51 ` Steven A. Falco 2011-04-28 17:29 ` Steven A. Falco 1 sibling, 1 reply; 11+ messages in thread From: Steven A. Falco @ 2011-04-27 19:51 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote: > On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote: >> On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote: >>> On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote: >>>> I'm getting an error message when trying to talk to some custom >>>> hardware: >>>> >>>> dx83xx 0001:43:00.0: device not available because of BAR 0 >>>> [0xa1000000-0xa1ffffff] collisions >>>> >>>> I see in setup-res.c that this message comes out when there is no >>>> parent for >>>> a device resource. >>> >>> .../... >>> >>> It mostly happens in arch/powerpc/kernel/pci-common.c and the generic >>> setup-res.c >>> >>> Try #define DEBUG at the top (before the #includes) of pci-common.c and >>> pci_32.c (remove the exiting #undef in the last one) and send us the >>> full dmesg log, along with the output of cat /proc/iomem > > Have you set any specific flags ? IE. Modified the value of > ppc_pci_flags from what the 4xx code sets originally ? For fun, I just tried changing: ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC); to: ppc_pci_set_flags(PPC_PCI_PROBE_ONLY); I realize that is the exact opposite of what you were suggesting, but please bear with me for a bit. I also changed the PCIE 0 ranges from: ranges = <0x02000000 0x00000000 0x80000000 0x90000000 0x00000000 0x10000000 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; ranges = <0x02000000 0x00000000 0x90000000 0x90000000 0x00000000 0x10000000 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; I changed the ranges not because I wanted a 1:1 map, but because 90000000 is what U-Boot chooses when it scans PCIe 1. At this point, everything is working. Here is /proc/iomap: 90000000-9fffffff : /plb/pciex@0c0000000 90000000-94ffffff : PCI Bus 0001:41 90000000-9001ffff : 0001:41:00.0 90100000-94ffffff : PCI Bus 0001:42 90100000-92ffffff : PCI Bus 0001:43 91000000-91ffffff : 0001:43:00.0 //<--- was missing before 92000000-92ffffff : 0001:43:00.0 //<--- was missing before 93000000-94ffffff : PCI Bus 0001:44 93000000-93ffffff : 0001:44:00.0 //<--- was missing before 94000000-94ffffff : 0001:44:00.0 //<--- was missing before e0000000-e7ffffff : /plb/pciex@0a0000000 e0000000-e7ffffff : PCI Bus 0000:01 e0000000-e00fffff : 0000:01:00.0 e0100000-e01fffff : 0000:01:00.0 e4000000-e7ffffff : 0000:01:00.0 ef600200-ef600207 : serial ef600300-ef600307 : serial ef600600-ef600606 : spi_ppc4xx_of ef6c0000-ef6cffff : dwc_otg.0 ef6c0000-ef6cffff : dwc_otg fc000000-ffffffff : fc000000.nor_flash Now I see the bars for the ASICs (flagged above). I could stop here, and declare success, but I don't really like this solution, because it requires me to be sure the dts has the same bus addresses that U-Boot will choose. Seems risky. Tentative conclusion: Either I still have something set wrong in my dts or there is a bug in the Linux PCI bus mapping code. Steve > > It does look to me like some of your device BARs have been setup already > by the firmware in a way that conflict with the way you configure your > ranges, and the kernel doesn't appear to detect nor try to remap that > which would happen if you have the "probe only" flag set. > > IE. On your c0000000 bus, you have memory at 90000000 CPU space mapped > to 80000000 PCI space. However, when probing, the kernel finds: > > pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] > > IE. A BAR was already set with a value of 90000000 PCI-side which is out > of the bounds you have for your bus. > > Maybe you really want to configure that second bus to have CPU 90000000 > mapped to 90000000 PCI-side ? (IE. a 1:1 mapping). That would be > something to fix in your "ranges" property. > > Cheers, > Ben. -- A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: device not available because of BAR 0 collisions 2011-04-27 19:51 ` Steven A. Falco @ 2011-04-28 17:29 ` Steven A. Falco 2011-04-28 20:55 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 11+ messages in thread From: Steven A. Falco @ 2011-04-28 17:29 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev On 04/27/2011 03:51 PM, Steven A. Falco wrote: > On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote: >> On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote: >>> On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote: >>>> On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote: >>>>> I'm getting an error message when trying to talk to some custom >>>>> hardware: >>>>> >>>>> dx83xx 0001:43:00.0: device not available because of BAR 0 >>>>> [0xa1000000-0xa1ffffff] collisions I believe I've gotten to the root cause of this issue. Turns out the ASIC is reporting a class code of 0000, in violation of the PCI spec. As a result, Linux is refusing to set up the ASIC, and so it remains with the settings made in U-Boot, which are in conflict with the allocation Linux makes for the bridge the ASIC is connected to. So Ben, you are absolutely right that there was some left-over configuration. My choices appear to be: 1) Fix the ASIC (yeah, right) 2) Force Linux to use the U-Boot settings 3) Hack Linux to set up a device with a bogus class. I'm not sure why this hardware works in x86 - I guess it is less fussy. Steve >>>>> >>>>> I see in setup-res.c that this message comes out when there is no >>>>> parent for >>>>> a device resource. >>>> >>>> .../... >>>> >>>> It mostly happens in arch/powerpc/kernel/pci-common.c and the generic >>>> setup-res.c >>>> >>>> Try #define DEBUG at the top (before the #includes) of pci-common.c and >>>> pci_32.c (remove the exiting #undef in the last one) and send us the >>>> full dmesg log, along with the output of cat /proc/iomem >> >> Have you set any specific flags ? IE. Modified the value of >> ppc_pci_flags from what the 4xx code sets originally ? > > For fun, I just tried changing: > > ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC); > > to: > > ppc_pci_set_flags(PPC_PCI_PROBE_ONLY); > > I realize that is the exact opposite of what you were suggesting, but > please bear with me for a bit. > > I also changed the PCIE 0 ranges from: > > ranges = <0x02000000 0x00000000 0x80000000 0x90000000 0x00000000 0x10000000 > 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; > > ranges = <0x02000000 0x00000000 0x90000000 0x90000000 0x00000000 0x10000000 > 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; > > I changed the ranges not because I wanted a 1:1 map, but because 90000000 is > what U-Boot chooses when it scans PCIe 1. > > At this point, everything is working. Here is /proc/iomap: > > 90000000-9fffffff : /plb/pciex@0c0000000 > 90000000-94ffffff : PCI Bus 0001:41 > 90000000-9001ffff : 0001:41:00.0 > 90100000-94ffffff : PCI Bus 0001:42 > 90100000-92ffffff : PCI Bus 0001:43 > 91000000-91ffffff : 0001:43:00.0 //<--- was missing before > 92000000-92ffffff : 0001:43:00.0 //<--- was missing before > 93000000-94ffffff : PCI Bus 0001:44 > 93000000-93ffffff : 0001:44:00.0 //<--- was missing before > 94000000-94ffffff : 0001:44:00.0 //<--- was missing before > e0000000-e7ffffff : /plb/pciex@0a0000000 > e0000000-e7ffffff : PCI Bus 0000:01 > e0000000-e00fffff : 0000:01:00.0 > e0100000-e01fffff : 0000:01:00.0 > e4000000-e7ffffff : 0000:01:00.0 > ef600200-ef600207 : serial > ef600300-ef600307 : serial > ef600600-ef600606 : spi_ppc4xx_of > ef6c0000-ef6cffff : dwc_otg.0 > ef6c0000-ef6cffff : dwc_otg > fc000000-ffffffff : fc000000.nor_flash > > Now I see the bars for the ASICs (flagged above). I could stop here, > and declare success, but I don't really like this solution, because it > requires me to be sure the dts has the same bus addresses that U-Boot > will choose. Seems risky. > > Tentative conclusion: Either I still have something set wrong in my dts > or there is a bug in the Linux PCI bus mapping code. > > Steve > >> >> It does look to me like some of your device BARs have been setup already >> by the firmware in a way that conflict with the way you configure your >> ranges, and the kernel doesn't appear to detect nor try to remap that >> which would happen if you have the "probe only" flag set. >> >> IE. On your c0000000 bus, you have memory at 90000000 CPU space mapped >> to 80000000 PCI space. However, when probing, the kernel finds: >> >> pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] >> >> IE. A BAR was already set with a value of 90000000 PCI-side which is out >> of the bounds you have for your bus. >> >> Maybe you really want to configure that second bus to have CPU 90000000 >> mapped to 90000000 PCI-side ? (IE. a 1:1 mapping). That would be >> something to fix in your "ranges" property. >> >> Cheers, >> Ben. > > -- A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: device not available because of BAR 0 collisions 2011-04-28 17:29 ` Steven A. Falco @ 2011-04-28 20:55 ` Benjamin Herrenschmidt 2011-04-28 21:11 ` Steven A. Falco 0 siblings, 1 reply; 11+ messages in thread From: Benjamin Herrenschmidt @ 2011-04-28 20:55 UTC (permalink / raw) To: Steven A. Falco; +Cc: linuxppc-dev On Thu, 2011-04-28 at 13:29 -0400, Steven A. Falco wrote: > On 04/27/2011 03:51 PM, Steven A. Falco wrote: > > On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote: > >> On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote: > >>> On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote: > >>>> On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote: > >>>>> I'm getting an error message when trying to talk to some custom > >>>>> hardware: > >>>>> > >>>>> dx83xx 0001:43:00.0: device not available because of BAR 0 > >>>>> [0xa1000000-0xa1ffffff] collisions > > I believe I've gotten to the root cause of this issue. Turns out the > ASIC is reporting a class code of 0000, in violation of the PCI spec. > > As a result, Linux is refusing to set up the ASIC, and so it remains > with the settings made in U-Boot, which are in conflict with the > allocation Linux makes for the bridge the ASIC is connected to. > > So Ben, you are absolutely right that there was some left-over > configuration. Hrm. that's odd still, do you know where in linux is the code that tests for the class code and decides to not setup the device resources ? I can't see that... > My choices appear to be: > > 1) Fix the ASIC (yeah, right) > > 2) Force Linux to use the U-Boot settings > > 3) Hack Linux to set up a device with a bogus class. > > I'm not sure why this hardware works in x86 - I guess it is less > fussy. x86 probably just re-uses whatever setting the BIOS does, but I'm still a bit surprised by your class code story. I supose you can do a PCI header quirk that overrides the class code in struct pci_dev. Something like: static void __devinit quirk_your_asic_class(struct pci_dev *dev) { dev->class = foobar; } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_xxx, PCI_DEVICE_ID_yyy, quirk_your_asic_class); But I'd like to figure out where that is tested bcs I haven't found so far... > Steve > > >>>>> > >>>>> I see in setup-res.c that this message comes out when there is no > >>>>> parent for > >>>>> a device resource. > >>>> > >>>> .../... > >>>> > >>>> It mostly happens in arch/powerpc/kernel/pci-common.c and the generic > >>>> setup-res.c > >>>> > >>>> Try #define DEBUG at the top (before the #includes) of pci-common.c and > >>>> pci_32.c (remove the exiting #undef in the last one) and send us the > >>>> full dmesg log, along with the output of cat /proc/iomem > >> > >> Have you set any specific flags ? IE. Modified the value of > >> ppc_pci_flags from what the 4xx code sets originally ? > > > > For fun, I just tried changing: > > > > ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC); > > > > to: > > > > ppc_pci_set_flags(PPC_PCI_PROBE_ONLY); > > > > I realize that is the exact opposite of what you were suggesting, but > > please bear with me for a bit. > > > > I also changed the PCIE 0 ranges from: > > > > ranges = <0x02000000 0x00000000 0x80000000 0x90000000 0x00000000 0x10000000 > > 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; > > > > ranges = <0x02000000 0x00000000 0x90000000 0x90000000 0x00000000 0x10000000 > > 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; > > > > I changed the ranges not because I wanted a 1:1 map, but because 90000000 is > > what U-Boot chooses when it scans PCIe 1. > > > > At this point, everything is working. Here is /proc/iomap: > > > > 90000000-9fffffff : /plb/pciex@0c0000000 > > 90000000-94ffffff : PCI Bus 0001:41 > > 90000000-9001ffff : 0001:41:00.0 > > 90100000-94ffffff : PCI Bus 0001:42 > > 90100000-92ffffff : PCI Bus 0001:43 > > 91000000-91ffffff : 0001:43:00.0 //<--- was missing before > > 92000000-92ffffff : 0001:43:00.0 //<--- was missing before > > 93000000-94ffffff : PCI Bus 0001:44 > > 93000000-93ffffff : 0001:44:00.0 //<--- was missing before > > 94000000-94ffffff : 0001:44:00.0 //<--- was missing before > > e0000000-e7ffffff : /plb/pciex@0a0000000 > > e0000000-e7ffffff : PCI Bus 0000:01 > > e0000000-e00fffff : 0000:01:00.0 > > e0100000-e01fffff : 0000:01:00.0 > > e4000000-e7ffffff : 0000:01:00.0 > > ef600200-ef600207 : serial > > ef600300-ef600307 : serial > > ef600600-ef600606 : spi_ppc4xx_of > > ef6c0000-ef6cffff : dwc_otg.0 > > ef6c0000-ef6cffff : dwc_otg > > fc000000-ffffffff : fc000000.nor_flash > > > > Now I see the bars for the ASICs (flagged above). I could stop here, > > and declare success, but I don't really like this solution, because it > > requires me to be sure the dts has the same bus addresses that U-Boot > > will choose. Seems risky. > > > > Tentative conclusion: Either I still have something set wrong in my dts > > or there is a bug in the Linux PCI bus mapping code. > > > > Steve > > > >> > >> It does look to me like some of your device BARs have been setup already > >> by the firmware in a way that conflict with the way you configure your > >> ranges, and the kernel doesn't appear to detect nor try to remap that > >> which would happen if you have the "probe only" flag set. > >> > >> IE. On your c0000000 bus, you have memory at 90000000 CPU space mapped > >> to 80000000 PCI space. However, when probing, the kernel finds: > >> > >> pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] > >> > >> IE. A BAR was already set with a value of 90000000 PCI-side which is out > >> of the bounds you have for your bus. > >> > >> Maybe you really want to configure that second bus to have CPU 90000000 > >> mapped to 90000000 PCI-side ? (IE. a 1:1 mapping). That would be > >> something to fix in your "ranges" property. > >> > >> Cheers, > >> Ben. > > > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: device not available because of BAR 0 collisions 2011-04-28 20:55 ` Benjamin Herrenschmidt @ 2011-04-28 21:11 ` Steven A. Falco 2011-04-28 21:14 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 11+ messages in thread From: Steven A. Falco @ 2011-04-28 21:11 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev On 04/28/2011 04:55 PM, Benjamin Herrenschmidt wrote: > On Thu, 2011-04-28 at 13:29 -0400, Steven A. Falco wrote: >> On 04/27/2011 03:51 PM, Steven A. Falco wrote: >>> On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote: >>>> On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote: >>>>> On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote: >>>>>> On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote: >>>>>>> I'm getting an error message when trying to talk to some custom >>>>>>> hardware: >>>>>>> >>>>>>> dx83xx 0001:43:00.0: device not available because of BAR 0 >>>>>>> [0xa1000000-0xa1ffffff] collisions >> >> I believe I've gotten to the root cause of this issue. Turns out the >> ASIC is reporting a class code of 0000, in violation of the PCI spec. >> >> As a result, Linux is refusing to set up the ASIC, and so it remains >> with the settings made in U-Boot, which are in conflict with the >> allocation Linux makes for the bridge the ASIC is connected to. >> >> So Ben, you are absolutely right that there was some left-over >> configuration. > > Hrm. that's odd still, do you know where in linux is the code that tests > for the class code and decides to not setup the device resources ? I > can't see that... It is in __dev_sort_resources() in setup-bus.c There is this test: /* Don't touch classless devices or host bridges or ioapics. */ if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST) return; where PCI_CLASS_NOT_DEFINED is 0x0000. So basically Linux skips over allocating anything with a class of 0. Steve > >> My choices appear to be: >> >> 1) Fix the ASIC (yeah, right) >> >> 2) Force Linux to use the U-Boot settings >> >> 3) Hack Linux to set up a device with a bogus class. >> >> I'm not sure why this hardware works in x86 - I guess it is less >> fussy. > > x86 probably just re-uses whatever setting the BIOS does, but I'm still > a bit surprised by your class code story. > > I supose you can do a PCI header quirk that overrides the class code in > struct pci_dev. Something like: > > static void __devinit quirk_your_asic_class(struct pci_dev *dev) > { > dev->class = foobar; > } > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_xxx, PCI_DEVICE_ID_yyy, quirk_your_asic_class); > > But I'd like to figure out where that is tested bcs I haven't found so > far... > >> Steve >> >>>>>>> >>>>>>> I see in setup-res.c that this message comes out when there is no >>>>>>> parent for >>>>>>> a device resource. >>>>>> >>>>>> .../... >>>>>> >>>>>> It mostly happens in arch/powerpc/kernel/pci-common.c and the generic >>>>>> setup-res.c >>>>>> >>>>>> Try #define DEBUG at the top (before the #includes) of pci-common.c and >>>>>> pci_32.c (remove the exiting #undef in the last one) and send us the >>>>>> full dmesg log, along with the output of cat /proc/iomem >>>> >>>> Have you set any specific flags ? IE. Modified the value of >>>> ppc_pci_flags from what the 4xx code sets originally ? >>> >>> For fun, I just tried changing: >>> >>> ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC); >>> >>> to: >>> >>> ppc_pci_set_flags(PPC_PCI_PROBE_ONLY); >>> >>> I realize that is the exact opposite of what you were suggesting, but >>> please bear with me for a bit. >>> >>> I also changed the PCIE 0 ranges from: >>> >>> ranges = <0x02000000 0x00000000 0x80000000 0x90000000 0x00000000 0x10000000 >>> 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; >>> >>> ranges = <0x02000000 0x00000000 0x90000000 0x90000000 0x00000000 0x10000000 >>> 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; >>> >>> I changed the ranges not because I wanted a 1:1 map, but because 90000000 is >>> what U-Boot chooses when it scans PCIe 1. >>> >>> At this point, everything is working. Here is /proc/iomap: >>> >>> 90000000-9fffffff : /plb/pciex@0c0000000 >>> 90000000-94ffffff : PCI Bus 0001:41 >>> 90000000-9001ffff : 0001:41:00.0 >>> 90100000-94ffffff : PCI Bus 0001:42 >>> 90100000-92ffffff : PCI Bus 0001:43 >>> 91000000-91ffffff : 0001:43:00.0 //<--- was missing before >>> 92000000-92ffffff : 0001:43:00.0 //<--- was missing before >>> 93000000-94ffffff : PCI Bus 0001:44 >>> 93000000-93ffffff : 0001:44:00.0 //<--- was missing before >>> 94000000-94ffffff : 0001:44:00.0 //<--- was missing before >>> e0000000-e7ffffff : /plb/pciex@0a0000000 >>> e0000000-e7ffffff : PCI Bus 0000:01 >>> e0000000-e00fffff : 0000:01:00.0 >>> e0100000-e01fffff : 0000:01:00.0 >>> e4000000-e7ffffff : 0000:01:00.0 >>> ef600200-ef600207 : serial >>> ef600300-ef600307 : serial >>> ef600600-ef600606 : spi_ppc4xx_of >>> ef6c0000-ef6cffff : dwc_otg.0 >>> ef6c0000-ef6cffff : dwc_otg >>> fc000000-ffffffff : fc000000.nor_flash >>> >>> Now I see the bars for the ASICs (flagged above). I could stop here, >>> and declare success, but I don't really like this solution, because it >>> requires me to be sure the dts has the same bus addresses that U-Boot >>> will choose. Seems risky. >>> >>> Tentative conclusion: Either I still have something set wrong in my dts >>> or there is a bug in the Linux PCI bus mapping code. >>> >>> Steve >>> >>>> >>>> It does look to me like some of your device BARs have been setup already >>>> by the firmware in a way that conflict with the way you configure your >>>> ranges, and the kernel doesn't appear to detect nor try to remap that >>>> which would happen if you have the "probe only" flag set. >>>> >>>> IE. On your c0000000 bus, you have memory at 90000000 CPU space mapped >>>> to 80000000 PCI space. However, when probing, the kernel finds: >>>> >>>> pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] >>>> >>>> IE. A BAR was already set with a value of 90000000 PCI-side which is out >>>> of the bounds you have for your bus. >>>> >>>> Maybe you really want to configure that second bus to have CPU 90000000 >>>> mapped to 90000000 PCI-side ? (IE. a 1:1 mapping). That would be >>>> something to fix in your "ranges" property. >>>> >>>> Cheers, >>>> Ben. >>> >>> >> >> > > > -- A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: device not available because of BAR 0 collisions 2011-04-28 21:11 ` Steven A. Falco @ 2011-04-28 21:14 ` Benjamin Herrenschmidt 2011-04-28 21:19 ` Steven A. Falco 0 siblings, 1 reply; 11+ messages in thread From: Benjamin Herrenschmidt @ 2011-04-28 21:14 UTC (permalink / raw) To: Steven A. Falco; +Cc: linuxppc-dev On Thu, 2011-04-28 at 17:11 -0400, Steven A. Falco wrote: > It is in __dev_sort_resources() in setup-bus.c > > There is this test: > > /* Don't touch classless devices or host bridges or ioapics. */ > if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST) > return; > > where PCI_CLASS_NOT_DEFINED is 0x0000. So basically Linux skips over allocating > anything with a class of 0. Ah nice. Can you try the quirk ? Cheers, Ben. > Steve > > > > >> My choices appear to be: > >> > >> 1) Fix the ASIC (yeah, right) > >> > >> 2) Force Linux to use the U-Boot settings > >> > >> 3) Hack Linux to set up a device with a bogus class. > >> > >> I'm not sure why this hardware works in x86 - I guess it is less > >> fussy. > > > > x86 probably just re-uses whatever setting the BIOS does, but I'm still > > a bit surprised by your class code story. > > > > I supose you can do a PCI header quirk that overrides the class code in > > struct pci_dev. Something like: > > > > static void __devinit quirk_your_asic_class(struct pci_dev *dev) > > { > > dev->class = foobar; > > } > > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_xxx, PCI_DEVICE_ID_yyy, quirk_your_asic_class); > > > > But I'd like to figure out where that is tested bcs I haven't found so > > far... > > > >> Steve > >> > >>>>>>> > >>>>>>> I see in setup-res.c that this message comes out when there is no > >>>>>>> parent for > >>>>>>> a device resource. > >>>>>> > >>>>>> .../... > >>>>>> > >>>>>> It mostly happens in arch/powerpc/kernel/pci-common.c and the generic > >>>>>> setup-res.c > >>>>>> > >>>>>> Try #define DEBUG at the top (before the #includes) of pci-common.c and > >>>>>> pci_32.c (remove the exiting #undef in the last one) and send us the > >>>>>> full dmesg log, along with the output of cat /proc/iomem > >>>> > >>>> Have you set any specific flags ? IE. Modified the value of > >>>> ppc_pci_flags from what the 4xx code sets originally ? > >>> > >>> For fun, I just tried changing: > >>> > >>> ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC); > >>> > >>> to: > >>> > >>> ppc_pci_set_flags(PPC_PCI_PROBE_ONLY); > >>> > >>> I realize that is the exact opposite of what you were suggesting, but > >>> please bear with me for a bit. > >>> > >>> I also changed the PCIE 0 ranges from: > >>> > >>> ranges = <0x02000000 0x00000000 0x80000000 0x90000000 0x00000000 0x10000000 > >>> 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; > >>> > >>> ranges = <0x02000000 0x00000000 0x90000000 0x90000000 0x00000000 0x10000000 > >>> 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; > >>> > >>> I changed the ranges not because I wanted a 1:1 map, but because 90000000 is > >>> what U-Boot chooses when it scans PCIe 1. > >>> > >>> At this point, everything is working. Here is /proc/iomap: > >>> > >>> 90000000-9fffffff : /plb/pciex@0c0000000 > >>> 90000000-94ffffff : PCI Bus 0001:41 > >>> 90000000-9001ffff : 0001:41:00.0 > >>> 90100000-94ffffff : PCI Bus 0001:42 > >>> 90100000-92ffffff : PCI Bus 0001:43 > >>> 91000000-91ffffff : 0001:43:00.0 //<--- was missing before > >>> 92000000-92ffffff : 0001:43:00.0 //<--- was missing before > >>> 93000000-94ffffff : PCI Bus 0001:44 > >>> 93000000-93ffffff : 0001:44:00.0 //<--- was missing before > >>> 94000000-94ffffff : 0001:44:00.0 //<--- was missing before > >>> e0000000-e7ffffff : /plb/pciex@0a0000000 > >>> e0000000-e7ffffff : PCI Bus 0000:01 > >>> e0000000-e00fffff : 0000:01:00.0 > >>> e0100000-e01fffff : 0000:01:00.0 > >>> e4000000-e7ffffff : 0000:01:00.0 > >>> ef600200-ef600207 : serial > >>> ef600300-ef600307 : serial > >>> ef600600-ef600606 : spi_ppc4xx_of > >>> ef6c0000-ef6cffff : dwc_otg.0 > >>> ef6c0000-ef6cffff : dwc_otg > >>> fc000000-ffffffff : fc000000.nor_flash > >>> > >>> Now I see the bars for the ASICs (flagged above). I could stop here, > >>> and declare success, but I don't really like this solution, because it > >>> requires me to be sure the dts has the same bus addresses that U-Boot > >>> will choose. Seems risky. > >>> > >>> Tentative conclusion: Either I still have something set wrong in my dts > >>> or there is a bug in the Linux PCI bus mapping code. > >>> > >>> Steve > >>> > >>>> > >>>> It does look to me like some of your device BARs have been setup already > >>>> by the firmware in a way that conflict with the way you configure your > >>>> ranges, and the kernel doesn't appear to detect nor try to remap that > >>>> which would happen if you have the "probe only" flag set. > >>>> > >>>> IE. On your c0000000 bus, you have memory at 90000000 CPU space mapped > >>>> to 80000000 PCI space. However, when probing, the kernel finds: > >>>> > >>>> pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] > >>>> > >>>> IE. A BAR was already set with a value of 90000000 PCI-side which is out > >>>> of the bounds you have for your bus. > >>>> > >>>> Maybe you really want to configure that second bus to have CPU 90000000 > >>>> mapped to 90000000 PCI-side ? (IE. a 1:1 mapping). That would be > >>>> something to fix in your "ranges" property. > >>>> > >>>> Cheers, > >>>> Ben. > >>> > >>> > >> > >> > > > > > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: device not available because of BAR 0 collisions 2011-04-28 21:14 ` Benjamin Herrenschmidt @ 2011-04-28 21:19 ` Steven A. Falco 0 siblings, 0 replies; 11+ messages in thread From: Steven A. Falco @ 2011-04-28 21:19 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev On 04/28/2011 05:14 PM, Benjamin Herrenschmidt wrote: > On Thu, 2011-04-28 at 17:11 -0400, Steven A. Falco wrote: > >> It is in __dev_sort_resources() in setup-bus.c >> >> There is this test: >> >> /* Don't touch classless devices or host bridges or ioapics. */ >> if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST) >> return; >> >> where PCI_CLASS_NOT_DEFINED is 0x0000. So basically Linux skips over allocating >> anything with a class of 0. > > Ah nice. Can you try the quirk ? That is exactly the way I fixed it. :-) I added the following in my board-specific file: static void quirk_d7(struct pci_dev *pdev) { // D7 has a bogus class code, which breaks BAR assignment. Patch it. pdev->class = 0xff0000; } DECLARE_PCI_FIXUP_EARLY(0x1b03, 0x7000, quirk_d7); (And thanks again for your assistance - I appreciate it.) Steve > > Cheers, > Ben. > >> Steve >> >>> >>>> My choices appear to be: >>>> >>>> 1) Fix the ASIC (yeah, right) >>>> >>>> 2) Force Linux to use the U-Boot settings >>>> >>>> 3) Hack Linux to set up a device with a bogus class. >>>> >>>> I'm not sure why this hardware works in x86 - I guess it is less >>>> fussy. >>> >>> x86 probably just re-uses whatever setting the BIOS does, but I'm still >>> a bit surprised by your class code story. >>> >>> I supose you can do a PCI header quirk that overrides the class code in >>> struct pci_dev. Something like: >>> >>> static void __devinit quirk_your_asic_class(struct pci_dev *dev) >>> { >>> dev->class = foobar; >>> } >>> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_xxx, PCI_DEVICE_ID_yyy, quirk_your_asic_class); >>> >>> But I'd like to figure out where that is tested bcs I haven't found so >>> far... >>> >>>> Steve >>>> >>>>>>>>> >>>>>>>>> I see in setup-res.c that this message comes out when there is no >>>>>>>>> parent for >>>>>>>>> a device resource. >>>>>>>> >>>>>>>> .../... >>>>>>>> >>>>>>>> It mostly happens in arch/powerpc/kernel/pci-common.c and the generic >>>>>>>> setup-res.c >>>>>>>> >>>>>>>> Try #define DEBUG at the top (before the #includes) of pci-common.c and >>>>>>>> pci_32.c (remove the exiting #undef in the last one) and send us the >>>>>>>> full dmesg log, along with the output of cat /proc/iomem >>>>>> >>>>>> Have you set any specific flags ? IE. Modified the value of >>>>>> ppc_pci_flags from what the 4xx code sets originally ? >>>>> >>>>> For fun, I just tried changing: >>>>> >>>>> ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC); >>>>> >>>>> to: >>>>> >>>>> ppc_pci_set_flags(PPC_PCI_PROBE_ONLY); >>>>> >>>>> I realize that is the exact opposite of what you were suggesting, but >>>>> please bear with me for a bit. >>>>> >>>>> I also changed the PCIE 0 ranges from: >>>>> >>>>> ranges = <0x02000000 0x00000000 0x80000000 0x90000000 0x00000000 0x10000000 >>>>> 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; >>>>> >>>>> ranges = <0x02000000 0x00000000 0x90000000 0x90000000 0x00000000 0x10000000 >>>>> 0x01000000 0x00000000 0x00000000 0xe8010000 0x00000000 0x00010000>; >>>>> >>>>> I changed the ranges not because I wanted a 1:1 map, but because 90000000 is >>>>> what U-Boot chooses when it scans PCIe 1. >>>>> >>>>> At this point, everything is working. Here is /proc/iomap: >>>>> >>>>> 90000000-9fffffff : /plb/pciex@0c0000000 >>>>> 90000000-94ffffff : PCI Bus 0001:41 >>>>> 90000000-9001ffff : 0001:41:00.0 >>>>> 90100000-94ffffff : PCI Bus 0001:42 >>>>> 90100000-92ffffff : PCI Bus 0001:43 >>>>> 91000000-91ffffff : 0001:43:00.0 //<--- was missing before >>>>> 92000000-92ffffff : 0001:43:00.0 //<--- was missing before >>>>> 93000000-94ffffff : PCI Bus 0001:44 >>>>> 93000000-93ffffff : 0001:44:00.0 //<--- was missing before >>>>> 94000000-94ffffff : 0001:44:00.0 //<--- was missing before >>>>> e0000000-e7ffffff : /plb/pciex@0a0000000 >>>>> e0000000-e7ffffff : PCI Bus 0000:01 >>>>> e0000000-e00fffff : 0000:01:00.0 >>>>> e0100000-e01fffff : 0000:01:00.0 >>>>> e4000000-e7ffffff : 0000:01:00.0 >>>>> ef600200-ef600207 : serial >>>>> ef600300-ef600307 : serial >>>>> ef600600-ef600606 : spi_ppc4xx_of >>>>> ef6c0000-ef6cffff : dwc_otg.0 >>>>> ef6c0000-ef6cffff : dwc_otg >>>>> fc000000-ffffffff : fc000000.nor_flash >>>>> >>>>> Now I see the bars for the ASICs (flagged above). I could stop here, >>>>> and declare success, but I don't really like this solution, because it >>>>> requires me to be sure the dts has the same bus addresses that U-Boot >>>>> will choose. Seems risky. >>>>> >>>>> Tentative conclusion: Either I still have something set wrong in my dts >>>>> or there is a bug in the Linux PCI bus mapping code. >>>>> >>>>> Steve >>>>> >>>>>> >>>>>> It does look to me like some of your device BARs have been setup already >>>>>> by the firmware in a way that conflict with the way you configure your >>>>>> ranges, and the kernel doesn't appear to detect nor try to remap that >>>>>> which would happen if you have the "probe only" flag set. >>>>>> >>>>>> IE. On your c0000000 bus, you have memory at 90000000 CPU space mapped >>>>>> to 80000000 PCI space. However, when probing, the kernel finds: >>>>>> >>>>>> pci 0001:41:00.0: reg 10 32bit mmio: [0x90000000-0x9001ffff] >>>>>> >>>>>> IE. A BAR was already set with a value of 90000000 PCI-side which is out >>>>>> of the bounds you have for your bus. >>>>>> >>>>>> Maybe you really want to configure that second bus to have CPU 90000000 >>>>>> mapped to 90000000 PCI-side ? (IE. a 1:1 mapping). That would be >>>>>> something to fix in your "ranges" property. >>>>>> >>>>>> Cheers, >>>>>> Ben. >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > -- A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-04-28 21:19 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-04-25 20:10 device not available because of BAR 0 collisions Steven A. Falco 2011-04-26 0:01 ` Benjamin Herrenschmidt 2011-04-26 13:38 ` Steven A. Falco 2011-04-26 23:39 ` Benjamin Herrenschmidt 2011-04-27 14:22 ` Steven A. Falco 2011-04-27 19:51 ` Steven A. Falco 2011-04-28 17:29 ` Steven A. Falco 2011-04-28 20:55 ` Benjamin Herrenschmidt 2011-04-28 21:11 ` Steven A. Falco 2011-04-28 21:14 ` Benjamin Herrenschmidt 2011-04-28 21:19 ` Steven A. Falco
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).