[This long message is meant to capture what I've learned about PCMCIA. Corrections are very welcome.]
I'm trying to get a PCMCIA card working on my HP Pavilion zv5000z (AMD Athlon 64) notebook running Fedora Core 3 x86-64. Note: PCMCIA (16-bit, old) is different from CardBus (32-bit, newer). The cards look the same, but the "plumbing" is different and the fixes to get each working on our notebook are different. I got CardBus working on my notebook some time ago. The PCMCIA cards that I have are: - Adaptec SlimSCSI APA-1460A - Global Village 56Kbps modem model A956 - Targus Pocket Modem 56K V.90 #PA560 [CF modem in a CF to PCMCIA holder] Windows XP finds and installs drivers for each of these but has problems with the SCSI adapter. See the rather unhelpful http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c00269105 Windows XP claims that there is a conflict for the card's I/O port range 0x0340-0x035f. Unfortunately it does not say what conflicts (contrary to their trouble shooting documentation. Besides, I think that a workaround should be possible (explained later). Some interesting links about PCMCIA for our notebooks under Linux: Ted Kisner's page. Look for "config.opt". Gus referenced this page a few times. Hard to find since he didn't specify the link and misspelled the author's name. http://cmb.phys.cwru.edu/kisner/linux/compaq-r3000/ List's Wiki page, based on Ken Hughes' work: http://prinsig.se/weekee/index.php/PCMCIA_%28hw%29 Theussl's page: http://www.triumf.ca/people/theussl/r3310/components/pcmcia.html Linux PCMCIA Programmer's Guide: http://pcmcia-cs.sourceforge.net/ftp/doc/PCMCIA-PROG.html The summary is that the default entries in /etc/pcmcia/config.opts don't work for our machines. Tom Kisner uses: include port 0x100-0x4ff + include port 0x800-0x8ff include port 0xc00-0xcff + include port 0x3000-0x7fff + include memory 0xe0100000-0xe17fffff include memory 0xc0000-0xfffff include memory 0xa0000000-0xa0ffffff include memory 0x60000000-0x60ffffff # Extra port range for IBM Token Ring include port 0xa00-0xaff He didn't say which were original and which were his additions. I marked entries that are not in my Fedora Core 3's vanilla config.opts with "+". Ken Hughes says for the 32-bit Athlon, use: include port 0x3000-0x7fff, memory 0xe8100000-0xe97fffff and for a 64-bit, perhaps: include port 0x3000-0x7fff, memory 0xe0100000-0xe17fffff Lukas Theussl recommends adding: include port 0x4000-0x6fff, memory 0xe8200000-0xe93ff000 based on what lspci said about the CardBus bridge. I don't think that PCMCIA cards are behind the CardBus bridges (there are two). And my lspci output doesn't match these numbers anyway. Lukas has a 32-bit CPU machine -- this may explain the difference. Ken also states that you may have to prevent probing -- add the following to /etc/rc.d/rc.pcmcia: CORE_OPTS="probe_io=0" In Fedora Core 3, the file to modify is /etc/sysconfig/pcmcia Comments within FC3's /etc/rc.d/init.d/pcmcia suggest that the file to modify in Debian is /etc/pcmcia.conf Apparently, these numbers are found from lspci -v output. Here's an extract from my system's lspci output that seems to match what Ken recommends for 64-bit systems and part of what Tom recommends. I'm not sure how to pick the right bridge, but this looks to be it. 00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=0a, sec-latency=128 I/O behind bridge: 00003000-00007fff Memory behind bridge: e0100000-e17fffff I see nothing in lspci output that explains the ports 0x800-0x8ff that Tom recommends. I think that the only memory and port ranges that should be included are exactly those behind this PCI bridge. FYI, here are the lspci entries for the two CardBus bridges. Not relevant for PCMCIA. 02:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) Subsystem: Hewlett-Packard Company: Unknown device 006d Flags: bus master, medium devsel, latency 168, IRQ 209 Memory at e0106000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 Memory window 0: e0200000-e03ff000 (prefetchable) Memory window 1: e0400000-e05ff000 I/O window 0: 00004000-000040ff I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 02:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) Subsystem: Hewlett-Packard Company: Unknown device 006d Flags: bus master, medium devsel, latency 168, IRQ 185 Memory at e0107000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176 Memory window 0: e1000000-e13ff000 (prefetchable) Memory window 1: e0c00000-e0fff000 I/O window 0: 00006000-00006fff I/O window 1: 00005000-00005fff 16-bit legacy interface ports at 0001 Does anyone know the difference between these two bridges? I would have guessed that there was one per card socket, but there is only one socket. Perhaps one is used for the funny flash card readers that we cannot get working under Linux. ================ testing vanilla Fedora Core 3 config.opt Without making any changes to config.opts, I get the following message when plugging in a PCMCIA card: cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xfffff cs: memory probe 0x60000000-0x60ffffff: excluding 0x60000000-0x60ffffff cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa0ffffff cs: unable to map card memory! cs: unable to map card memory! cs: unable to map card memory! cs: unable to map card memory! 2.6. kernels use pcmciamtd instead of memory_cs.c and do not require special MTD handling any more. ================ testing with Kisner's changes to config.opt cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xfffff cs: memory probe 0x60000000-0x60ffffff: excluding 0x60000000-0x60ffffff cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa0ffffff cs: memory probe 0xe0100000-0xe17fffff: excluding 0xe0100000-0xe06bffff 0xe0b10000-0xe151ffff ttyS14 at I/O 0x33f8 (irq = 209) is a 16550A The modem card was recognized. According to dump_cis(8), the I/O space for this card looks like this: io 0x03f8-0x03ff [lines=10] [8bit] [range] I *think* [lines=10] means that only the low-order 10 bits of the I/O address is decoded by the card. So you can freely add any multiple of 1024 (== 0x400) to the address and the card will still respond. So the I/O ports could be 0x33f8-0x33ff. My SCSI card's dump_cis output is: dev_info NULL 0ns, 512b attr_dev_info ROM 200ns, 512b vers_1 4.1, "Adaptec, Inc.", "APA-1460 SCSI Host Adapter", "Version 0.01" manfid 0x012f, 0x0002 config base 0x2000 mask 0x0001 last_index 0x08 cftable_entry 0x09 [default] Vcc Vnom 5V Istatic 60mA Idown 100mA io 0x0340-0x035f [lines=10] [16bit] [range] irq mask 0x1e00 [level] cftable_entry 0x08 io 0x0140-0x015f [lines=10] [16bit] [range] If I'm right about [lines=10], I see no reason that the I/O ports for this card could not be assigned to ports 0x3340-0x335f. Background info (mostly from section 2.2 of Linux PCMCIA Programmer's Guide): - according to /etc/pcmcia/config.opts on FC3, it has not effect on CardBus "with the kernel PCMCIA subsystem" - pcmcia memory addresses can be mapped by bridges. So addresses are not fixed by the card. The "include memory" directive declares these bridge-specific windows. It looks as if our PCMCIA bridge only has one window, even though 2.2 says that all supported controllers support at least 4 independent memory windows. => I deduce that there should be no "include memory" directives except for 0xe0100000-0xe17fffff - pcmcia I/O port addresses are not mapped by bridges, they are passed straight through. On our machine, it appears that there is one big I/O window, 0x3000-0x7fff. Even though 2.2 says that all supported controllers support at least two I/O windows. Although I/O port addresses are not mapped, most PCMCIA cards seem to ignore some number of high-order port address bits. So this means that you can treat them as if they had any address that matches only on the low-order bits. See the modem example above. In effect, this allows a form of mapping: if the motherboard has a built-in device with, say, port 0x340 and the PCMCIA card wants that port too, 0x3340 can be used for the card's port (assuming that the card ignores the top 4 bits of the 16-bit port address). => I deduce that there should be no "include port" directives except for 0x3000-0x7fff. => It isn't obvious to me why CORE_OPTS="probe_io=0" would be needed I would expect that the I/O window assigned to the bridge ought to be for its exclusive use. _______________________________________________ LinuxR3000 mailing list [email protected] http://lists.pcxperience.com/cgi-bin/mailman/listinfo/linuxr3000 Wiki at http://prinsig.se/weekee/
