pcmcia (again)

pcmcia (again)

[Jim Paris]

I've learned a bit since my question regarding PCMCIA, and haven't
gotten any answers, so here's a possibly-easier-to-answer version.

My architecture has ISA memory mapped at some high address (via
isa_slot_offset).  Turns out this isn't special; most non-x86 targets
with ISA do it (PPC, MIPS).  So, the problem seems to boil down to the
fact that the kernel's PCMCIA drivers simply don't support this (as
they assume that ISA space is absolutely addressable).

Is this true, and if so, how do you guys get PCMCIA working on MIPS?
Has anyone done it?

-jim

Re: pcmcia (again)

[Pete Popov]

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

Jim Paris wrote:
> I've learned a bit since my question regarding PCMCIA, and haven't
> gotten any answers, so here's a possibly-easier-to-answer version.
> 
> My architecture has ISA memory mapped at some high address (via
> isa_slot_offset).  Turns out this isn't special; most non-x86 targets
> with ISA do it (PPC, MIPS).  So, the problem seems to boil down to the
> fact that the kernel's PCMCIA drivers simply don't support this (as
> they assume that ISA space is absolutely addressable).
> 
> Is this true, and if so, how do you guys get PCMCIA working on MIPS?
> Has anyone done it?

Yes, I did it recently for the Alchemy Au1000 eval board, the pb1000. In fact, 
just last week I added support for the ide-cs driver which allows you to use 
flash ata cards.

The Au1000 pcmcia controller is part of the SOC. There are three windows with 
fixed addresses: one that accesses pcmcia io, another for attribute memory, and 
the last for common memory. If your pcmcia controller is not one of the ones 
that linux already supports (ie, no socket driver for it), you might encounter 
problems beyond just the ones you describe above.

There is a small patch I got from a strongarm board which adds support for fixed 
memory windows controllers.  I've attached that patch in case you need it (I 
also had to make ioaddr_t a 32 bit type).  The socket driver I wrote ioremaps 
the pcmcia io space.  I have set mips_io_port_base to 0, so now when the 
inl/inb/outl/outb etc macros are used, the "offset" that is passed to them is 
actually the ioremapped address so it's a valid address.  The IO macros in the 
mips port take the "offset" passed to them and then add mips_io_port_base.  So 
the sum of the two has to be a valid address.  The socket driver passes the 
physical addresses of the attribute and common memory to the cs driver, and 
those addresses are then ioremapped at some point.

Unfortunately the client drivers make assumptions about the pcmcia windows that 
are valid for the type of pcmcia controllers used in PCs and even some PPC SOCs, 
but they are not valid for fixed window controllers. The only client driver I 
was able to use without any modifications to it is the 3COM 589 ethernet card, 
and now the ide-cs driver.  The memory-cs driver (which is not part of the 
kernel drivers anyway) does not work for me without modifying it.

One advice, stay the hell away from Xircom cards when you're testing. Apparently 
there is no documentation for them (someone correct me if I'm wrong) so they 
work mainly (and perhaps only) on x86, since that's where they were reversed 
engineered.

Pete

[-- Attachment #2: pcmcia_fixed_io.patch --]
[-- Type: text/plain, Size: 844 bytes --]

--- stock-2.4.8/drivers/pcmcia/cs.c	Wed Jun 20 11:19:02 2001
+++ linux-mips-dev/drivers/pcmcia/cs.c	Wed Sep  5 12:51:24 2001
@@ -788,6 +788,10 @@
 	      *base, align);
 	align = 0;
     }
+    if ((s->cap.features & SS_CAP_STATIC_MAP) && s->cap.io_offset) {
+	*base = s->cap.io_offset | (*base & 0x0fff);
+	return 0;
+    }
     /* Check for an already-allocated window that must conflict with
        what was asked for.  It is a hack because it does not catch all
        potential conflicts, just the most obvious ones. */
--- stock-2.4.8/include/pcmcia/ss.h	Fri Feb 16 16:02:37 2001
+++ linux-mips-dev/include/pcmcia/ss.h	Wed Sep  5 12:25:36 2001
@@ -52,6 +52,7 @@
     u_int	features;
     u_int	irq_mask;
     u_int	map_size;
