TUMPA
I was planning on “playing” with a certain device, so I wanted some adapter which allowed me to interface with the device at a low level to facilitate the information gathering phase in the hacking process.
I wanted something to connect to UART signals, and a JTAG port and maybe something able to program SPI flash chips too; Marek Vasut suggested I should pick up something based on the FT2232H IC, after a round of research I settled on a TUMPA; it arrived some days ago.
Testing TUMPA under Linux
The TUMPA manual is more than OK, but some more specific info about linux can still be useful.
UART
The FT2232H has two serial channels (A and B), on the TUMPA only channel B is dedicated to UART communication, either as TTL signals or as a full RS-232 interface.
Using the TUMPA for a naked serial connection/console works fine, the linux ftdi_sio USB-serial driver can be used for that, the module can be loaded passing the vendor and product options to it:
$ sudo modprobe ftdi_sio vendor=0x0403 product=0x8a98
In this case two new device nodes show up, in my case they are /dev/ttyUSB0 and /dev/ttyUSB1, the latter corresponds to channel B.
Alternatively a patch to add direct support for TUMPA to ftdi_sio is available and will hopefully be added to linux-3.7, with this mechanism only one new device node shows up (/dev/ttyUSB0 here) which is mapped to channel B (channel A is reserved to JTAG/SPI1 on the TUMPA).
[ 211.848085] usb 2-2: new high-speed USB device number 3 using ehci_hcd [ 211.996305] hub 2-0:1.0: unable to enumerate USB device on port 2 [ 212.452090] usb 4-2: new full-speed USB device number 3 using ohci_hcd [ 212.652083] usb 4-2: not running at top speed; connect to a high speed hub [ 212.672078] usb 4-2: New USB device found, idVendor=0403, idProduct=8a98 [ 212.672086] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 212.672092] usb 4-2: Product: TIAO USB Multi-Protocol Adapter [ 212.672098] usb 4-2: Manufacturer: TIAO [ 212.672103] usb 4-2: SerialNumber: XXXXXXXX [ 212.770697] usbcore: registered new interface driver usbserial [ 212.771255] usbcore: registered new interface driver usbserial_generic [ 212.771835] USB Serial support registered for generic [ 212.771850] usbserial: USB Serial Driver core [ 212.791528] usbcore: registered new interface driver ftdi_sio [ 212.792885] USB Serial support registered for FTDI USB Serial Device [ 212.794682] usb 4-2: Ignoring serial port reserved for JTAG [ 212.794755] ftdi_sio 4-2:1.1: FTDI USB Serial Device converter detected [ 212.797208] usb 4-2: Detected FT2232H [ 212.797217] usb 4-2: Number of endpoints 2 [ 212.797224] usb 4-2: Endpoint 1 MaxPacketSize 64 [ 212.797229] usb 4-2: Endpoint 2 MaxPacketSize 64 [ 212.797235] usb 4-2: Setting MaxPacketSize 64 [ 212.808428] usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 212.808477] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
After connecting the interface to the target device, the serial console on the device can be accessed using minicom:
$ minicom -D /dev/ttyUSBX
SPI
I tested the SPI interface using a chip from an old motherboard I had lying around, it is a MX25L8005, I just needed to make the connections:
and use flashrom which already has support for both the TUMPA and the MX25L8005:
$ sudo flashrom -p ft2232_spi:type=tumpa,port=B -r flash.bin flashrom v0.9.6.1-r1563 on Linux 3.6.0-rc5-ao2 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found Macronix flash chip "MX25L8005" (1024 kB, SPI) on ft2232_spi. Reading flash... done.
I2C, GPIO and bit-banging
FTDI chips are quite flexible, they can operate in a mode called Multi-Protocol Synchronous Serial Engine (MPSSE) which can be used to talk to I2C devices, or to set up some chip lines as GPIO pins, or for bit banging.
I used MPSSE via libmpsse to read data off a 24C16 EEPROM, the mapping can be derived by joining the different documents about MPSSE Basics, MPSSE Commands and TUMPA manual, a table is following for convenience:
JTAG | TUMPA-jtag | FT2232H | MPSSE | I2C | ||
---|---|---|---|---|---|---|
TCK | pin9 | ADBUS0 | TCK/SK | SCK | ||
TDI | pin5 | ADBUS1 | TDI/DO | SDA | ||
TDO | pin13 | ADBUS2 | TDO/DI | SDA | ||
TMS | pin7 | ADBUS3 | TMS/CS | |||
RST | pin15 | ADBUS4 | GPIOL0 | |||
nTRST | pin3 | ADBUS5 | GPIOL1 | WP | ||
DBGRQ | pin17 | ADBUS6 | GPIOL2 | |||
RTCK | pin11 | ADBUS7 | GPIOL3 | |||
DBGACK | pin19 | ACBUS0 | GPIOH0 | |||
ACBUS1 | GPIOH1 | |||||
ACBUS2 | GPIOH2 | |||||
ACBUS3 | GPIOH3 |
And here is the final wiring to read an EEPROM via I2C:
With the GPIO mode I was also able to test a trivial circuit with a LED and a resistor and make the LED blink controlling the delay via software using libmpsse.
I don't know if MPSSE mode can be used to flash programs to PIC microcontrollers too, the PICPgm mentions a USB interface based on an FTDI chip but I didn't go deeper into the matter.
Reading the FTDI eeprom on TUMPA
The FTDI chip stores some info into an internal EEPROM, this one can be read (and flashed) using ftdi_eeprom from libftdi (NOTE: bash command line):
$ ftdi_eeprom --read-eeprom <(echo -e "vendor_id=0x0403\nproduct_id=0x8a98\nfilename=TUMPA-eeprom.bin")
The official utility to deal with the FTDI eeprom is the closed source FT_PROG.
Final words
Now that I know something more about FT2232H I think I can compare the TUMPA to simpler solutions like the basic FT2232H Mini Module:
- On the plus side, having dedicated connectors for SPI, JTAG and TTL/RS232 on the TUMPA speeds up the connections as that avoids keeping track of the pin mapping each time.
- On the other hand I note that the TUMPA does not make it easy to access all the FT2232H lines, which is limiting especially in MPSSE GPIO mode.
I will update the article when I get a chance to test the JTAG functionality.
Comments
Which drivers (kernel
Which drivers (kernel modules) should be loaded or unloaded to get it recognized as described?
my results - 3.2.0-56-generic (64-bit) show at dmesg:
Only /dev/ttyUSB0 shows up. Software such as zJTAG reporting "There are no FTDI devices installed".
Are the USB ids the TUMPA
Are the USB ids the TUMPA ones?
If so, it is OK than just
/dev/ttyUSB0
shows up: the ftdi_sio kernel driver recognized it is a TUMPA and left the port B of the FTDI chip free for JTAG usage.Maybe zJTAG doesn't know about the TUMPA USB ids, and/or you should tell it to use port B. I've never used zJTAG so I don't know how to do that, sorry.
Ciao, Antonio
Having the same problem. It
Having the same problem.
It seems that the library is not discovering valid devices (test it with the bundled examples with the library).
Did you had any luck?
Could you please upload the
Could you please upload the EEPROM contents somewhere? My TUMPA did not get configured correctly (even the product_id is different from yours) and the only thing that's working is serial. I have some XML config files for FT_Prog but FTDI does not seem to provide Linux version.
Thanks
Post new comment