Last updated: Tue Jun 20 11:35:44 EDT 2006
It is included in Linux kernel 2.6.17 (since 2.6.17-rc1). In order for it to work on my HP dv1000 notebook, I require this command in my startup scripts:
# setpci -s 02:09.3 4c.b=02
02:09.0 CardBus bridge: Texas Instruments PCI6411,6421,6611,6621,7411,7421,7611,7621 Cardbus Controller
02:09.2 FireWire (IEEE 1394): Texas Instruments PCI7411,7421,7611,7621 Firewire Controller
02:09.3 Unknown mass storage controller: Texas Instruments PCI6411,6421,6611,6621,7411,7421,7611,7621 Flash Media Controller
02:09.4 Class 0805: Texas Instruments PCI6411,6421,6611,6621,7411,7421,7611,7621 SD Host Controller
# setpci -s 02:09.3 4c.b=02
This command _disables_ the SD support in TI's "FlashMedia" device, which reverts control of the SD socket to the "SD-Host Controller", for which the above sdhci driver works.
It was merged in 2.6.17-rc1, and also worked for me when backported to 2.6.16. This will give you read/write access (albeit quite slow, < 500 kB/s) to SD cards (and maybe MMC?) only. This will not work for Memory Stick, XD, or SM.
The rest of this page is now to be considered obsolete. Thanks for all the fish.
# modinfo tifm.ko license: GPL parmtype: major_num:int vermagic: 220.127.116.11 preempt PENTIUMM gcc-3.3 depends: alias: pci:v0000104Cd0000AC8Fsv*sd*bc*sc*i* alias: pci:v0000104Cd00008033sv*sd*bc*sc*i*
By this rationale, we ought to be able to demand the source from TI.
NOTE: I don't know anything about getting this binary driver to actually work with anything other than an ancient 18.104.22.168 kernel (and I haven't even tried that, actually), so please stop asking! I did not write it, I don't know who did. I know nothing about it. I can't help you. If you're feeling brave, and want to teke a look at it, feel free.
For the moment, additional dumps of the memory range with SmartMedia, xD, MS, MSPro, MSPro/Duo cards inserted would be helpful.
Step 1: I expect to have something that will at least detect when a card is inserted or removed and output a message to syslog.
Step 2: Read card capacity and scan for a partition table.
Step 3: Add real block-device support to read/write the cards!
I'm not sure right now whether it should try to hook into the IDE layer (like PCMCIA cards) or into the SCSI layer (like USB mass-storage), or if a new type of block device should be exposed (like /dev/flash0 ?)
lspci: 02:09.3 Unknown mass storage controller: Texas Instruments PCI6411,6421,6611,6621,7411,7421,7611,7621 Flash Media Controller Subsystem: Hewlett-Packard Company Pavilion dv1000 notebook Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (1750ns min, 1000ns max), Cache Line Size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e0204000 (32-bit, non-prefetchable) [size=8K] Capabilities:  Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- /proc/iomem: e0204000-e0205fff : 0000:02:09.3
The TI docs seem to only describe the PCI configuration interface, and not the actual API for the device. Hence, this project to try to figure it out.
Dumps were taken with a simple script, the core part of which is:
#!/bin/sh DEV=0000:02:09.3 RES=0 FILE=/sys/bus/pci/devices/$DEV/resource$RES LEN=0x2000 mmapr -b $FILE 0 $LEN \ | recode /4321-permutation \ | xxd >fmdumpNative PCI byte order is little-endian, so in order to read the dumps without losing sanity, I run them through a byte-swap operation (recode).
0x0000 0000 8033 0000 2577 0000 0000 0000 0000
0x0400 "SKT0" (?) 0x0800 "SKT1" (?) 0x0c00 "SKT2" (MemoryStick (and variants)) 0x1000 "SKT3" (SD & MMS(+))
Socket name as "SKT0", "SKT1", "SKT2", or "SKT3"
ALL sockets seem to get this bit set to 0 when no card is inserted and set to 1 when ANY card is inserted.
A socket seems to have this bit set when a card of the correct type for this socket is inserted.
Unknown data block. All zeroes when no card is inserted, and filled with unknown data when a card is inserted. This block does not change upon repeated insertions of a card, but was noted to change slightly after a reboot. It's clear that this block does not provide any specific details of the card that is inserted.
0x1400 - 0x2000
Socket 2 data block is filled when a MemoryStick/Duo card is inserted *and presumably all MemoryStick variants).
The data block for Socket 2 does NOT change between a '32MB MS/Duo' and a '128MB MS/Duo w/MagicGate'.
Socket 3 data block is filled when a SecureDigital or MMC card is inserted.
Changing the position of the write-protect switch on the SD does NOT change the contents of the data block.
The data block for Socket 3 does NOT change between a '256MB SD' and a '1GB MMC(+)'.
I was hoping the data block would reveal some basic information about the card that was inserted (capacity at least), but the above observations seem to deny that assumption.
File header: tifm21.hdr
Disassembled by PEDUMP: tifm21_pedump.asm
Disassembled by PE Explorer: tifm21_peexplorer.asm (Better)
Seems that TI went out of their way to obfuscate all of the original debug support in the driver by changing all the debug-related strings into the generic string "TI Msg", but left all the debug calls in place! Dumb. Still, there's some information to be gleamed from the assembly, but x86 assembly is not my forté, so I'm struggling through it.
The subroutine at SUB_L00021BE0 seemes curiously interesting. Instict tells me something in there might tell me how to enable interrupts on the device. Now I just have to wrap my head around it...
To test it out, just do:
(The firmware loader described here is not required for the 6xx1,7xx1 series chips. The UltraMedia interface works out-of-the-box, and is not related to this project of trying to get the FlashMedia interface working.)