Hi Laurent, Gerrit: http://openocd.zylin.com/#/c/941/
or Git: http://openocd.zylin.com/gitweb?p=openocd.git;a=commitdiff;h=a5c818d2577b62273f8863df7e2e510006d49c9a Regards, Peter Am 01.02.2013 17:51, schrieb Laurent Gauch: > Hi Peter, > > Where is this patch sourced ? > > Regards, > Laurent > > I can test with AMONTEC JTAGKEY ft2232D based and AMONTEC JTAGKEY-2 > ft2232H based . > http://www.amontec.com > > > > Le 01.02.2013 16:34, Peter Henn a écrit : >> Hi Oliver and OpenOCD developers, >> >> thanks for testing the patch. The patch was related to the FTDI >> application note: "AN 108 Command Processor for MPSSE and MCU Host Bus >> Emulation Modes", which also includes the older FT2232D chip. So I would >> not expect bad things happen, if that inserted flush commands is send to >> the old FT2232D chip. But unfortunately I haven't a JTAG dongle with >> that old chip, which prevents me for checking it using a LeCroy USB tracer. >> >> More interesting than seen my patch included in OpenOCD is the fact that >> the new ftdi driver also uses that flush command to decrease the USB >> latency time or slow down the overall JTAG memory read performance as >> you have detected with the FT2232D chip here. The intention of the flush >> command is just to stop the hardware built-in latency timeout timer and >> starting a short package transfer immediately. >> Without that flush command a next USB read transfer needs some time >> longer. But a faster USB read transfer is something different than an >> OpenOCD memory read or write command. >> >> Before we understand your findings here my remarks: You tested with >> STM32, which is ARM based. I used an AR7161 MIPS32 controller. MIPS do >> memory read and write in some kind of JTAG remote controlled CPU >> instructions in PRAC mode. I guess that is different compared to ARM and >> slows down memory read from OpenOCD anyway. At least the MIPS-EJTAG >> needs some kind of polling a JTAG status register for every JTAG >> controlled CPU instruction. >> My patch decrease the USB read latency. But in detail it has only an >> effect, if the next JTAG commands often arrive faster and the polling of >> the status register detects a CPU not yet ready situation, before the >> USB-latency timer anyway would elapse. >> Additionally USB allows transfers only in a discrete timing raster of >> 125 uSec or possibly 1ms, because USB host controllers mostly start the >> next USB transfer only at the beginning of the next USB-Microframe >> and/or depending on the host controller implementation using Full Speed >> this timing raster may be increased to 1 ms. At the final end the JTAG >> instruction speed, which depends on the JTAG clock rate, interferes with >> that USB timing raster and could become worse using USB 1.1 >> I would expect that this is the case using the old FT2232D chip running >> with USB1.1. Without an USB analyzer in place, we need some more input >> from your measurement: >> >> 1. Which OS and PC did you use? >> 2. Which JTAG clock rate did you use and did you try with different rates? >> 3. Which absolute memory read (write) transfer speeds did you measure? >> 4. Was the read out data always correct? >> >> Here are my measurements: >> 1. I used an Core-2 Notebook and did the measurement running Debian >> Lenny i386 and Debian Squeeze AMD64. >> 2. The AR7161 JTAG speed was 10MHz in case of the USB FT2232H based >> dongle and 0.5MHz in case of the Parport Wiggler dongle. Higher clock >> rates result sometimes in incorrect CPU behaviour. >> 3. I guess you see with your ARM system much higher throughput. However >> I measured only read performance, because write was dramatically faster >> on the MIPS system: >> - 0.1 KiB/s with the original ft2232 driver and Olimex ARM-USB-OCD-H >> - 0.5 KiB/s with the flush patch included in the ft2232 driver >> - 0.5 KiB/s with a parport driver >> - 5.0 KiB/s with a ftdi driver including all newest MIPS performance >> patches using the Olimex ARM-USB-OCD-H >> 4. Sometimes I measured a higher read performance, but the read data >> were incorrect. The above reads are naturally related to correct data read. >> >> >> How to proceed? If you are convinced that the inserted flush command >> make some bad things using the FT2232D adapter, please do some >> measurements using the new FTDI driver too, once a time the original >> code and once with that patch included: >> >> >> Omit the FTDI flush command just for test purposes, because with FT2232D >> the read throughput may be decreased. But note that this patch is still >> untested. >> --- a/src/jtag/drivers/mpsse.c >> +++ b/src/jtag/drivers/mpsse.c >> @@ -777,7 +777,7 @@ >> struct libusb_transfer *read_transfer = 0; >> struct transfer_result read_result = { .ctx = ctx, .done = true }; >> if (ctx->read_count) { >> - buffer_write_byte(ctx, 0x87); /* SEND_IMMEDIATE */ >> +// buffer_write_byte(ctx, 0x87); /* SEND_IMMEDIATE */ >> read_result.done = false; >> read_transfer = libusb_alloc_transfer(0); >> libusb_fill_bulk_transfer(read_transfer, ctx->usb_dev, >> ctx->in_ep, >> ctx->read_chunk, >> >> >> Another way might be checking how often polling a JTAG status register >> miss with/without the flush (patched) included, expecting that an ARM >> system requires as well polling a status register in read mode. That >> could give us a hint, if the decreased read performance is related to an >> interference problem of the polling cycle time with the JTAG instruction >> cycles. But when you measure higher read throughput using a different or >> slower JTAG clock rates may give us also an indication here. >> >> Thanks and Kind Regards, >> >> Peter >> >> Am 31.01.2013 13:43, schrieb Spencer Oliver (Code Review): >>> Spencer Oliver has posted comments on this change. >>> >>> Change subject: ft2232 flush before read >>> ...................................................................... >>> >>> >>> Patch Set 1: I would prefer that you didn't submit this >>> >>> (1 inline comment) >>> >>> I have done some basic testing using a FT2232 and a FT2232H on a stm32 >>> board. >>> >>> A increase of about 4KiB/s was seen during a read test using the H adapter, >>> however the older chip (non H) seemed to be slightly slower 3KiB/s. Did not >>> see any change in write speed. >>> >>> Perhaps we need to check the type and use flush only for the newer H parts? >>> >>> The other issue is do we update this driver and add potential regressions >>> when it is as such deprecated. Maybe needs discussing on the ml. >>> >>> .................................................... >>> File src/jtag/drivers/ft2232.c >>> Line 810: LOG_DEBUG("Send Immediate buffer to PC"); >>> can you remove any debug messages as they can make it a bit to noisy. >>> if they are needed then use a _DEBUG_USB_IO_ block ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
