FreeCalypso > hg > freecalypso-hwlab
view doc/FTDI-EEPROM-tools @ 118:b563ff1c1a2a
simtool/saverestore.c: rm unused variable
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Thu, 28 Jan 2021 04:11:28 +0000 |
parents | 0514e3520be3 |
children | df4bf4e06221 |
line wrap: on
line source
Mother Mychaela has developed a set of Linux command line tools for manipulating configuration EEPROMs that are attached to FT2232x devices and accessed in-band via USB. This document describes these tools. Supported FTDI chips and EEPROMs ================================ The present tools work with 93C46, 93C56 and 93C66 EEPROMs attached behind FT2232x dual-channel UART/FIFO/MPSSE/etc chips, both FT2232C/D and FT2232H. We can read these EEPROMs for examination or backup, and we can program them with new bits, either restoring a previously saved backup or creating a new from-scratch configuration. These EEPROM configurations (which we can save, restore or create from scratch) set the USB VID:PID and the textual strings naming the manufacturer, the product model and an optional serial number, select whether each FT2232x channel will come up in the default UART mode or one of the other EEPROM-configurable modes (245 FIFO, CPU-style FIFO or fast opto-isolated serial), and allow a few other obscure chip settings to be tweaked. Some work has also been done toward the goal of being able to program the internal EEPROM in FT232R chips (a very popular single-channel USB to UART converter needing no external components), but this work should be considered experimental: the tools appear to work on an UB232R module from Digi-Key (presumably containing a genuine FT232RQ chip) and on a no-name FT232RL adapter where the chip is uncertain, but because we have no real production use case yet, we are not ready to truly vouch for FT232R support. More generally: * our fteeprom-read tool should be able to read out the EEPROM content from just about any FTDI chip; * our fteeprom-prog tool should be able to program a user-supplied set of bits into any FTDI+EEPROM combo where the EEPROM is a separate chip, or into FT232R internal EEPROM - but it most likely won't work for newer FT-X chips; * if the goal is to generate a new EEPROM config from scratch, as opposed to restoring a saved backup, we currently have generators only for FT2232C/D, for FT2232H and for FT232R, with the last one considered experimental and not proven. libftdi dependency ================== We use libftdi (which is in turn layered on libusb) to issue the special USB control pipe commands to FTDI chips which are needed to read and write their EEPROMs. We use old-style libftdi-0.x (-lftdi on the link line) as opposed to libftdi1 (-lftdi1) because the new versions took away the ability to write to the EEPROM directly with ftdi_write_eeprom_location() calls, forcing users to go through libftdi1's own EEPROM smarts, which we don't want to do - our tools are all about more direct user empowerment at the lowest level. Selecting the device to operate on ================================== Our fteeprom-read, fteeprom-prog and fteeprom-erase tools take a device selector argument, selecting the device to operate on. This required argument is the string to be passed to the ftdi_usb_open_string() function in libftdi, allowing the device to be operated on to be selected in one of several ways. Copying from libftdi documentation, the available formats are: d:<devicenode> - path of bus and device-node (e.g. "003/001") within usb device tree (usually at /proc/bus/usb/) i:<vendor>:<product> - first device with given vendor and product id, ids can be decimal, octal (preceded by "0") or hex (preceded by "0x") i:<vendor>:<product>:<index> - as above with index being the number of the device (starting with 0) if there are more than one s:<vendor>:<product>:<serial> - first device with given vendor id, product id and serial string If you have only one FTDI device connected to your PC or laptop at the time of your EEPROM manipulation session (generally a good idea to avoid hitting the wrong device by mistake) and if that FTDI device has some sensible starting USB VID:PID (either from the previous EEPROM config or the chip's sans-EEPROM default) that doesn't clash with anything else, then the i: form will probably be the most convenient, e.g.: i:0x0403:0x6001 for single-channel FT232x devices running with the default ID i:0x0403:0x6010 for dual-channel FT2232x devices running with the default ID i:0x0403:0xPPPP for custom PIDs assigned out of FTDI's VID range i:0xVVVV:0xPPPP for totally custom USB IDs Or if the current device config is totally hosed (the EEPROM has a passing checksum, but sets some completely bogus USB ID), then the d: form will probably be required for recovery. Reading the EEPROM ================== The basic EEPROM read command is as follows: fteeprom-read <device-selector> See the previous section for the device selector argument. In this default form the tool will read the first 64 EEPROM words, which is appropriate for 93C46 external EEPROMs or for the internal 1024-bit EEPROM in the FT232R chip. However, if you are working with an FT2232x board with an external EEPROM and that EEPROM is of a larger variety (93C56 or 93C66), this basic form with give you an incomplete (truncated) read, and you will need one of the following extended forms to read the complete EEPROM: fteeprom-read -b <device-selector> -- read 128 EEPROM words (93C56) fteeprom-read -B <device-selector> -- read 256 EEPROM words (93C66) (If you use one of the extended forms on a smaller EEPROM, you will get 2 or 4 copies of the same bits.) The output of fteeprom-read is in the same format as the input to fteeprom-prog, thus you can redirect the output to a file and get a restorable backup copy of your EEPROM. It also needs to be noted that if the FTDI device has the kernel's ftdi_sio driver attached to it (ttyUSB device present) when you run fteeprom-read (same for fteeprom-prog and fteeprom-erase), the act of running any of our EEPROM tools will cause it to unbind, i.e., the ttyUSB device will disappear. If the device being operated on is a dual-channel FT2232x, then only the ttyUSB device corresponding to Channel A will disappear, while the Channel B ttyUSB device will stay. Programming the EEPROM ====================== In terms of the primitives provided over USB, writing to EEPROMs sitting behind FTDI chips is accomplished by writing one 16-bit word at a time: the SIO_WRITE_EEPROM_REQUEST command writes a user-supplied word at a user-supplied EEPROM address. However, our fteeprom-prog tool currently supports only writing complete EEPROMs (64 or 128 or 256 16-bit words starting at address 0) and we do not currently provide any kind of "random access write" utility; the primary reason for this design decision is practical usefulness: FTDI's EEPROM structure includes a checksum over the first 64 words for 1024-bit EEPROMs or over the first 128 words for larger ones, and if this checksum fails to match, the entire structure is deemed to be invalid - hence there is no practical use case for selectively rewriting individual words. The only exception may be with 93C66 EEPROMs: on these giants only the first half would be subject to the checksum, and the second half could be used arbitrarily. However, we have not yet encountered any boards out in the wild with such big EEPROMs, and we have no plans to use such in any of our own hardware designs either, hence there is no business case at the present moment to develop tooling support for them. There are two primary modes of usage for our fteeprom-prog tool: restoring a saved EEPROM backup or writing a new EEPROM config which you generate yourself. To restore a saved EEPROM backup, run the tool as follows: fteeprom-prog <device-selector> <eeprom-image-file> To program a new EEPROM config of your own, run a pipeline of this form: <generator-tool> | fteeprom-prog <device-selector> fteeprom-prog reads the EEPROM image from stdin if no image file is named on the command line; the image format is the same in both cases, and the length of this EEPROM image tells the tool how many words need to be programmed - there are no -b or -B options to fteeprom-prog. Generator tools =============== Unfortunately FTDI never documented the format of their EEPROM configuration structure - apparently they consider it a proprietary trade secret just like the wire protocol spoken over USB between their chips and their closed-source proprietary drivers. All FOSS community support for these chips is based on reverse engineering, and that includes the EEPROM format. The present suite of tools includes ftee-gen2232c and ftee-gen2232h EEPROM image generators, meant for use with FT2232C/D and FT2232H chips, respectively. These tools are based on the knowledge extracted from other (pre-existing) community tools, primarily the EEPROM config code built into various libftdi versions - we haven't done any FTDI RE of our own, instead the goal of this project has been to create a set of tools that are better fit for production use. Our ftee-gen2232c and ftee-gen2232h tools are invoked as follows: ftee-gen2232[ch] [-b|-B] <config-file> [serial-num] The output of these generator tools is meant to be piped directly into fteeprom-prog. The philosophy of which settings are given in the config file vs. which ones are given on the command line reflects configuration management and factory production line operations. In the envisioned usage there would be a config file for each product, giving the USB VID:PID, textual manufacturer and product ID strings and possibly other config settings which need to be changed from the defaults, but the optional serial number string is given on the command line because it would be different for each individual unit being programmed. The EEPROM size selection is also made on the command line, so that the same config can be programmed into a smaller EEPROM or a bigger one. By default our tools generate an image suitable for a 93C46 EEPROM: the generated image is 64 words long, with a checksum in word 63, and the EEPROM type byte in FTDI's structure is set to 0x46. Running with -b produces an image for a 93C56 EEPROM: the EEPROM type byte is set to 0x56, and the checksum-covered image length is extended to 128 words. Finally, -B sets things up for a 93C66 EEPROM: the EEPROM type byte is set to 0x66, but the generated checksum-covered image is still 128 words long just like with -b, as that is what FT2232x chips apparently expect. I said "apparently" because I don't have any FT2232x hardware with 93C66 EEPROMs and I don't plan on acquiring or building any, hence this minimal 93C66 support is completely untested - use at your own risk. It also needs to be noted that with our current RE-based understanding of FTDI's undocumented EEPROM structure, using a bigger EEPROM does NOT provide more room for strings: all that happens with -b and -B options is that a gap of 64 unused EEPROM words is inserted between the end of the fixed structure and the beginning of strings. The exact same arrangement has been observed in all 93C56 EEPROM images found in the wild, presumably produced with FTDI's official tools, including FTDI's own USB-COM232-PLUS2 board - thus it is not clear at all if FT2232x chips actually support longer strings with bigger EEPROMs, and if not, what does one need a bigger EEPROM for... For the format of config files read by our ftee-gen2232[ch] tools and what settings can be tweaked, read the source code. Erasing the EEPROM (making it blank) ==================================== If you are playing with a "generic" FT2232x breakout board that is made for tinkering, as opposed to a more finished product, such boards are typically shipped with their EEPROMs completely blank. In that case restoring the EEPROM to its "pristine" state after playing around would mean erasing it, i.e., bringing it into a blank (all ones) state. FT2232x chips provide two ways to do so: one can explicitly write 0xFFFF into each individual EEPROM word with SIO_WRITE_EEPROM_REQUEST, or one can send a SIO_ERASE_EEPROM_REQUEST command to the chip, and the chip then erases the entire EEPROM. But we don't know how the latter SIO_ERASE_EEPROM_REQUEST operation is implemented by FT2232x chips: does the FT2232x chip go through and erase each word individually, or does it issue an "erase full chip" opcode to the serial EEPROM? If the latter, then according to some EEPROM datasheets that operation may not work if the EEPROM is powered from a 3.3V rail rather than the full USB 5V - may be an issue in FT2232H-based designs. In any case our tools provide both ways. To perform the "automatic full chip erase" operation, run the following command: fteeprom-erase <device-selector> To blank the EEPROM by writing 0xFFFF into each word, run one of the following pipelines: ftee-mkblank | fteeprom-prog <device-selector> -- blank a 93C46 EEPROM ftee-mkblank -b | fteeprom-prog <device-selector> -- blank a 93C56 EEPROM ftee-mkblank -B | fteeprom-prog <device-selector> -- blank a 93C66 EEPROM