* Au1500 PCI autoconfig issues with multiple PCI devices?
@ 2003-04-24 18:48 Jeff Baitis
2003-04-24 19:11 ` Jun Sun
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Baitis @ 2003-04-24 18:48 UTC (permalink / raw)
To: linux-mips
Hi ya'll:
This is the first time I've tried multiple PCI devices on the Au1500. I have a
PCI->CardBus bridge and a 3Com ethernet plugged into the Au1500's PCI bus. I'm
using the linux_2_4 branch.
Here's the applicable dmesg:
...
Autoconfig PCI channel 0x8028e518
Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
00:0b.0 Class 0607: 104c:ac56
CARDBUS Bridge: primary=00, secondary=01
PCI Autoconfig: Found CardBus bridge, device 11 function 0
Mem at 0x40000000 [size=0x1000]
Scanning sub bus 01, I/O 0x00000300, Mem 0x40001000
Back to bus 00, sub_bus is 1
00:0d.0 Class 0200: 10b7:9200 (rev 78)
I/O at 0x00000300 [size=0x80]
Mem at 0x40001000 [size=0x80]
Linux NET4.0 for Linux 2.4
...
Here's lspci output:
root@10.1.1.122:~# lspci -vx
00:0b.0 CardBus bridge: Texas Instruments: Unknown device ac56
Flags: bus master, medium devsel, latency 168, IRQ 255
Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=176
Memory window 0: 40000000-403ff000 (prefetchable)
Memory window 1: 40400000-407ff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
00: 4c 10 56 ac 07 00 10 02 00 00 07 06 08 a8 02 00
10: 00 00 00 40 a0 00 00 02 00 01 01 b0 00 00 00 40
20: 00 f0 3f 40 00 00 40 40 00 f0 7f 40 00 40 00 00
30: fc 40 00 00 00 44 00 00 fc 44 00 00 ff 01 40 05
40: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:0d.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 78)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
Flags: bus master, medium devsel, latency 128, IRQ 1
I/O ports at 0300 [size=128]
Memory at 40001000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
00: b7 10 00 92 07 00 10 02 78 00 00 02 00 80 00 00
10: 01 03 00 00 00 10 00 40 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 00 10
30: 00 00 00 00 dc 00 00 00 00 00 00 00 01 01 0a 0a
-------------------------------------------------------------------------
My 3Com card is communicating over the network very effectively (as a matter of
fact, I've been using the 3Com card for netboot since I've been having problems
with my onboard PHY). I guess it's a (blessing?) that I was forced to use
multiple PCI devices...
Anyhow, since the 3Com card is configured in the same PCI memory space, card
services has a very hard time talking to the CardBus bridge. Below, I tried
a couple of different base addresses for the memory probe:
cardmgr[203]cs: memory probe 0x40000000-0x40ffffff:: starting, version is 3.2.3
excluding 0x40000000-0x40bfffff
<6>cs: memory probe 0x40000000-0x40ffffff: excluding 0x40000000-0x40bfffff
cardmgr[203]: socket 0: Anonymous Memory
cardmgr[203]: executing: 'modprobe memory_cs'
cardmgr[203]: + modprobe: Can't locate module memory_cs
cardmgr[203]: modprobe exited with status 255
cardmgr[203]: module /lib/modules/2.4.21-pre4/pcmcia/memory_cs.o not available
cardmgr[203]: get dev info on socket 0 failed: Resource temporarily unavailable
cardmgr[203]: executing: 'modprobe -r memory_cs'
Trying to free nonexistent resource <40c00000-40c00fff>
cardmgr[203]: exiting
<4>Trying to free nonexistent resource <40c00000-40c00fff>
unloading Kernel Card Services
<6>unloading Kernel Card Services
Linux Kernel Card Services 3.1.22
options: [pci] [cardbus]
<6>Linux Kernel Card Services 3.1.22
<6> options: [pci] [cardbus]
Yenta IRQ list 0000, PCI irq0
Socket status: 30000110
<4>Yenta IRQ list 0000, PCI irq0
<4>Socket status: 30000110
cardmgr[253]:cs: memory probe 0x40001000-0x40ffffff: starting, version is 3.2.3
excluding 0x40001000-0x410defff
cs: unable to map card memory!
cs: unable to map card memory!
<6>cs: memory probe 0x40001000-0x40ffffff: excluding 0x40001000-0x410defff
<5>cs: unable to map card memory!
<5>cs: unable to map card memory!
cardmcs: unable to map card memory!
grcs: unable to map card memory!
[2cs: unable to map card memory!
53cs: unable to map card memory!
]: socket 0: Anonymous Memory
<5>cs: unable to map card memory!
<5>cs: unable to map card memory!
<5>cs: unable to map card memory!
<5>cs: unable to map card memory!
cardmgr[253]: executing: 'modprobe memory_cs'
cardmgr[253]: + modprobe: Can't locate module memory_cs
cardmgr[253]: modprobe exited with status 255
cardmgr[253]: module /lib/modules/2.4.21-pre4/pcmcia/memory_cs.o not available
cardmgr[253]: get dev info on socket 0 failed: Resource temporarily unavailable
I can only assume that this has to do with PCI misconfiguration.
Thoughts?
Thanks for taking a look!
-Jeff
--
Jeffrey Baitis - Associate Software Engineer
Evolution Robotics, Inc.
130 West Union Street
Pasadena CA 91103
tel: 626.535.2776 | fax: 626.535.2777 | baitisj@evolution.com
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Au1500 PCI autoconfig issues with multiple PCI devices? 2003-04-24 18:48 Au1500 PCI autoconfig issues with multiple PCI devices? Jeff Baitis @ 2003-04-24 19:11 ` Jun Sun 2003-04-24 19:46 ` Pete Popov 2003-04-24 20:04 ` Jeff Baitis 0 siblings, 2 replies; 8+ messages in thread From: Jun Sun @ 2003-04-24 19:11 UTC (permalink / raw) To: Jeff Baitis; +Cc: linux-mips, jsun [-- Attachment #1: Type: text/plain, Size: 448 bytes --] On Thu, Apr 24, 2003 at 11:48:32AM -0700, Jeff Baitis wrote: > Hi ya'll: > > This is the first time I've tried multiple PCI devices on the Au1500. I have a > PCI->CardBus bridge and a 3Com ethernet plugged into the Au1500's PCI bus. I'm > using the linux_2_4 branch. > <snip> Try this patch and let me know the results. BTW, I did not know Au1500 has a cardbus controller. I was under impression it is a PCMCIA controller. Interesting. Jun [-- Attachment #2: junk --] [-- Type: text/plain, Size: 596 bytes --] diff -Nru link/arch/mips/kernel/pci_auto.c.orig link/arch/mips/kernel/pci_auto.c --- link/arch/mips/kernel/pci_auto.c.orig Thu Apr 10 14:13:57 2003 +++ link/arch/mips/kernel/pci_auto.c Thu Apr 24 12:10:16 2003 @@ -354,8 +354,8 @@ * configured by this routine to happily live behind a * P2P bridge in a system. */ - pciauto_upper_memspc += 0x00400000; - pciauto_upper_iospc += 0x00004000; + pciauto_lower_memspc += 0x00400000; + pciauto_lower_iospc += 0x00004000; /* Align memory and I/O to 4KB and 4 byte boundaries. */ pciauto_lower_memspc = (pciauto_lower_memspc + (0x1000 - 1)) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Au1500 PCI autoconfig issues with multiple PCI devices? 2003-04-24 19:11 ` Jun Sun @ 2003-04-24 19:46 ` Pete Popov 2003-04-24 20:04 ` Jeff Baitis 1 sibling, 0 replies; 8+ messages in thread From: Pete Popov @ 2003-04-24 19:46 UTC (permalink / raw) To: Jun Sun; +Cc: Jeff Baitis, Linux MIPS mailing list On Thu, 2003-04-24 at 12:11, Jun Sun wrote: > On Thu, Apr 24, 2003 at 11:48:32AM -0700, Jeff Baitis wrote: > > Hi ya'll: > > > > This is the first time I've tried multiple PCI devices on the Au1500. I have a > > PCI->CardBus bridge and a 3Com ethernet plugged into the Au1500's PCI bus. I'm > > using the linux_2_4 branch. > > > <snip> > > Try this patch and let me know the results. > > BTW, I did not know Au1500 has a cardbus controller. I was under impression > it is a PCMCIA controller. Interesting. The cardbus controller is a pci plug-in card. Pete ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Au1500 PCI autoconfig issues with multiple PCI devices? 2003-04-24 19:11 ` Jun Sun 2003-04-24 19:46 ` Pete Popov @ 2003-04-24 20:04 ` Jeff Baitis 2003-04-24 20:12 ` Pete Popov 1 sibling, 1 reply; 8+ messages in thread From: Jeff Baitis @ 2003-04-24 20:04 UTC (permalink / raw) To: Jun Sun; +Cc: linux-mips Hi Jun: To clarify, the DbAu1500 development board does *not* have a CardBus controller. Our fabbed board, however, does ;) Also, before I applied that patch, you should know that I tried plugging in a PCI->PCI bridge, placing the 3Com card behind the bridge, and the PCI auto config didn't find the 3Com card. :( Autoconfig PCI channel 0x8028c428 Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000 00:0b.0 Class 0607: 104c:ac56 CARDBUS Bridge: primary=00, secondary=01 PCI Autoconfig: Found CardBus bridge, device 11 function 0 Mem at 0x40000000 [size=0x1000] Scanning sub bus 01, I/O 0x00000300, Mem 0x40001000 Back to bus 00, sub_bus is 1 00:0d.0 Class 0604: 1011:0022 (rev 02) Bridge: primary=00, secondary=02 Scanning sub bus 02, I/O 0x00001000, Mem 0x40100000 After applying the patch, it looks like the PCI autoconfig fortunately didn't assign overlapping memory areas: 00:0b.0 CardBus bridge: Texas Instruments: Unknown device ac56 Flags: bus master, medium devsel, latency 0, IRQ 255 Memory at 40000000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory window 0: 40001000-40400000 (prefetchable) I/O window 0: 00000300-000042ff I/O window 1: 00000000-00000003 16-bit legacy interface ports at 0001 00:0d.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 78) Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC Flags: bus master, medium devsel, latency 128, IRQ 1 I/O ports at 4300 [size=128] Memory at 40401000 (32-bit, non-prefetchable) [size=128] Expansion ROM at <unassigned> [disabled] [size=128K] Capabilities: [dc] Power Management version 2 It seems like there used to be two memory windows associated with the CardBus bridge: although I'm not completely familiar with what it *should* look like, I think there should be two; one for the EXCA and one for the 32bit CardBus (?) Anyway, cardservices is locking up on me right now. Perhaps I don't have the memory range right. I'm including port 0x300-0x42ff, and include memory 0x40001000-0x403fffff. Thanks for your help, Jun. Hopefully I'll have this working today. Here's another question: What are the goals of the AU1500 PCI auto config? Is it supposed to be a full implementation, or just enough to work with a PCI card? The reason I ask is that the DBAu1500 has only one PCI slot, so a simple implementation would normally suffice. Restated: I don't know if the PCI auto config code was designed to work with all sorts of wacky PCI devices. I don't know if the intention of the code is to support the single PCI slot present on the DbAu1500 development board, or if it is supposed to be more flexible (and complicated). Thanks. -Jeff On Thu, Apr 24, 2003 at 12:11:40PM -0700, Jun Sun wrote: > > > On Thu, Apr 24, 2003 at 11:48:32AM -0700, Jeff Baitis wrote: > > Hi ya'll: > > > > This is the first time I've tried multiple PCI devices on the Au1500. I have a > > PCI->CardBus bridge and a 3Com ethernet plugged into the Au1500's PCI bus. I'm > > using the linux_2_4 branch. > > > <snip> > > Try this patch and let me know the results. > > BTW, I did not know Au1500 has a cardbus controller. I was under impression > it is a PCMCIA controller. Interesting. > > Jun > diff -Nru link/arch/mips/kernel/pci_auto.c.orig link/arch/mips/kernel/pci_auto.c > --- link/arch/mips/kernel/pci_auto.c.orig Thu Apr 10 14:13:57 2003 > +++ link/arch/mips/kernel/pci_auto.c Thu Apr 24 12:10:16 2003 > @@ -354,8 +354,8 @@ > * configured by this routine to happily live behind a > * P2P bridge in a system. > */ > - pciauto_upper_memspc += 0x00400000; > - pciauto_upper_iospc += 0x00004000; > + pciauto_lower_memspc += 0x00400000; > + pciauto_lower_iospc += 0x00004000; > > /* Align memory and I/O to 4KB and 4 byte boundaries. */ > pciauto_lower_memspc = (pciauto_lower_memspc + (0x1000 - 1)) -- Jeffrey Baitis - Associate Software Engineer Evolution Robotics, Inc. 130 West Union Street Pasadena CA 91103 tel: 626.535.2776 | fax: 626.535.2777 | baitisj@evolution.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Au1500 PCI autoconfig issues with multiple PCI devices? 2003-04-24 20:04 ` Jeff Baitis @ 2003-04-24 20:12 ` Pete Popov 2003-04-25 1:48 ` Jun Sun 0 siblings, 1 reply; 8+ messages in thread From: Pete Popov @ 2003-04-24 20:12 UTC (permalink / raw) To: baitisj; +Cc: Jun Sun, Linux MIPS mailing list > Here's another question: > What are the goals of the AU1500 PCI auto config? Is it supposed to be a full > implementation, or just enough to work with a PCI card? The reason I ask is > that the DBAu1500 has only one PCI slot, so a simple implementation would > normally suffice. > > Restated: I don't know if the PCI auto config code was designed to work with > all sorts of wacky PCI devices. I don't know if the intention of the code is to > support the single PCI slot present on the DbAu1500 development board, or if it > is supposed to be more flexible (and complicated). The MIPS pci auto should work fine with a single PCI bus and it _should_ be a full implementation. The code was ported from PPC some time ago, but sub busses were not tested. Also, if I remember correctly, we simplified a bit the more complex PPC implementation and maybe you're seeing the result of that :) Pete ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Au1500 PCI autoconfig issues with multiple PCI devices? 2003-04-24 20:12 ` Pete Popov @ 2003-04-25 1:48 ` Jun Sun 2003-04-25 1:54 ` Pete Popov 0 siblings, 1 reply; 8+ messages in thread From: Jun Sun @ 2003-04-25 1:48 UTC (permalink / raw) To: Pete Popov; +Cc: baitisj, Linux MIPS mailing list, jsun On Thu, Apr 24, 2003 at 01:12:11PM -0700, Pete Popov wrote: > > > Here's another question: > > > What are the goals of the AU1500 PCI auto config? Is it supposed to be a full > > implementation, or just enough to work with a PCI card? The reason I ask is > > that the DBAu1500 has only one PCI slot, so a simple implementation would > > normally suffice. > > > > Restated: I don't know if the PCI auto config code was designed to work with > > all sorts of wacky PCI devices. I don't know if the intention of the code is to > > support the single PCI slot present on the DbAu1500 development board, or if it > > is supposed to be more flexible (and complicated). > > The MIPS pci auto should work fine with a single PCI bus and it _should_ > be a full implementation. The code was ported from PPC some time ago, > but sub busses were not tested. That is not true. pciauto has been working P2P bridges pretty much since day one. Usually sub-bus not working is due to type 1 configuration not supported in pci ops, which is board-dependent code. I took a brief look of au1x00 pci_ops and it appears it does not support type 1 configuration access. See arch/mips/ddb5xxx/ddb5477/pci_ops.c for one example on how type 1 configuration being supported. Jun ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Au1500 PCI autoconfig issues with multiple PCI devices? 2003-04-25 1:48 ` Jun Sun @ 2003-04-25 1:54 ` Pete Popov 2003-04-25 1:58 ` Jun Sun 0 siblings, 1 reply; 8+ messages in thread From: Pete Popov @ 2003-04-25 1:54 UTC (permalink / raw) To: Jun Sun; +Cc: baitisj, Linux MIPS mailing list On Thu, 2003-04-24 at 18:48, Jun Sun wrote: > On Thu, Apr 24, 2003 at 01:12:11PM -0700, Pete Popov wrote: > > > > > Here's another question: > > > > > What are the goals of the AU1500 PCI auto config? Is it supposed to be a full > > > implementation, or just enough to work with a PCI card? The reason I ask is > > > that the DBAu1500 has only one PCI slot, so a simple implementation would > > > normally suffice. > > > > > > Restated: I don't know if the PCI auto config code was designed to work with > > > all sorts of wacky PCI devices. I don't know if the intention of the code is to > > > support the single PCI slot present on the DbAu1500 development board, or if it > > > is supposed to be more flexible (and complicated). > > > > The MIPS pci auto should work fine with a single PCI bus and it _should_ > > be a full implementation. The code was ported from PPC some time ago, > > but sub busses were not tested. > > That is not true. pciauto has been working P2P bridges pretty much since day one. > > Usually sub-bus not working is due to type 1 configuration not supported > in pci ops, which is board-dependent code. > > I took a brief look of au1x00 pci_ops and it appears it does not support type > 1 configuration access. See arch/mips/ddb5xxx/ddb5477/pci_ops.c for one > example on how type 1 configuration being supported. There is support for type 1 accesses in arch/mips/au1000/common/pci_ops.c. Maybe you were looking at the pb1000 pci routine which had limited pci bus support in an fpga. The Au1500 pci routine does support type 1 accesses. Pete ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Au1500 PCI autoconfig issues with multiple PCI devices? 2003-04-25 1:54 ` Pete Popov @ 2003-04-25 1:58 ` Jun Sun 0 siblings, 0 replies; 8+ messages in thread From: Jun Sun @ 2003-04-25 1:58 UTC (permalink / raw) To: Pete Popov; +Cc: baitisj, Linux MIPS mailing list, jsun On Thu, Apr 24, 2003 at 06:54:26PM -0700, Pete Popov wrote: > On Thu, 2003-04-24 at 18:48, Jun Sun wrote: > > On Thu, Apr 24, 2003 at 01:12:11PM -0700, Pete Popov wrote: > > > > > > > Here's another question: > > > > > > > What are the goals of the AU1500 PCI auto config? Is it supposed to be a full > > > > implementation, or just enough to work with a PCI card? The reason I ask is > > > > that the DBAu1500 has only one PCI slot, so a simple implementation would > > > > normally suffice. > > > > > > > > Restated: I don't know if the PCI auto config code was designed to work with > > > > all sorts of wacky PCI devices. I don't know if the intention of the code is to > > > > support the single PCI slot present on the DbAu1500 development board, or if it > > > > is supposed to be more flexible (and complicated). > > > > > > The MIPS pci auto should work fine with a single PCI bus and it _should_ > > > be a full implementation. The code was ported from PPC some time ago, > > > but sub busses were not tested. > > > > That is not true. pciauto has been working P2P bridges pretty much since day one. > > > > Usually sub-bus not working is due to type 1 configuration not supported > > in pci ops, which is board-dependent code. > > > > I took a brief look of au1x00 pci_ops and it appears it does not support type > > 1 configuration access. See arch/mips/ddb5xxx/ddb5477/pci_ops.c for one > > example on how type 1 configuration being supported. > > There is support for type 1 accesses in > arch/mips/au1000/common/pci_ops.c. Maybe you were looking at the pb1000 > pci routine which had limited pci bus support in an fpga. Ahh, yes. That is the first config access routine I saw in the file and thus draw the conclusion. :) Jun ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-04-25 1:58 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-04-24 18:48 Au1500 PCI autoconfig issues with multiple PCI devices? Jeff Baitis 2003-04-24 19:11 ` Jun Sun 2003-04-24 19:46 ` Pete Popov 2003-04-24 20:04 ` Jeff Baitis 2003-04-24 20:12 ` Pete Popov 2003-04-25 1:48 ` Jun Sun 2003-04-25 1:54 ` Pete Popov 2003-04-25 1:58 ` Jun Sun
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox