ftdi_eeprom: Add device release number support In process of firmware repairing of some FTDI-chip based device I have found that I can't get binary identical EEPROM dumps from properly working device and ftdi_eeprom --build_eeprom command because of ftdi_eeprom does not support changing of device release number (byte with addr 0x06). [TJ: Keep old behavior if release_number is not set in the config file]
eeprom handling: Add support for arbitrary user data Add two new configuration options: - user_data_addr: An integer indicating the offset where we want to put the user provided data. - user_data_file: A string indicating the filename that contains the binary data to be added. I've extended the libftdi API to store the above mentioned data inside the eeprom struct. Also extended ftdi_eeprom_build to include this data.
ftdi_eeprom: support channel configuration Previously, the channels could not be configured and were hard set to type UART and driver VCP and further to no RS485 functionality on chips with support for this feature. With the new 'chX_*' config file options the ftdi_eeprom tool is now abel to change the channel type, set the driver autoload decision (VCP od D2XX) and enable or disable RS485. The new config file options are: * ch[a,b]_type - string of: UART, FIFO, OPTO, CPU, FT1284 * ch[a,b,c,d]_vcp - bool: true for VCP, false for D2XX * ch[a,b,c,d]_rs485 - bool: true for RS485 enabled Signed-off-by: Stephan Linz <linz@li-pro.net>
ftdi_eeprom: added --device option to specify FTDI device * previously, the device could only be selected using the "vendor_id", "product_id" and "default_pid" config file options. This did not guarantee that a device could be uniquely identified (e.g. there could be multiple devices with the same VID/PID). Also this severely limited the possibilities of changing a device's VID/PID using ftdi_eeprom - this only worked if the device happened to have FTDI's VID 0x0403 and a PID equal to "default_pid". * If the --device option is omitted, ftdi_eeprom defaults to the old behaviour of using the config file options. * The order of arguments is insignificant. If multiple 'command' options (--read-eeprom, --erase-eeprom, --flash-eeprom) are given, only the last one will determine the action.
fixed ftdi_cbus_func and ftdi_cbush_func enumerations and introduced ftdi_cbusx_func * removed CBUS_BB. D2XX doesn't have it, so I don't think it's actually valid. * CBUSH_TXLED/CBUSH_RXLED had the wrong values probably because the author looked at an outdated D2XX ftdi.h These values were also wrong in various mux tables of ftdi.c resulting e.g. in confusing outputs of the eeprom.c example. * ftdi_cbush_func was extended to contain FT230X CBUS functions. However, the clock functions are different on FT-X and it is also confusing to use CBUSH constants on FT-X chips, so I introduced another enum ftdi_cbusx_func with CBUSX constants. * Added support for setting CBUS functions on FT232H and FT230X in ftdi_eeprom. To support these chips, special cbushN and cbusxN options have been introduced. Possible values of the "cbus" options now match the ftdi.h constant names. Libconfuse string lists are no longer used as option types since they do not represent enumerations but lists. * When "cbus" options are missing in ftdi_eeprom config files, keep the chip defaults as set by ftdi_eeprom_initdefaults().
ftdi_eeprom: Added config value "eeprom_type" The default eeprom size is 128 bytes - if we have a larger one, we need a way to specify the fact. Using ftdi_read_eeprom() / ftdi_eeprom_decode() to get the actual eeprom type is not an option as ftdi_eeprom_decode() would overwrite the values set by ftdi_eeprom_initdefaults() Signed-off-by: Anders Larsen <al@alarsen.net>
Completed the support for the FT4232H chip Added missing fields to the ftdi_eeprom structure and the encoding and decoding functions. The ftdi_eeprom utility forces DRIVER_VCP on and RS485 off for all channels, but this could easily be made configurable, should the need arise. Signed-off-by: Anders Larsen <al@alarsen.net>