If there is no ISA or PCI bus and communication between the PCMCIA interface and CPU is I/O mapped, then which piece of the pcmcia-cs source code will require modifications to make these stand-alone pcmcia modules to work for such architecture, thereby by-passing the PCI/ISA dependencies? Any help in response will be greatly acknowledged.
I think the code already works on architectures with no ISA or PCI bus. Can you be more specific about what you're trying to do?
I am looking to port pcmcia based wlan driver (prism chipset) on a custom hardware. Pcmcia hardware conforms to PCMCIA/PC CARD 2.1 standard. Pcmcia host controller is connected with the CPU via a custom bus which is a non-ISA/PCI bus. Pcmcia host controller is programmed using memory mapped 32-bit registers. Pcmcia interrupts, attribute, common and iobase memories are accessible through these registers. I am looking for some integration points in pcmcia-cs, where I can specify the memory addresses of pcmcia registers and also by-pass the ISA and PCI bus code. Since I want to port the wlan driver (prism chipset) for now, therefore, I may not be needing all the source files in the pcmcia-cs package. Keeping in view my requirement, I guess that I need to do following;
> Initialise the pcmcia host controller
> Specify the memory addresses of attribute, common and iobase memory in pcmcia-cs
> Modify the pcmcia-cs source to talk to the pcmcia hardware using its memory mapped registers directly
As the pcmcia interface is limited to wlan card support, I guess that I will need the 'pcmcia_core', 'cs' and 'ds' modules, cardmgr and cardctl utilities ONLY. Ultimately, pcmcia-cs will load the appropriate wlan card driver module (prism chipset based wlan driver from linux-wlan).
Other solution in my mind is to modify the chipset specific wlan card driver code and make it use the pcmcia host controller registers directly (as this will by-pass the pcmcia-cs) but I am not sure if this is that much simple.
Is my understanding okay? I would be happy to have your thoughts. I apologies in case my post is a redundant one.
You should probably take a look at the socket drivers for embedded systems in the 2.6 kernel tree (i.e. the ARM drivers or the HD64465 driver) for example code. You should not need to modify any of the core pcmcia-cs modules to do this. The core code already supports systems that memory map the PCMCIA address spaces at fixed addresses.
Thank you for giving pointers of example code. I have following points to ask.
(1) I am writing the socket driver layer for a different kind of hardware in which the card attribute, common and i/o are not completely mapped into the host memory space. A common memory block of 1024 bytes (in host memory space) is used to access the card memory. Hence, Card memory is accessed in chunks of 1024 bytes. For 64MBytes of card memory, there would be
(64MBytes/1024Bytes = 64K) chunks of 1024 bytes in card memory. 16-bit register is used to specify the chunk base address and doing i/o in the host common memory block of 1024 bytes will actually be performed in the card memory chunk of 1024 bytes (depending on the base address). In this situation, how should I set the memory map in SetMemMap() of the Socket Services?
(2) I am using 2.4 kernel, will the pcmcia driver in 2.6 kernel work with 2.4 kernel without any problem?
(3) Can pcmcia source in 2.6 kernel be built as modules for 2.4 kernel? Will it work?
(4) In pcmcia-cs module for 2.4 kernel, CONFIG_VIRTUAL_BUS is used to support unusual socket architectures. How custom socket drivers are supported in 2.6 kernel pcmcia as there is no
CONFIG_VIRTUAL_BUS in 2.6 kernel pcmcia?
(5) In what manner do the APIs of pcmcia-cs modules (for 2.4 kernel) vary from the 2.6 kernel pcmcia?
(6) Version of the pcmcia driver in 2.6 kernel is 3.1.22, whereas the latest version of the pcmcia-cs modules (for 2.4 kernel) is 3.2.8. Do both these versions correspond to the same tree? If yes, then when CONFIG_VIRTUAL_BUS was introduced? version?
Is there any online chat forum for this project?
(1) If you mean that there is exactly one 1024 byte aperture for all PCMCIA memory and IO accesses, then this architecture is not currently supported by the regular socket services interface. Your only option would be to use the CONFIG_VIRTUAL_BUS setup in the 2.4 kernel drivers.
(2) No, you can't mix 2.4 and 2.6 kernel components; the kernel APIs are not compatible.
(3) No, see (2).
(4) The CONFIG_VIRTUAL_BUS capability does not exist for 2.6 kernels. It was deprecated since no one used it. It could be reintroduced if someone made a case for it being important and provided appropriate code.
Even for 2.4, CONFIG_VIRTUAL_BUS was never fully implemented. I created the infrastructure in Card Services for it, but didn't adapt any client drivers to use it, since the original intended application never materialized, and no one else showed interest.
(5) I'm afraid that the evolution of the 2.6 kernel APIs is essentially undocumented. I am not the maintainer of the 2.6 kernel code.
(6) The 2.6 kernel code is a separate branch of the tree and the version numbers have not been maintained.
The mailing list for discussion of 2.6 kernel PCMCIA development is here:
I am facing almost the similar problem. I am writing socket driver for a custom pcmcia controller. Card memory is accessed through a 256 byte device access window in the host memory. Following diagram Would help understand the situation precisely;
CPU <> PCMCIA Controller <> PCMCIA Device
PCMCIA controller is connected with the CPU through a non-standard local bus.
In case of HD64465, whole address space of device is mapped in the host memory. For example, if the driver layer request to map first 2k of attribute memory through hs_set_mem_map funtion, HD654465 simply moves the sys_start pointer to (HD64465_PCC_WINDOW + mem_base).
How can I achieve the same behavior in my case, so that Card Services can access 64MB of card memory where only 256 bytes of card memory is mapped in the host memory space.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.