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 ------------------------------------------------------------------------------ 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
