Texas Instruments 6xx1,7xx1 FlashMedia driver for Linux

Last updated: Tue Jun 20 11:35:44 EDT 2006

Working driver for the SD Host Controller (function 4)

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:

# lspci
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.

OBSOLETE BELOW

GPL driver (without source) from TI!

# modinfo tifm.ko
license:        GPL
parmtype:       major_num:int
vermagic:       2.6.11.6 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.

ti-binary-driver.tgz

NOTE: I don't know anything about getting this binary driver to actually work with anything other than an ancient 2.6.11.6 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.

Call for help

For the moment, additional dumps of the memory range with SmartMedia, xD, MS, MSPro, MSPro/Duo cards inserted would be helpful.

Progress:

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 ?)

Device PCI configuration information

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: [44] 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

TI Docs:

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:

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 >fmdump

Analysis of the memory region:

0x0000 0000 8033 0000 2577 0000 0000 0000 0000

• 8033 is the device id for chip function 3 (flash media controller). Is this just for redundant identification and verification that the memory region is correct by using "8033" as a magic string?

0x0400 "SKT0" (?)
0x0800 "SKT1" (?)
0x0c00 "SKT2" (MemoryStick (and variants))
0x1000 "SKT3" (SD & MMS(+))

• each socket chunk (0x400 bytes):
  • offset 0x00 length 4

    Socket name as "SKT0", "SKT1", "SKT2", or "SKT3"

  • offset 0x0a bit 1 = socket power on?

    ALL sockets seem to get this bit set to 0 when no card is inserted and set to 1 when ANY card is inserted.

  • offset 0x0b bit 1 = socket occupied?

    A socket seems to have this bit set when a card of the correct type for this socket is inserted.

  • offset 0x200 length 0x200

    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

• unknown purpose (maybe nothing), always zeroes (so far)

Observations:

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.

Exploring the Windows driver

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...

Linux driver

Makefile
tifm21.c

To test it out, just do:

make
insmod ./tifm21.ko

Other Resources

http://penguin-breeder.org/kernel/#tiumfwl
(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.)