+    ioaddr_t    io_offset;
     u_char	pci_irq;
     struct pci_dev *cb_dev;
     struct bus_operations *bus;

Re: pcmcia (again)

[Jim Paris]

Thanks for your reply.

> If your pcmcia
> controller is not one of the ones that linux already supports (ie,
> no socket driver for it), you might encounter problems beyond just
> the ones you describe above.

My PCMCIA controller is an i82365-compatible VG-469.  The driver for
that works; there are some linux-vr specific modifications to it that
allow it to work with remapped interrupts.

The I/O port mapping also seems to work fine, as the controller is
detected and it has no trouble seeing when cards are inserted.

The problem comes in with cs.c; it doesn't seem to know about the
ISA memory remapping:

cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107
initializing socket 0
cs: memory probe 0x0d0000-0x0dffff: excluding 0xd0000-0xdffff
cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcffff
cs: unable to map card memory!
cs: unable to map card memory!
initializing socket 1
cs: unable to map card memory!
cs: unable to map card memory!

And, from my inspection of the code, this seems to be caused by the
fact that it assumes that if it's ISA, the memory is mapped to
absolute address 0; rsrc_mgr.c excludes those memory regions and fails
to find available ISA memory space because the kernel already has
0x000000-0xffffff allocated to system RAM.

Am I misunderstanding something here?  Is there some simple way to get
the PCMCIA driver to use isa_slot_offset when checking and
requesting memory regions?  I tried adding that offset to the
check_mem_resource, request_mem_region, and release_mem_region calls,
and changing all of the readx/writex() calls to isa_readx/isa_writex(),
but things still don't work right.

thanks,
-jim

Re: pcmcia (again)

[Pete Popov]

Jim Paris wrote:
> Thanks for your reply.
> 
> 
>>If your pcmcia
>>controller is not one of the ones that linux already supports (ie,
>>no socket driver for it), you might encounter problems beyond just
>>the ones you describe above.
>>
> 
> My PCMCIA controller is an i82365-compatible VG-469.  The driver for
> that works; there are some linux-vr specific modifications to it that
> allow it to work with remapped interrupts.
> 
> The I/O port mapping also seems to work fine, as the controller is
> detected and it has no trouble seeing when cards are inserted.
> 
> The problem comes in with cs.c; it doesn't seem to know about the
> ISA memory remapping:
> 
> cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107
> initializing socket 0
> cs: memory probe 0x0d0000-0x0dffff: excluding 0xd0000-0xdffff
> cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcffff
> cs: unable to map card memory!
> cs: unable to map card memory!
> initializing socket 1
> cs: unable to map card memory!
> cs: unable to map card memory!
> 
> And, from my inspection of the code, this seems to be caused by the
> fact that it assumes that if it's ISA, the memory is mapped to
> absolute address 0; rsrc_mgr.c excludes those memory regions and fails
> to find available ISA memory space because the kernel already has
> 0x000000-0xffffff allocated to system RAM.
> 
> Am I misunderstanding something here?  Is there some simple way to get
> the PCMCIA driver to use isa_slot_offset when checking and
> requesting memory regions?  I tried adding that offset to the
> check_mem_resource, request_mem_region, and release_mem_region calls,
> and changing all of the readx/writex() calls to isa_readx/isa_writex(),
> but things still don't work right.

Are ioport_resource.{start,end} and iomem_resource.{start,end} set correctly?
Perhaps you haven't set those up and the requests are failing.


Pete

Re: pcmcia (again)

[Jim Paris]

> > Am I misunderstanding something here?  Is there some simple way to get
> > the PCMCIA driver to use isa_slot_offset when checking and
> > requesting memory regions?  I tried adding that offset to the
> > check_mem_resource, request_mem_region, and release_mem_region calls,
> > and changing all of the readx/writex() calls to isa_readx/isa_writex(),
> > but things still don't work right.

.. 

Success!!

