[OpenOCD-devel] ft2232 and ftdi improvements

[Peter H. <pet...@gm...>]

Hi Andreas, Øyvind, Dick, Dominic, Oliver and OpenOCD developers,

please find here my findings and experience with USB and the FTDI chip,
which I like to share with you and the nice OpenOCD project.

The story starts when I switched the last month from an Wiggler based
parallel port jtag interface to an FTDI-2232H based Jtag interface. I
plugged the jtag on a Mips based OpenWRT WNDR3700 box reading out some
bytes of the flash memory. Ok, reading out data is anyway not optimized
compared to the "fast_load_image" memory write implementation and who
really need a fast read...
But anyway I was surprised about the bad read performance using the
USB-2.0 dongle with 64bit Debian Squeeze, OpenOCD 0.6.1 on a Core-2
Notebook compared to my self build Wiggler dongle.

ParPort driver:
dump_image wndr3700-uboot.test 0x1f000000 0x2000
dumped 8192 bytes in 20.888700s (0.383 KiB/s)

Original FT2232 driver:
dump_image wndr3700-uboot.test 0x1f000000 0x2000
dumped 8192 bytes in 86.300087s (0.093 KiB/s)


Because I couldn't believe what I saw, I took the "LeCroy" from the
company at work and found out the USB-In transactions were NAKed on the
USB bus, until the latency timer of the FTDI-2232H elapsed. Reducing the
timer value to 1ms doubles the performance and setting it to 0ms needs
an additional patch in the libftdi, which then allows setting a latency
value of zero for the chip. The FTDI data sheet describe it as a send
out all data collected in the read buffer immediately starting from the
next USB micro frame.
In the attached patch I used the FTDI-2232 "send immediate" command also
described in the FTDI-2232H data sheet, which needs to be simple
inserted before every read command. Basically it does the same thing as
a FTDI-2232H latency timer with value zero and show the same read
throughput.
By the way, the newest ftd2xx Windows driver can be improved as well
with that patch. And yes, later on I saw that this "send immediate" is
already used in the new ftdi/mpsse async driver. But first the results:

Patched FT2232 driver:
dump_image wndr3700-uboot.test 0x1f000000 0x2000
dumped 8192 bytes in 13.483574s (0.593 KiB/s)

Original FTDI driver:
dump_image wndr3700-uboot.test 0x1f000000 0x2000
dumped 8192 bytes in 8.443300s (0.947 KiB/s)

Patched FTDI driver:
dump_image wndr3700-uboot.test 0x1f000000 0x2000
dumped 8192 bytes in 8.042574s (0.995 KiB/s)


Also the new FTDI driver can be improved. Ok, the difference doesn't
impress someone, but it helps to understand further ways of FTDI
improvements, by combining the right USB-Out with the USB-In
transactions, here first done with a simple in/out reordering to out/in:
Because always the first USB-In transaction must be NAKed by the device,
which shouldn't have any interesting data prior in its input buffer,
especially USB 1.1 devices may be improved a little bit more than USB
2.0 FTDI chips.
Again looking with the LeCroy on the USB I saw further USB-In
transaction from the device are NAKed, although I already used a high
Jtag TCK rate of 15MHz and the reorder patch. The reasons for those NAKs
are:
- the FTDI chip must wait a longer time until a more complex bit
synchronous in/out transfer is completed before it can release its input
buffer
- currently not all time is used in parallel sending the next command
sequence over USB to the device, when bits can be collected from the
Jtag TDO into the FTDI chip internal read buffer
- possibly the "flush_queue" command need to be more often called in the
different target code for fine tuning, but naturally with the risk of
bad side effects, because such optimization depends naturally on the
Jtag command execution latency of all these different Jtag interfaces.

Because I am just a beginner of using OpenOCD, I would be interested in
feedback from experienced ARM and MIPS OpenOCD debuggers, if the ft2232
patch show also improvements in other use cases. You will find both
patches naturally also in Gerrit for review.

Kind Regards,

Peter
--
-------------------------------------------------------------------------
Peter Henn
D-47495 Rheinberg                       mailto:Pet...@we...