Le 04.02.2013 04:20, Peter Henn a écrit :
> Hi Laurent,
>
> Am 02.02.2013 17:23, schrieb Laurent Gauch:
>> so for me I cannot see any trouble on the use of the send immediat 87
>> command regarding and the full-speed and high-speed device.
>> We have used it a lot as with our Amontec JTAGkey SVF Player or vector
>> player....
>> We never see any bad effect using this command.
>>
> That is an important information, because that means I can in principle
> emulate the FT2232D chip simply by running a FT2232H on a USB1.1 hub and
> trace it with the LeCroy.
>
> Yesterday I made some first tests with an LPC-3131 ARM base SoC. The
> data read tests were really impressive using the ftdi driver and the
> FT2232H based dongle:
>
> JTAG speed: 10 MHz:
> dump_image lpc3231-irom.bin 0x12000000 0x20000
> dumped 131072 bytes in 0.630765s (202.928 KiB/s)
>
> JTAG speed: 6 MHz:
> dump_image lpc3231-irom.bin 0x12000000 0x20000
> dumped 131072 bytes in 0.905101s (141.421 KiB/s)
>
> JTAG speed: 1 MHz:
> dump_image lpc3231-irom.bin 0x12000000 0x20000
> dumped 131072 bytes in 4.153779s (30.815 KiB/s)
>
> That means there is a strong dependency between the JTAG clock rate and
> the read performance as I had expected. But these are naturally not the
> measurements of the here discussed ft2232 driver with USB-1.1
>
> I will need some time to lend the LeCroy, doing all these measurements
> and will then come back to you. Please be patient.
>
>
>> Also, regarding the mips32, I do not understand why you expect the send
>> immediat command to be the trouble.
> I personally didn't expect any trouble on mips32.
>
>> For me it should come from the upper layer.
>>
>> But in an other way, the patch touch the buffer by using buffer_write
>> inside in the send_and_recv function.
> Yepp, and therefore I took especially double care on that, including a
> analyzing tour what happen inside the used libftdi!
> Buffer_write is called several times in ft2232.c to setup the JTAG
> commands and then finally handing over to the libftdi, which does an
> additional copy of the whole data message again from RAM to RAM,
> including the MPSSE command setup. This copying is really crazy and now
> in the ftdi/libusb solution much better done.
>
>> This could generate issue if the buffer was full before the
>> send_and_receiv.
> Nop, that is hide by "buffer_write" function. Looking at line 414 in
> ft2232.c gives you an answer:
>
> static inline void buffer_write(uint8_t val)
> {
> assert(ft2232_buffer);
> assert((unsigned) ft2232_buffer_size< (unsigned) FT2232_BUFFER_SIZE);
> ft2232_buffer[ft2232_buffer_size++] = val;
> }
> Or did you see a crash message during your tests?
Yes, but this is an assert !!!
adding the send immediat command should be done before calling the
send_reicv anyway.
But as you say, the ft2232.c should be reworked and it should call the
mpsse.c sub layer.
Laurent
http://www.amontec.com
JTAGkey-2 USB JTAG made faster.
> Regards,
> Peter
>
>> So the actual patch is really not so good.
>>
>> Maybe this is why you have sometimes some issues.
>>
>> Regards,
>> Laurent
>> http://www.amontec.com ;-)
>>
>>
>>> 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
