Steve Tell
2017-07-13 02:21:25 UTC
Attached is a patch in three parts - or three seperate patches -
broken out for clarity.
0001-new-cable-driver-FTDI-FT422.patch
0002-documentation-adding-a-new-cable-driver.patch
0003-feature-accept-TRST-and-RESET-bit-definitions-on-com.patch
1. A new cable driver entry for the FTDI FT4232H. Why build a custom
test rig with a 4232H instead of a 2232H? So you can use the two MPSSE
channels for jtag and stuff while using the other two channels for
bit-bang and serial functions. This is a rather simple driver.
2. A start on documention on adding new cable drivers. Mainly, this new
text file lists the several places that need updating when a new driver
is added. It uses the FT4232H as an example in a few places, but
otherwise stands alone and could be applied independently of (1).
3. This is ther more interesting one. It requires patch 1 above. It
extends the cable command to parse additional parameter options
TRST=<number> and RESET=<number>. Then it uses those parameters in the
FT4232H driver to configure control of those functions (from the "pod"
command) with the indicated GPIO bits on the FTDI chip. This allows a
cable (commercial or homebrew) that needs those functions to be
controlled without writing a whole new special-purpose driver.
This builds on the syntax accepted by "cable gpio" for the TDO, TDI, TCK,
and TMS functions. Of course, those basic jtag pins can't be
reprogrammed on an FTDI device. Note that the "wiggler" driver uses a
completely different syntax for mapping pins to functions.
Future work: supporting TRST and RESET in the same manner on the FT2232(H)
and GPIO drivers.
Of course specifying random bit numbers could cause hardware conflicts,
but we already have the warning "UrJTAG may damage your hardware."
broken out for clarity.
0001-new-cable-driver-FTDI-FT422.patch
0002-documentation-adding-a-new-cable-driver.patch
0003-feature-accept-TRST-and-RESET-bit-definitions-on-com.patch
1. A new cable driver entry for the FTDI FT4232H. Why build a custom
test rig with a 4232H instead of a 2232H? So you can use the two MPSSE
channels for jtag and stuff while using the other two channels for
bit-bang and serial functions. This is a rather simple driver.
2. A start on documention on adding new cable drivers. Mainly, this new
text file lists the several places that need updating when a new driver
is added. It uses the FT4232H as an example in a few places, but
otherwise stands alone and could be applied independently of (1).
3. This is ther more interesting one. It requires patch 1 above. It
extends the cable command to parse additional parameter options
TRST=<number> and RESET=<number>. Then it uses those parameters in the
FT4232H driver to configure control of those functions (from the "pod"
command) with the indicated GPIO bits on the FTDI chip. This allows a
cable (commercial or homebrew) that needs those functions to be
controlled without writing a whole new special-purpose driver.
This builds on the syntax accepted by "cable gpio" for the TDO, TDI, TCK,
and TMS functions. Of course, those basic jtag pins can't be
reprogrammed on an FTDI device. Note that the "wiggler" driver uses a
completely different syntax for mapping pins to functions.
Future work: supporting TRST and RESET in the same manner on the FT2232(H)
and GPIO drivers.
Of course specifying random bit numbers could cause hardware conflicts,
but we already have the warning "UrJTAG may damage your hardware."