The main problem was that I had subtly broken the ioremap function
while trying to update the linux-vr tree to 2.4.5ish.  Doh!

A second problem is that the pcmcia drivers needed to add
isa_slot_offset when calling {check,request,release}_mem_region
-- but the readx/writex calls do _not_ need this offset added.
(So this must be handled by the ioremap.  I still don't fully
understand when or where this remapping is done, but I know it's
happening.)

And it works!

This means that I now have a working 2.4.5 kernel on my Mobilon Tripad
(aka Vadem Clio) with a functional compact flash and wireless ethernet
card.  I'm quite happy.  Now I just need to build some binaries.

Pete, thanks for your help; it pointed me in the right direction.

-jim

Re: pcmcia (again)

[Pete Popov]

Jim Paris wrote:
>>>Am I misunderstanding something here?  Is there some simple way to get
>>>the PCMCIA driver to use isa_slot_offset when checking and
>>>requesting memory regions?  I tried adding that offset to the
>>>check_mem_resource, request_mem_region, and release_mem_region calls,
>>>and changing all of the readx/writex() calls to isa_readx/isa_writex(),
>>>but things still don't work right.
>>>
> 
> .. 
> 
> Success!!
> 
> The main problem was that I had subtly broken the ioremap function
> while trying to update the linux-vr tree to 2.4.5ish.  Doh!
> 
> A second problem is that the pcmcia drivers needed to add
> isa_slot_offset when calling {check,request,release}_mem_region
> -- but the readx/writex calls do _not_ need this offset added.
> (So this must be handled by the ioremap.  I still don't fully
> understand when or where this remapping is done, but I know it's
> happening.)
> 
> And it works!
> 
> This means that I now have a working 2.4.5 kernel on my Mobilon Tripad
> (aka Vadem Clio) with a functional compact flash and wireless ethernet
> card.  I'm quite happy.  Now I just need to build some binaries.
> 
> Pete, thanks for your help; it pointed me in the right direction.
> 
Good to hear that you found the problems.  If your patch to use isa_slot_offset 
doesn't get accepted, you might want to try to figure out if there's any way to 
limit your changes to your board's specific files. That way you won't have to 
carry patches around from one kernel version to another. I think this is now the 
second mips board with pcmcia support.

BTW, I have a LE ramdisk which runs linuxrc, loads pcmcia drivers, starts 
cardmgr, and exits. The kernel then mounts the real root fs which is /dev/hda1 
in my case (pcmcia ata card).  Let me know if you need it.

Pete

Re: pcmcia (again)

[Jim Paris]

> Good to hear that you found the problems.  If your patch to use
> isa_slot_offset doesn't get accepted, you might want to try to
> figure out if there's any way to limit your changes to your board's
> specific files. That way you won't have to carry patches around from
> one kernel version to another. I think this is now the second mips
> board with pcmcia support.

My architecture is only superficially supported by the current
Linux-MIPS cvs, so coming up with a patch for that would be a bit
difficult right now.  (the current CVS appears to have some basic
support for the vr41xx processor, but that's it).  The codebase I'm
working with right now is a terrible mix of the (outdated) linux-vr
and (current) linux-MIPS trees, which means that I'm already going to
have big issues if I ever want to upgrade versions or whatnot.

I guess my current plan is to keep hacking until I get a system that
works acceptably well, and then start submitting small patches to the
linux-MIPS tree to try to incorporate all of the linux-vr-specific
stuff, which would hopefully eliminate the need for the linux-VR
tree (which is not being actively maintained anyway).

> BTW, I have a LE ramdisk which runs linuxrc, loads pcmcia drivers,
> starts cardmgr, and exits. The kernel then mounts the real root fs
> which is /dev/hda1 in my case (pcmcia ata card).  Let me know if you
> need it.

I currently have my PCMCIA drivers built into the kernel; the
kernel-based card services stuff seems to work just fine in
my case, so I don't need an initrd.  Having never dealt directly with
PCMCIA under Linux before, I didn't find this strange, but it seems
that other people find a cardmgr-free PCMCIA setup a bit strange. :)

-jim