I am working with a custom PPC based board and I'm trying to get the PCMCIA system working. I'm using a Ricoh PCI-Cardbus bridge with a Cisco 350 16-bit PCMCIA client card. I'm able to access Attribute memory fine - I can read the card's CIS, but I cannot access IO Memory.
I've hooked up the PC Card bus adapter to a logic analyzer (soldered wires on the back of the PC Card connector) and I'm not seeing the proper control signals coming across the bus. The control signals show that the bridge is still operating in Memory-only mode. The control signals I'm looking at are IOWR#, IORD#, OE#, WE#, and REG#. According to the PCMCIA spec, this shows that its accessing attribute memory space. The signals never change when I should be accessing IO Memory.
My first assumption was that the bridge didn't get setup properly after the CIS was read. I checked the bridge registers and the bit is set that is supposed to kick it into Memory+IO mode and the lower and upper address bounds are correctly setup for the IO window, and the IO Windows enable register is correct. I can even look at the addresses being put on the PC Card bus, and they fall within range of the IO Window.
My second guess was that the lines that wire up the bridge to the PC Card bus were pulled high or low (first spin of this board). This isn't the case, because I can see the lines wiggle when the system boots and when the bridge driver is loaded.
I'd appreciate any input from anyone. If you need more info, just ask.
I'm using the PowerPC devel kernel 2.4.21-rc6, with the stand alone PCMCIA package 3.2.4, the i82365 bridge driver and the airo_cs and airo client drivers.
(David Hinds: Please see my solution below - I have seen numerous messages in these forums having the same problem, its a common problem it appears - I think we really need to change something for that - i dont have time these days, and i am also not qualified enough - otherwise i would have sent you a patch - please look into it)
I had got into (exactly) this problem some months ago - and toiled long long days to solve it. Finally i had managed to do it.
From what I remember:
I was working with a XScale Board having a memory controller and a PCI bus. I had the same Ricoh PCMCIA Controller.
The problem was two-fold in my case: The ARM platform that i was using uses 32-bit IO addresses, and all the PCMCIA drivers cs.c, ds.c, yenta, i82365, and others assume no bigger than 16-bit IO addresses. So first thing I did was to change in numerous places to allow 32-bit addresses. I also had to change the parsing logic when cardmgr reads the config file, to allow reading 32-bit addresses.
Second thing was a major problem - the Ricoh IC ALSO REQUIRES the TOP 16 bits TO BE ZERO, that means, the IC also wants only 16-bit addresses. So I changed the window mapping registers in the memory controller (which converted the addresses from the processor local bus to PCI bus) to map the appropriately long IO window in the 32-bit address space to 0x00000000 to 0x0000ffff in the PCI address space, so that the PCMCIA IC gets only 16-bit addresses.
And you know what, it worked wonderfully.
I, feel with all probability that you will also have to do exactly what I wrote above. The only difference between you and me is that I had to spend really long days/nights (for weeks) on this, and you are directly getting the solution. ;-)
Try it out, and let the list know. If I am not clear on something above, ask.
Hope this helps.
(Forgive the arrogant tone in my message above - I am very sleepy at the moment)
Ahh I see, excellent diagnosis. I think this is what may be wrong with my setup as well.
My PCI IO Window is from 0xf400_0000 to - 0xf400_ffff, so for anything to even reach the Ricoh, it needs to be within this range. And as you said, looking at the IO window range programmed into the Ricoh, it is only 16 bit values. And since the Ricoh requires the upper 16 bits to be zeros, I'm going to have to clear them at some point before they reach the Ricoh.
I'm going to try and avoid modifying all of the pcmcia-cs files to use 32-bit addresses by doing something similar to what you did with your memory controller. I going to hack the PCI controller to look at the local bus for addresses coming in that are in the upper 64 bytes of the PCI IO memory range, 0xf400_ffbf -0xf400_ffff. If they fall in here then put a 16-bit address on the PCI bus that corresponds with the values that I have programmed into the Ricoh for the IO window.
Since the outw macros and friends automatically add _IO_BASE (_IO_BASE = 0xf400_0000 for me) I'll be able to reach the entire 64MB PCI IO window using the 16-bit addresses that pcmcia-cs uses. I'm just choosing the upper range be cause it is away from my other devices.
Besides this being an ugly hack, does anyone see a problem with this?
Thanks again Gaurang.
What do you think of this problem Dave?
I would recommend sticking to the method I mentioned.
Modifying the PCMCIA drivers to support 32-bit IO addresses is a rather trivial task - you only need to modify the data type of the IO address, and remove the checks that the drivers make to ensure that the IO addresses are of 16-bits.
However, if you know what you are doing, then you can try going ahead.
It's a tricky problem for me to figure out because I've never worked on a platform that had it. I'm sure that if you come up with a reasonable kernel patch it would be accepted.
Is there any reason why, on these platforms, linux should not map the entire PCI IO space so that _IO_BASE corresponds to PCI IO address 0? I had thought that various other PCI devices only support 16-bit IO addresses, so PCMCIA should not be the only such issue? Or is the 16-bit IO address limitation very unusual?
Good point about other PCI devices using 16-bit IO addresses. I'm not sure if pcmcia-cs is the place to solve this problem. I think it would need to be platform specific. In my case I fixed this problem outside of the pcmcia code - my PCI controller has an outbound address translation window. I mapped 512 KB of IO at _IO_BASE so that the PCI controller puts addresses starting at 0 on the bus. Everythign looks ok so far, but I haven't tested it with another wireless device yet.
The only advantages I can see of alterinig the pcmcia-cs code to support 32-bit addresses would be to allow more flexibility as to where in PCI IO space you would like to place your 16-bit IO. As of now, you can only reach 2^16 = 64KB above _IO_BASE.
Many thanks to Gaurang for the heads up on this problem. Rest assured that your weeks of toiling has helped others.
I found that the PCI controller on the MPC8250 I'm using supports inbound and outbound address translation, so I'm going to try to translate the address range available to me from _IO_BASE + the port address. Trying this now...
That flexibility is REQUIRED. In my system, even after subtracting IO_BASE, my addresses were 32-bit.
So I think either PCMCIA subsystem should stop enforcing 16-bit IO addresses completely, or should provide a flag for controlling enforcement while enforcing it for PC Platform.
The rest of the adjustments like the Memory Controller Mapping etc should be done in platform-specific ports - so pcmcia should not have to worry abt that.
And as far as helping is considered, welcome. But this is just a small thing, I cant even imagine how many million hours David must have spent developing the whole pcmcia system, or other developers developing the kernel and other open source software. The basic principle of open source is giving a shoulder to others to stand on - I am happy that my effort is useful to others. :)
We are using PCI1520 which is sitting on PCI Bus 1 of Marvell System controller to interface compactflash card.
Below is our configuration:
Status Command reg(0x04) = 0xA100003
CardBus socket/ExCA base address(0x10) = 0xF4220000
CardBus Memory base register 0(0x1c) = 0xF4230000 and
CardBus Memory limit register 0(0x20) = 0xF4238000
CardBus I/O base register 0(0x2c) = 0xD0000000
CardBus I/O limit register 0(0x30) = 0xD0008000
System control(0x80) = 0x8443000
So PCI1520 ExCA Registers are at: 0xF4220800 (config space offset 0x10 has the value 0xF4220000)
ExCA Config is below:
ExCA Address Window Enable Register(0x806) = 0xC1
ExCA I/O Window Control Register(0x807) = 0x22
With this configuration Card detection is happening properly and socket is powered up.
Now we are not able to map the Compactflash memory(Both Attribute and Common memory)
1.What is the significance of ExCA regs at
0x808 to 0x80F (I/O Windows)
0x836 to 0x839 (I/O Windows)
0x810 to 0x835 (Mem Windows)
0x840 to 0x844 (Mem Windows)
2.We are not sure what values to be filled in the above ExCA regs to access the compactFlash card memory.
Product is in release phase, we are struck up with these.
Please help on these issues.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.