[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CardBus testers needed
On Thu, Mar 11, 2010 at 09:52:22AM +0100, Markus W Kilbinger wrote:
> >>>>> "David" == David Young <dyoung%pobox.com@localhost> writes:
> David> Please send 'pcictl pci0 dump -d 20 -f 4'.
> >> Attached:
> David> Thanks. Send pcictl output for the CardBus bridge again,
> David> too, and the host bridge.
> According to my dmesg output (excerpt):
> pci0 at mainbus0 bus 0: configuration mode 1
That is a host-PCI bridge. It bridges the host chipset (CPU, memory
controller, et cetera) to a PCI bus.
> ppb2 at pci0 dev 20 function 4: ATI Technologies SB600 PCI to PCI Bridge
> (rev. 0x00)
And that is a PCI-PCI bridge. It bridges a PCI bus to a PCI bus.
> pci3 at ppb2 bus 3
> pci3: i/o space, memory space enabled
> cbb0 at pci3 dev 5 function 0: ENE Technology CB1410 CardBus Controller
> (rev. 0x01)
Finally, we have the PCI-CardBus bridge.
There are I/O- and memory-space windows on each PCI-* bridge. They tell
which addresses are on the secondary side of the bridge. (The secondary
side is the side that is farther from the chipset. The primary side
is nearer to the chipset.) When a bridge sees a transaction address
on its primary side that is in the applicable window, it forwards the
transaction to its secondary side.
I'm concerned that your CardBus bridge's memory-mapped registers are at
Base address register at 0x10 (CardBus socket/ExCA registers)
type: 32-bit nonprefetchable memory
base: 0xcffe0000, not sized
but the PCI bridge passes only memory addresses [0xfe300000, 0xfebfffff]
to its secondary side:
base register: 0xfe30
limit register: 0xfeb0
The PCI bridge's window, [0xfe300000, 0xfebfffff], should enclose the
CardBus bridge's registers, [0xcffe0000, 0xcfffffff], but the regions do
not even overlap!
I believe that this is just the kind of misconfiguration that
PCI_ADDR_FIXUP was meant to fix.
It seems that accesses to [0xcffe0000, 0xcfffffff] could not possibly go
to the CardBus bridge. It is possible that those accesses go to RAM.
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933
Main Index |
Thread Index |