Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)

[Andrew Lyon]

On Mon, Apr 4, 2011 at 7:54 PM, Andrew Lyon  wrote:
> On Mon, Apr 4, 2011 at 6:51 PM, Øyvind Harboe  wrote:
>> Any objections to merging 1,2 and 4?
>>
>> I think #3 needs more discussion or cool-off. My objection is
>> that we don't know why this makes things better and it certainly
>> seems to hit performance hard.
>>
>>
>> --
>> Øyvind Harboe
>>
>> Can Zylin Consulting help on your project?
>>
>> US toll free 1-866-980-3434 / International +47 51 87 40 27
>>
>> http://www.zylin.com/zy1000.html
>> ARM7 ARM9 ARM11 XScale Cortex
>> JTAG debugger and flash programmer
>> ___
>> Openocd-development mailing list
>> Openocd-development@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/openocd-development
>>
>
> Hi,
>
> I did some more testing loading much larger images (3226774 bytes) and
> found that both with and without patch #3 the image fails to load
> properly, attempting to bootm the uImage uboot detected bad crc and
> aborted, and verify_image also fails and starts a slow compare that
> would take all night to run.
>
> I can load the same image into ram using uboot and y-modem over
> serial, so there is clearly nothing wrong with the ram setup etc.
>
> Not sure how to approach debugging this further so any advice would be
> appreciated.
>
> Andy
>

I scripted some tests which ran overnight and are still running,
basically just a cycle of cat uboot >>testfile ; load_image ;
verify_image so that the test binary grew by 118k between each run and
I am now close to identifying the point at which images are too big
for me to load successfully:

3226774 uImage fails to load
3089528 testimagerandomuboots loads successfully

I've changed my script to load each of these several times to make
sure the failure is consistent, then I will change to bisecting
between the two file sizes to identify the failure point.

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)

[Andrew Lyon]

Yes, with #3 applied I do not get any of the buffer size warnings I
saw previously, for example here is a debug=3 log of loading uboot:

User : 81 4569151 command.c:557 command_print(): debug_level: 3
Debug: 82 4571432 command.c:151 script_debug(): command - ocd_command
ocd_command type ocd_load_image u-boot.t2 0xa040
Debug: 83 4571433 command.c:151 script_debug(): command - load_image
ocd_load_image u-boot.t2 0xa040
Debug: 85 4571439 configuration.c:87 find_file(): found u-boot.t2
Debug: 86 4571439 configuration.c:87 find_file(): found u-boot.t2
Debug: 87 4571440 target.c:1346 target_write_buffer(): writing buffer
of 118828 byte at 0xa040
Debug: 88 4571440 mips_m4k.c:1037 mips_m4k_bulk_write_memory():
address: 0xa040, count: 0x740b
Debug: 89 4571440 target.c:1157 target_alloc_working_area_try(): MMU
disabled, using physical address for working memory 0xa001
Debug: 90 4571440 target.c:1217 target_alloc_working_area_try():
allocated new working area at address 0xa001
Debug: 94 4573359 mips32_pracc.c:1018 mips32_pracc_fastdata_xfer():
mips32_pracc_fastdata_xfer using 0xa001 for write handler
Debug: 96 4632848 log.c:437 keep_alive(): keep_alive() was not invoked
in the 1000ms timelimit (59457). This may cause trouble with GDB
connections.
User : 98 4632855 command.c:557 command_print(): 118828 bytes written
at address 0xa040
User : 99 4632855 command.c:557 command_print(): downloaded 118828
bytes in 61.415859s (1.889 KiB/s)

Andy

On Mon, Apr 4, 2011 at 8:21 PM, Drasko DRASKOVIC
 wrote:
> Does the patch #3 remove these warnings for you ?
>
> On Mon, Apr 4, 2011 at 6:02 PM, Andrew Lyon  wrote:
>> On Mon, Apr 4, 2011 at 4:55 PM, Drasko DRASKOVIC
>>  wrote:
>>> Hi Andy,
>>> thanks a lot for these tests !
>>>
>>> I can see that it is well flushing the buffer that affects the
>>> performance, as we suspected, and which is logical.
>>>
>>> However, without this step I am constantly getting "ft2232 buffer size
>>> reached" errors for both libftdi, libftd2xx and libftdi-1.0 and
>>> FASTDATA does not work... I do not know if there is some other way to
>>> prevent this and not affect performances.
>>>
>>> BR,
>>> Drasko
>>
>> I get the same messages, although they appear to be warnings rather
>> than errors, perhaps I am not loading enough data for them to become
>> critical? How big is the image you are loading?
>>
>> Debug: 400 777585 mips32_pracc.c:1018 mips32_pracc_fastdata_xfer():
>> mips32_pracc_fastdata_xfer using 0xa001 for write handler
>> Debug: 402 777845 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer
>> size reached, sending queued commands (first_unsent: 0xb7630008, cmd:
>> 0xb7536fe8)
>> Debug: 403 778112 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer
>> size reached, sending queued commands (first_unsent: 0xb7536fe8, cmd:
>> 0xb743dfac)
>> Debug: 404 778380 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer
>> size reached, sending queued commands (first_unsent: 0xb743dfac, cmd:
>> 0xb7344f28)
>> User : 406 778687 command.c:557 command_print(): 109628 bytes written
>> at address 0xa040
>>
>> Andy
>>
>>>
>>> On Mon, Apr 4, 2011 at 5:50 PM, Andrew Lyon  wrote:
>>>> On Mon, Apr 4, 2011 at 4:21 PM, Drasko DRASKOVIC
>>>>  wrote:
>>>>> Hi Andrew,
>>>>> this might also come from the while(1) loop functionality which is now
>>>>> by my opinion done well.
>>>>>
>>>>> Maybe before it worked, but I think it was not really correct and not
>>>>> promised good results for all MIPS targets.
>>>>>
>>>>> What happens if you do not apply patch #3 (added jtag_execute_queue())
>>>>> ? Is this the reason of slow down, or is it #2 (while (1) loop) ?
>>>>
>>>> Revert #3: 34.624 KiB/s
>>>> Revert #2: 1.950 KiB/s
>>>> Apply All: 1.950 KiB/s
>>>>
>>>> Something I did notice, I did a few runs of each one to make sure the
>>>> speed reported was accurate, I noticed that in all cases the first
>>>> load_image takes slightly longer than any subsequent runs:
>>>>
>>>> Revert #2:
>>>>
>>>> downloaded 109628 bytes in 56.909698s (1.881 KiB/s)
>>>> downloaded 109628 bytes in 54.896725s (1.950 KiB/s)
>>>> downloaded 109628 bytes in 54.891483s (1.950 KiB/s)
>>>> downloaded 109628 bytes in 54.891483s (1.950 KiB/s)
>>>>
>>>> Apply all:
>>>>
>>>> downloaded 109628 bytes in 56.653496s (1.890 KiB/s)
>>>

Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)

[Andrew Lyon]

On Mon, Apr 4, 2011 at 6:51 PM, Øyvind Harboe  wrote:
> Any objections to merging 1,2 and 4?
>
> I think #3 needs more discussion or cool-off. My objection is
> that we don't know why this makes things better and it certainly
> seems to hit performance hard.
>
>
> --
> Øyvind Harboe
>
> Can Zylin Consulting help on your project?
>
> US toll free 1-866-980-3434 / International +47 51 87 40 27
>
> http://www.zylin.com/zy1000.html
> ARM7 ARM9 ARM11 XScale Cortex
> JTAG debugger and flash programmer
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>

Hi,

I did some more testing loading much larger images (3226774 bytes) and
found that both with and without patch #3 the image fails to load
properly, attempting to bootm the uImage uboot detected bad crc and
aborted, and verify_image also fails and starts a slow compare that
would take all night to run.

I can load the same image into ram using uboot and y-modem over
serial, so there is clearly nothing wrong with the ram setup etc.

Not sure how to approach debugging this further so any advice would be
appreciated.

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)

[Andrew Lyon]

On Mon, Apr 4, 2011 at 4:55 PM, Drasko DRASKOVIC
 wrote:
> Hi Andy,
> thanks a lot for these tests !
>
> I can see that it is well flushing the buffer that affects the
> performance, as we suspected, and which is logical.
>
> However, without this step I am constantly getting "ft2232 buffer size
> reached" errors for both libftdi, libftd2xx and libftdi-1.0 and
> FASTDATA does not work... I do not know if there is some other way to
> prevent this and not affect performances.
>
> BR,
> Drasko

I get the same messages, although they appear to be warnings rather
than errors, perhaps I am not loading enough data for them to become
critical? How big is the image you are loading?

Debug: 400 777585 mips32_pracc.c:1018 mips32_pracc_fastdata_xfer():
mips32_pracc_fastdata_xfer using 0xa001 for write handler
Debug: 402 777845 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer
size reached, sending queued commands (first_unsent: 0xb7630008, cmd:
0xb7536fe8)
Debug: 403 778112 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer
size reached, sending queued commands (first_unsent: 0xb7536fe8, cmd:
0xb743dfac)
Debug: 404 778380 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer
size reached, sending queued commands (first_unsent: 0xb743dfac, cmd:
0xb7344f28)
User : 406 778687 command.c:557 command_print(): 109628 bytes written
at address 0xa040

Andy

>
> On Mon, Apr 4, 2011 at 5:50 PM, Andrew Lyon  wrote:
>> On Mon, Apr 4, 2011 at 4:21 PM, Drasko DRASKOVIC
>>  wrote:
>>> Hi Andrew,
>>> this might also come from the while(1) loop functionality which is now
>>> by my opinion done well.
>>>
>>> Maybe before it worked, but I think it was not really correct and not
>>> promised good results for all MIPS targets.
>>>
>>> What happens if you do not apply patch #3 (added jtag_execute_queue())
>>> ? Is this the reason of slow down, or is it #2 (while (1) loop) ?
>>
>> Revert #3: 34.624 KiB/s
>> Revert #2: 1.950 KiB/s
>> Apply All: 1.950 KiB/s
>>
>> Something I did notice, I did a few runs of each one to make sure the
>> speed reported was accurate, I noticed that in all cases the first
>> load_image takes slightly longer than any subsequent runs:
>>
>> Revert #2:
>>
>> downloaded 109628 bytes in 56.909698s (1.881 KiB/s)
>> downloaded 109628 bytes in 54.896725s (1.950 KiB/s)
>> downloaded 109628 bytes in 54.891483s (1.950 KiB/s)
>> downloaded 109628 bytes in 54.891483s (1.950 KiB/s)
>>
>> Apply all:
>>
>> downloaded 109628 bytes in 56.653496s (1.890 KiB/s)
>> downloaded 109628 bytes in 54.862507s (1.951 KiB/s)
>> downloaded 109628 bytes in 54.891483s (1.950 KiB/s)
>> downloaded 109628 bytes in 54.891483s (1.950 KiB/s)
>>
>> Revert #3:
>>
>> downloaded 109628 bytes in 3.101150s (34.522 KiB/s)
>> downloaded 109628 bytes in 1.105152s (96.872 KiB/s)
>> downloaded 109628 bytes in 1.102143s (97.137 KiB/s)
>> downloaded 109628 bytes in 1.101120s (97.227 KiB/s)
>>
>> Andy
>>
>>> BR,
>>> Drasko
>>>
>>> On Mon, Apr 4, 2011 at 5:06 PM, Andrew Lyon  wrote:
>>>> On Mon, Apr 4, 2011 at 2:51 PM, Drasko DRASKOVIC
>>>>  wrote:
>>>>> Hi all,
>>>>> here is a set of patched (separeted by the logical changes they
>>>>> introduce) that :
>>>>> 1) Correct endianess for big endian targets
>>>>> 2) Correct while(1) loop waiting for PrAcc to be "1"
>>>>> 3) Change FASTDATA operation, forcing the shift out to prevent "ft2232
>>>>> buffer size reached" errors
>>>>> 4) Add optimizations similar to ones introduced by Øyvind recently
>>>>>
>>>>> With these patches I was able to obtain decent performances and
>>>>> correct functioning for my big endian MIPS-M14Kc based target.
>>>>>
>>>>> I see no more problems with libftdi of type :
>>>>> Error: couldn't read enough bytes from FT2232 device (0 < 5)
>>>>> Current stable version of libftdi can be used, no need for closed D2XX
>>>>> files nor for development branches of libusb-1.0
>>>>>
>>>>> I also have no more problems with GDB synchronisation - ELF can be
>>>>> correctly downloaded and executed from GDB.
>>>>>
>>>>> Best regards,
>>>>> Drasko
>>>>>
>>>>
>>>> Hi Drasko,
>>>>
>>>> I reverted the patches I used previously and applied your 4 patches
>>>> but load_image is now much slower:

Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)

[Andrew Lyon]

On Mon, Apr 4, 2011 at 4:21 PM, Drasko DRASKOVIC
 wrote:
> Hi Andrew,
> this might also come from the while(1) loop functionality which is now
> by my opinion done well.
>
> Maybe before it worked, but I think it was not really correct and not
> promised good results for all MIPS targets.
>
> What happens if you do not apply patch #3 (added jtag_execute_queue())
> ? Is this the reason of slow down, or is it #2 (while (1) loop) ?

Revert #3: 34.624 KiB/s
Revert #2: 1.950 KiB/s
Apply All: 1.950 KiB/s

Something I did notice, I did a few runs of each one to make sure the
speed reported was accurate, I noticed that in all cases the first
load_image takes slightly longer than any subsequent runs:

Revert #2:

downloaded 109628 bytes in 56.909698s (1.881 KiB/s)
downloaded 109628 bytes in 54.896725s (1.950 KiB/s)
downloaded 109628 bytes in 54.891483s (1.950 KiB/s)
downloaded 109628 bytes in 54.891483s (1.950 KiB/s)

Apply all:

downloaded 109628 bytes in 56.653496s (1.890 KiB/s)
downloaded 109628 bytes in 54.862507s (1.951 KiB/s)
downloaded 109628 bytes in 54.891483s (1.950 KiB/s)
downloaded 109628 bytes in 54.891483s (1.950 KiB/s)

Revert #3:

downloaded 109628 bytes in 3.101150s (34.522 KiB/s)
downloaded 109628 bytes in 1.105152s (96.872 KiB/s)
downloaded 109628 bytes in 1.102143s (97.137 KiB/s)
downloaded 109628 bytes in 1.101120s (97.227 KiB/s)

Andy

> BR,
> Drasko
>
> On Mon, Apr 4, 2011 at 5:06 PM, Andrew Lyon  wrote:
>> On Mon, Apr 4, 2011 at 2:51 PM, Drasko DRASKOVIC
>>  wrote:
>>> Hi all,
>>> here is a set of patched (separeted by the logical changes they
>>> introduce) that :
>>> 1) Correct endianess for big endian targets
>>> 2) Correct while(1) loop waiting for PrAcc to be "1"
>>> 3) Change FASTDATA operation, forcing the shift out to prevent "ft2232
>>> buffer size reached" errors
>>> 4) Add optimizations similar to ones introduced by Øyvind recently
>>>
>>> With these patches I was able to obtain decent performances and
>>> correct functioning for my big endian MIPS-M14Kc based target.
>>>
>>> I see no more problems with libftdi of type :
>>> Error: couldn't read enough bytes from FT2232 device (0 < 5)
>>> Current stable version of libftdi can be used, no need for closed D2XX
>>> files nor for development branches of libusb-1.0
>>>
>>> I also have no more problems with GDB synchronisation - ELF can be
>>> correctly downloaded and executed from GDB.
>>>
>>> Best regards,
>>> Drasko
>>>
>>
>> Hi Drasko,
>>
>> I reverted the patches I used previously and applied your 4 patches
>> but load_image is now much slower:
>>
>> Debug: 132 223732 command.c:151 script_debug(): command - ocd_command
>> ocd_command type ocd_halt
>> Debug: 133 223732 command.c:151 script_debug(): command - halt ocd_halt
>> Debug: 135 223738 target.c:2196 handle_halt_command(): -
>> Debug: 136 223738 mips_m4k.c:182 mips_m4k_halt(): target->state: running
>> Debug: 137 223746 mips_ejtag.c:239 mips_ejtag_enter_debug():
>> ejtag_ctrl: 0x4004c008
>> Debug: 141 225374 mips_m4k.c:109 mips_m4k_debug_entry(): entered debug
>> state at PC 0x83fe4128, target->state: halted
>> Debug: 142 225374 target.c:1053 target_call_event_callbacks(): target
>> event 2 (gdb-halt)
>> Debug: 143 225374 target.c:1053 target_call_event_callbacks(): target
>> event 3 (halted)
>> User : 144 225374 target.c:1330 target_arch_state(): target state: halted
>> User : 145 225374 mips32.c:259 mips32_arch_state(): target halted in
>> MIPS32 mode due to debug-request, pc: 0x83fe4128
>> Debug: 146 227896 command.c:151 script_debug(): command - ocd_command
>> ocd_command type ocd_load_image u-boot.bin.new 0xa040
>> Debug: 147 227897 command.c:151 script_debug(): command - load_image
>> ocd_load_image u-boot.bin.new 0xa040
>> Debug: 149 227903 configuration.c:87 find_file(): found u-boot.bin.new
>> Debug: 150 227903 configuration.c:87 find_file(): found u-boot.bin.new
>> Debug: 151 227904 target.c:1346 target_write_buffer(): writing buffer
>> of 109628 byte at 0xa040
>> Debug: 152 227904 mips_m4k.c:1037 mips_m4k_bulk_write_memory():
>> address: 0xa040, count: 0x6b0f
>> Debug: 153 227904 target.c:1157 target_alloc_working_area_try(): MMU
>> disabled, using physical address for working memory 0xa001
>> Debug: 154 227904 target.c:1217 target_alloc_working_area_try():
>> allocated new working area at address 0xa001
>> Debug: 158 229698 mips32_pracc.c:1018 mips32_pracc_fastdata_xfer():
>> mips32_pracc_fastdata_xfer using 0xa001 for

Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)

[Andrew Lyon]

On Mon, Apr 4, 2011 at 2:51 PM, Drasko DRASKOVIC
 wrote:
> Hi all,
> here is a set of patched (separeted by the logical changes they
> introduce) that :
> 1) Correct endianess for big endian targets
> 2) Correct while(1) loop waiting for PrAcc to be "1"
> 3) Change FASTDATA operation, forcing the shift out to prevent "ft2232
> buffer size reached" errors
> 4) Add optimizations similar to ones introduced by Øyvind recently
>
> With these patches I was able to obtain decent performances and
> correct functioning for my big endian MIPS-M14Kc based target.
>
> I see no more problems with libftdi of type :
> Error: couldn't read enough bytes from FT2232 device (0 < 5)
> Current stable version of libftdi can be used, no need for closed D2XX
> files nor for development branches of libusb-1.0
>
> I also have no more problems with GDB synchronisation - ELF can be
> correctly downloaded and executed from GDB.
>
> Best regards,
> Drasko
>

Hi Drasko,

I reverted the patches I used previously and applied your 4 patches
but load_image is now much slower:

Debug: 132 223732 command.c:151 script_debug(): command - ocd_command
ocd_command type ocd_halt
Debug: 133 223732 command.c:151 script_debug(): command - halt ocd_halt
Debug: 135 223738 target.c:2196 handle_halt_command(): -
Debug: 136 223738 mips_m4k.c:182 mips_m4k_halt(): target->state: running
Debug: 137 223746 mips_ejtag.c:239 mips_ejtag_enter_debug():
ejtag_ctrl: 0x4004c008
Debug: 141 225374 mips_m4k.c:109 mips_m4k_debug_entry(): entered debug
state at PC 0x83fe4128, target->state: halted
Debug: 142 225374 target.c:1053 target_call_event_callbacks(): target
event 2 (gdb-halt)
Debug: 143 225374 target.c:1053 target_call_event_callbacks(): target
event 3 (halted)
User : 144 225374 target.c:1330 target_arch_state(): target state: halted
User : 145 225374 mips32.c:259 mips32_arch_state(): target halted in
MIPS32 mode due to debug-request, pc: 0x83fe4128
Debug: 146 227896 command.c:151 script_debug(): command - ocd_command
ocd_command type ocd_load_image u-boot.bin.new 0xa040
Debug: 147 227897 command.c:151 script_debug(): command - load_image
ocd_load_image u-boot.bin.new 0xa040
Debug: 149 227903 configuration.c:87 find_file(): found u-boot.bin.new
Debug: 150 227903 configuration.c:87 find_file(): found u-boot.bin.new
Debug: 151 227904 target.c:1346 target_write_buffer(): writing buffer
of 109628 byte at 0xa040
Debug: 152 227904 mips_m4k.c:1037 mips_m4k_bulk_write_memory():
address: 0xa040, count: 0x6b0f
Debug: 153 227904 target.c:1157 target_alloc_working_area_try(): MMU
disabled, using physical address for working memory 0xa001
Debug: 154 227904 target.c:1217 target_alloc_working_area_try():
allocated new working area at address 0xa001
Debug: 158 229698 mips32_pracc.c:1018 mips32_pracc_fastdata_xfer():
mips32_pracc_fastdata_xfer using 0xa001 for write handler
Debug: 159 284584 log.c:437 keep_alive(): keep_alive() was not invoked
in the 1000ms timelimit (55226). This may cause trouble with GDB
connections.
User : 161 284588 command.c:557 command_print(): 109628 bytes written
at address 0xa040
User : 162 284588 command.c:557 command_print(): downloaded 109628
bytes in 56.685356s (1.889 KiB/s)


Compared to the version I was using previously which just had the two
patches for endianness:

Debug: 100 50064 command.c:151 script_debug(): command - ocd_command
ocd_command type ocd_halt
Debug: 101 50065 command.c:151 script_debug(): command - halt ocd_halt
Debug: 103 50071 target.c:2196 handle_halt_command(): -
Debug: 104 50071 mips_m4k.c:178 mips_m4k_halt(): target->state: running
Debug: 105 50079 mips_ejtag.c:218 mips_ejtag_enter_debug():
ejtag_ctrl: 0x4004c008
Debug: 111 52855 mips_m4k.c:109 mips_m4k_debug_entry(): entered debug
state at PC 0x83fe4128, target->state: halted
Debug: 112 52855 target.c:1053 target_call_event_callbacks(): target
event 2 (gdb-halt)
Debug: 113 52855 target.c:1053 target_call_event_callbacks(): target
event 3 (halted)
User : 114 52855 target.c:1330 target_arch_state(): target state: halted
User : 115 52855 mips32.c:259 mips32_arch_state(): target halted in
MIPS32 mode due to debug-request, pc: 0x83fe4128
Debug: 116 54993 command.c:151 script_debug(): command - ocd_command
ocd_command type ocd_load_image u-boot.bin.new 0xa040
Debug: 117 54993 command.c:151 script_debug(): command - load_image
ocd_load_image u-boot.bin.new 0xa040
Debug: 119 54999 configuration.c:87 find_file(): found u-boot.bin.new
Debug: 120 54999 configuration.c:87 find_file(): found u-boot.bin.new
Debug: 121 55000 target.c:1346 target_write_buffer(): writing buffer
of 109628 byte at 0xa040
Debug: 122 55000 mips_m4k.c:1016 mips_m4k_bulk_write_memory():
address: 0xa040, count: 0x6b0f
Debug: 123 55000 target.c:1157 target_alloc_working_area_try(): MMU
disabled, using physical address for working memory 0xa001
Debug: 124 55000 target.c:1217 target_alloc_working_area_try():
allocated new working area at address 0xa001

Re: [Openocd-development] ft2232 jtag mips performance

[Andrew Lyon]

On Wed, Mar 30, 2011 at 4:37 PM, Drasko DRASKOVIC
 wrote:
> Hi all,
> I would like to ask again for the problems noted below.
>
> If it seems reasonable from the maintainers point of view, I'll
> prepare the patch.
>
> Otherwise I'll keep the implementation just for me, as the existing
> solution seems to be working for the resto of people (but for me is
> wrong).
>
> BTW. Andy, what core are you using ? M4K or something else ? I am
> using M14Kc, but I believe that EJTAG implementation should be exactly
> the same...
>
> Best regards,
> Drasko

I am using m4k, if you send me your patch I will test it and let you
know if fastdata still works.

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] mips breakpoints

[Andrew Lyon]

Hi,

Any ideas why (software) breakpoints don't appear to work on mips?

I have bigendian mips cpu which appears to not have hardware
breakpoints, to test software bp I step into and through some code
(uboot) to identify how the code runs, then set bp at address already
seen when stepping, finally resume at entry point but the bp does not
fire as expected.

Even single stepping through the code it appears to pass over the bp.

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] bugfix for step mips_m4k

[Andrew Lyon]

On Tue, Mar 29, 2011 at 9:28 AM, Øyvind Harboe  wrote:
> Hi,
>
> I wasn't able to apply your patch.
>
> Is the attached patch correct?
>
>
>
>
> --
> Øyvind Harboe
>
> Can Zylin Consulting help on your project?
>
> US toll free 1-866-980-3434 / International +47 51 87 40 27
>
> http://www.zylin.com/zy1000.html
> ARM7 ARM9 ARM11 XScale Cortex
> JTAG debugger and flash programmer
>

Yes that's correct, in future I will send patches as attachments to
avoid such problems.

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] bugfix for step mips_m4k

[Andrew Lyon]

On Mon, Mar 28, 2011 at 11:31 AM, Øyvind Harboe  wrote:
> Any objections to committing?
>
> Could you also list the necessary patches here?
>
>
> Thanks!
>
>
> --
> Øyvind Harboe
>
> Can Zylin Consulting help on your project?
>
> US toll free 1-866-980-3434 / International +47 51 87 40 27
>
> http://www.zylin.com/zy1000.html
> ARM7 ARM9 ARM11 XScale Cortex
> JTAG debugger and flash programmer
>

The other patches I had to apply are the two hunks mentioned in this
thread 
http://lists.berlios.de/pipermail/openocd-development/2011-March/018337.html
but as Drasko said if they are applied and mips_m4k_bulk_write_memory
fails and falls back to mips_m4k_write_memory then the bits will be
shuffled twice.

I've looked at the code and there are various ways it could be fixed,
the most simple would be to remove the automatic use of bulk_write for
over 128 bytes and to remove the automatic fallback to write_memory,
leaving the user to decide which to use, commands already exist for
both (fast_load_image, load_image).

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] bugfix for step mips_m4k

[Andrew Lyon]

Hi,

The patch below fixes step  on mips_m4k:

diff --git a/src/target/mips_m4k.c b/src/target/mips_m4k.c
index 8afee9c..78786a5 100644
--- a/src/target/mips_m4k.c
+++ b/src/target/mips_m4k.c
@@ -422,6 +422,8 @@ static int mips_m4k_step(struct target *target, int current,
/* current = 1: continue on current pc, otherwise continue at
 */
if (!current)

buf_set_u32(mips32->core_cache->reg_list[MIPS32_PC].value, 0, 32,
address);
+   mips32->core_cache->reg_list[MIPS32_PC].dirty = 1;
+   mips32->core_cache->reg_list[MIPS32_PC].valid = 1;

/* the front-end may request us not to handle breakpoints */
if (handle_breakpoints) {


With this patch and the ones already posted last week for bigendian
fixes I can now successfully setup sdram, read and write memory, bulk
load memory using fastdata, resume to address, single step, and step
into address, I had previously reported that resume  did not
work but I was mistaken, it does work.

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] ft2232 jtag mips performance

[Andrew Lyon]

On Fri, Mar 25, 2011 at 12:07 PM, Drasko DRASKOVIC
 wrote:
> On Fri, Mar 25, 2011 at 1:02 PM, Andrew Lyon  wrote:
>> On Fri, Mar 25, 2011 at 11:40 AM, Drasko DRASKOVIC
>>  wrote:
>>> Hi Andy,
>>> thank you for these tests, it is very helpful. The problem you have
>>> can be easily solved by applying David Claffey's patches.
>>
>> I have applied them and recompiling now to test again, but looking at
>> the source they will only fix memory read/write, not the other
>> problems I mentioned with step and resume, perhaps they need similar
>> fixes?
> This might be fixed, because OpenOCD probably uses these functions to
> write bkpt instructions... I do not know, still did not test - I'll do
> it right now and report back.

step does not appear to work properly, certainly if I step into a
memory address then the address shown when the target is halted again
is not where I asked it to step into, or even anywhere that the code I
loaded could have made it jump (if some code was run before it was
halted again)

however manually setting the pc reg and then single stepping seems to
work, I am currently stepping thru the uboot code and so far I can
follow PC through the source dump and it makes perfect sense.

so step and resume fail when a address is passed.

I've got quite a way into the uboot process so don't want to stop yet
and start over as its quite a slow process, but once i've done this
run I will test breakpoints again, last time I tried they didn't work
so I seem to be stuck with single stepping, still its better than
nothing and great fun to trace the C code and asm as it runs :).

Andy

>
>>> I see that  mips32_pracc_fastdata_xfer() works well for you - I'll
>>> take a look why it does not work for me and elaborate on the list.
>>>
>>> Also, I can see that you are not facing the problem which I have :
>>>
>>> Error: couldn't read enough bytes from FT2232 device (0 < 5)
>>> Error: couldn't read from FT2232
>>> Error: register read failed
>>>
>>> Since Laurent from Amontec is capable of reproducing the same problem,
>>> it might be something related to Amontec dongle I am using, but there
>>> is small chance.
>>>
>>> Which dongle are you using ?
>>
>> Its a guruplug jtag module
>> http://www.globalscaletechnologies.com/p-28-guruplug-jtag.aspx
>>
>> Have you tried using libftxx instead of libftdi?
>
> Yes, same problem...
>
> BR,
> Drasko
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] compile failure due to recent cortex changes

[Andrew Lyon]

On Fri, Mar 25, 2011 at 12:13 PM, Øyvind Harboe  wrote:
> Try:
>
> make distclean
> sh bootstrap
> ./configure --enable-maintainer-mode 
>
>
>
> --
> Øyvind Harboe
>
> Can Zylin Consulting help on your project?
>
> US toll free 1-866-980-3434 / International +47 51 87 40 27
>
> http://www.zylin.com/zy1000.html
> ARM7 ARM9 ARM11 XScale Cortex
> JTAG debugger and flash programmer
>

Thanks, that fixed it, and will remember to do that in future.

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] compile failure due to recent cortex changes

[Andrew Lyon]

Hi,

The recent cortex commits cause compile to fail:

make[5]: Entering directory `/usr/src/openocd-git/src/target'
/bin/sh ../../libtool --tag=CC   --mode=compile gcc -std=gnu99
-DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src
-DPKGDATADIR=\"/usr/local/share/openocd\" -I../../jimtcl
-I../../jimtcl   -g -O2 -Wall -Wstrict-prototypes -Wformat-security
-Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast
-Wcast-align -Wredundant-decls -Werror -MT cortex_a8.lo -MD -MP -MF
.deps/cortex_a8.Tpo -c -o cortex_a8.lo cortex_a8.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..
-I../../src -I../../src -DPKGDATADIR=\"/usr/local/share/openocd\"
-I../../jimtcl -I../../jimtcl -g -O2 -Wall -Wstrict-prototypes
-Wformat-security -Wshadow -Wextra -Wno-unused-parameter
-Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT
cortex_a8.lo -MD -MP -MF .deps/cortex_a8.Tpo -c cortex_a8.c -o
cortex_a8.o
mv -f .deps/cortex_a8.Tpo .deps/cortex_a8.Plo
make[5]: *** No rule to make target `cortex_a9.c', needed by
`cortex_a9.lo'.  Stop.

I tried reverting just dec80e1cffa162ba0e1cd8e6ee66c7784fe79b87 but it
still failed and I had to go back to
ec2b8d71ac1fb2e8d6c8057a5e1d0a27bd7bd110 for the compile to be
successful.

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] ft2232 jtag mips performance

[Andrew Lyon]

On Fri, Mar 25, 2011 at 11:40 AM, Drasko DRASKOVIC
 wrote:
> Hi Andy,
> thank you for these tests, it is very helpful. The problem you have
> can be easily solved by applying David Claffey's patches.

I have applied them and recompiling now to test again, but looking at
the source they will only fix memory read/write, not the other
problems I mentioned with step and resume, perhaps they need similar
fixes?

>
> I see that  mips32_pracc_fastdata_xfer() works well for you - I'll
> take a look why it does not work for me and elaborate on the list.
>
> Also, I can see that you are not facing the problem which I have :
>
> Error: couldn't read enough bytes from FT2232 device (0 < 5)
> Error: couldn't read from FT2232
> Error: register read failed
>
> Since Laurent from Amontec is capable of reproducing the same problem,
> it might be something related to Amontec dongle I am using, but there
> is small chance.
>
> Which dongle are you using ?

Its a guruplug jtag module
http://www.globalscaletechnologies.com/p-28-guruplug-jtag.aspx

Have you tried using libftxx instead of libftdi?

>
> Best regards,
> Drasko
>
>
> On Fri, Mar 25, 2011 at 11:52 AM, Andrew Lyon  wrote:
>> On Thu, Mar 24, 2011 at 11:01 AM, Drasko DRASKOVIC
>>  wrote:
>>> Hi Andy,
>>> I am very surprised that OpenOCD works for big endian MIPS.
>>>
>>> I am currently working on this and I am preparing the patch that will
>>> fix some of the issues.
>>>
>>> What I currently observed is :
>>>
>>> 1) mips_m4k_write_memory() and mips_m4k_read_memory() do not handle
>>> endianess at all. Since these functions are used by mww and mdw
>>> commands to set up SDRAM controller, most probably your configuration
>>> is wrong. Can you check this by reading SDRAM controller configuration
>>> registers and comparing to that configuration you expect ? I'd be very
>>> suprised that it works.
>>>
>>> 2) Only mips_m4k_bulk_write_memory() handles endianess, but it is
>>> called on 128 byes blocks (becaus it uses FASTDATA, and size of
>>> FASTDATA area is 16 words). Bottom line is that by my observation
>>> confirmed that mips32_pracc_fastdata_xfer() called internaly does not
>>> work either, and I do not think that it works for little endian
>>> targets also, missing some FASTDATA instructions. So, it would be very
>>> important if you can answer us the question I asked in the first mail
>>> : is mips32_pracc_fastdata_xfer() function called, and does it
>>> succeeds, or it falls back to simple mips_m4k_write_memory() ? I would
>>> expect to fail and fallback to mips_m4k_write_memory(), which as I
>>> explaind, do not handle endianess at all.
>>>
>>> So please send us the report on following 3 things :
>>> 1) Is SDRAM configured OK (i.e. does mww commands work well for you)
>>
>> Hi Drasko,
>>
>> You are absolutely right there are endianness issues with mips
>> bigendian, on the board I am using the memory controller is already
>> configured by the onboard firmware but reading back the values I can
>> see they are bitswapped:
>>
>> mdw 0xbf8011d0 1
>> 0xbf8011d0: 932d
>> Correct Value: 0xbf8011d0 0x2D93
>>
>> mdw 0xbf8011e0 1
>> 0xbf8011e0: 3582
>> Correct Value: 0xbf8011e0 0x8235
>>
>>> 2) Is mips32_pracc_fastdata_xfer() exiting with error
>>
>> No, I checked the debug logs and it works successfully:
>>
>> Debug: 219 25550 target.c:1251 target_write_buffer(): writing buffer
>> of 57344 byte at 0x8600
>> Debug: 220 25550 mips_m4k.c:984 mips_m4k_bulk_write_memory(): address:
>> 0x8600, count: 0x3800
>> Debug: 221 25551 target.c:1072 target_alloc_working_area(): MMU
>> disabled, using physical address for working memory 0xa060
>> Debug: 222 25551 target.c:1134 target_alloc_working_area(): allocated
>> new working area at address 0xa060
>> Debug: 228 28508 mips32_pracc.c:971 mips32_pracc_fastdata_xfer():
>> mips32_pracc_fastdata_xfer using 0xa060 for write handler
>>
>> Debug: 230 28711 ft2232.c:1685 ft2232_execute_scan(): ft2232 buffer
>> size reached, sending queued commands (first_unsent: 0xb74f3008, cmd:
>> 0xb7411fe8)
>> User : 232 29125 command.c:539 command_print(): 57344 bytes written at
>> address 0x8600
>> User : 233 29126 command.c:539 command_print(): downloaded 57344 bytes
>> in 3.576233s (15.659 kb/s)
>>
>>
>>> 3) Dump the loaded image and inspect it - is it well loaded in memory ?
>>
>> I 

Re: [Openocd-development] ft2232 jtag mips performance

[Andrew Lyon]

On Fri, Mar 25, 2011 at 10:52 AM, Andrew Lyon  wrote:
> On Thu, Mar 24, 2011 at 11:01 AM, Drasko DRASKOVIC
>  wrote:
>> Hi Andy,
>> I am very surprised that OpenOCD works for big endian MIPS.
>>
>> I am currently working on this and I am preparing the patch that will
>> fix some of the issues.
>>
>> What I currently observed is :
>>
>> 1) mips_m4k_write_memory() and mips_m4k_read_memory() do not handle
>> endianess at all. Since these functions are used by mww and mdw
>> commands to set up SDRAM controller, most probably your configuration
>> is wrong. Can you check this by reading SDRAM controller configuration
>> registers and comparing to that configuration you expect ? I'd be very
>> suprised that it works.
>>
>> 2) Only mips_m4k_bulk_write_memory() handles endianess, but it is
>> called on 128 byes blocks (becaus it uses FASTDATA, and size of
>> FASTDATA area is 16 words). Bottom line is that by my observation
>> confirmed that mips32_pracc_fastdata_xfer() called internaly does not
>> work either, and I do not think that it works for little endian
>> targets also, missing some FASTDATA instructions. So, it would be very
>> important if you can answer us the question I asked in the first mail
>> : is mips32_pracc_fastdata_xfer() function called, and does it
>> succeeds, or it falls back to simple mips_m4k_write_memory() ? I would
>> expect to fail and fallback to mips_m4k_write_memory(), which as I
>> explaind, do not handle endianess at all.
>>
>> So please send us the report on following 3 things :
>> 1) Is SDRAM configured OK (i.e. does mww commands work well for you)
>
> Hi Drasko,
>
> You are absolutely right there are endianness issues with mips
> bigendian, on the board I am using the memory controller is already
> configured by the onboard firmware but reading back the values I can
> see they are bitswapped:
>
> mdw 0xbf8011d0 1
> 0xbf8011d0: 932d
> Correct Value: 0xbf8011d0 0x2D93
>
> mdw 0xbf8011e0 1
> 0xbf8011e0: 3582
> Correct Value: 0xbf8011e0 0x8235
>
>> 2) Is mips32_pracc_fastdata_xfer() exiting with error
>
> No, I checked the debug logs and it works successfully:
>
> Debug: 219 25550 target.c:1251 target_write_buffer(): writing buffer
> of 57344 byte at 0x8600
> Debug: 220 25550 mips_m4k.c:984 mips_m4k_bulk_write_memory(): address:
> 0x8600, count: 0x3800
> Debug: 221 25551 target.c:1072 target_alloc_working_area(): MMU
> disabled, using physical address for working memory 0xa060
> Debug: 222 25551 target.c:1134 target_alloc_working_area(): allocated
> new working area at address 0xa060
> Debug: 228 28508 mips32_pracc.c:971 mips32_pracc_fastdata_xfer():
> mips32_pracc_fastdata_xfer using 0xa060 for write handler
>
> Debug: 230 28711 ft2232.c:1685 ft2232_execute_scan(): ft2232 buffer
> size reached, sending queued commands (first_unsent: 0xb74f3008, cmd:
> 0xb7411fe8)
> User : 232 29125 command.c:539 command_print(): 57344 bytes written at
> address 0x8600
> User : 233 29126 command.c:539 command_print(): downloaded 57344 bytes
> in 3.576233s (15.659 kb/s)
>
>
>> 3) Dump the loaded image and inspect it - is it well loaded in memory ?
>
> I think fastdata may be loading it correctly, but reading it back it
> is clearly bitswapped:
>

Drasko,

I read somewhere that some bigendian mips systems still have little
endian tap, perhaps that explains why on my system data loaded using
fastdata is ok (it is aware of endianness), but everything else is
bitswapped because my board does not have the little endian tap.

Andy

> hexdump of original file:
>
> 000 000b 1000      
> 010 688c 688c   312e 312e  3000
> 020        
> 030 7800 401b 00ff 3c08 ff00 3508 d824 0368
> 040 0001 3c08 9500 3508 0019 1768  
> 050 8000 4008 8000 3c09  3529 4024 0109
> 060 3604 3c09 4025 0109   8000 4088
> 070 0040  0040  0040  00c0 
> 080 6000 4008 fffc 3c09  3529 4024 0109
> 090  2409 4025 0109   6000 4088
> 0a0 0040  0040  0040  00c0 
> 0b0 0001 3c08 8000 3508 0007 1368  
> 0c0 0001 3c08 8400 3508 0003 1368  
> 0d0 0019 1000   8000 4008 8000 3c09
> 0e0  3529 4024 0109 3600 3c09 4025 0109
> 0f0   8000 4088 0040  0040 
>
> The file was loaded using fastdata_xfer and then read back, hexdump:
>
> 000 0010 0b00      
> 010 8c68 8c68   2e31 2e31 0030 
> 020        
> 03

Re: [Openocd-development] ft2232 jtag mips performance

[Andrew Lyon]

ot work, you can forget any debugging...
>
> Best regards,
> Drasko
>
> On Thu, Mar 24, 2011 at 11:43 AM, Andrew Lyon  wrote:
>> On Wed, Mar 23, 2011 at 2:06 PM, Drasko DRASKOVIC
>>  wrote:
>>> Hi Andy,
>>> are you using big or little endian CPU ?
>>
>> big endian.
>>
>>>
>>> Is mips32_pracc_fastdata_xfer() function called, and does it succeeds,
>>> or it falls back to simple mips_m4k_write_memory() ?
>>
>> I realized I had not setup the working area properly and having done
>> so load_image is much faster (14.378 kb/s)
>>
>> However I have noticed other problems, to give some background the
>> board is a mips router which already has a working factory firmware, I
>> am trying to port the uboot code released by the manufacturer into a
>> newer version of uboot, so I load my new uboot binary into memory and
>> resume to that address, but instead of running my code the system
>> seems to reset and boot from rom again.
>>
>> So I tried a more simple binary which simply toggles a gpio to make a
>> led flash, but the same thing happens.
>>
>> Here is a log with some notes.
>>
>>> targets
>>    TargetName         Type       Endian TapName            State
>> --  -- -- -- -- 
>>  0* xway.cpu           mips_m4k   big    xway.cpu           running
>>
>> *At this point the board has loaded uboot from rom and is at the uboot 
>> prompt.
>>
>>> halt
>> target state: halted
>> target halted in MIPS32 mode due to debug-request, pc: 0x83fd7ac0
>>> load_image test1 0x8000
>> 57344 bytes written at address 0x8000
>> downloaded 57344 bytes in 3.937115s (14.224 kb/s)
>>> step 0x8000
>> target state: halted
>> target halted in MIPS32 mode due to single-step, pc: 0x83fd7abc
>>
>> *As you can see PC is not where I asked it to go.
>>
>>> resume
>>
>> *At this point the uboot prompt starts responding to input again,
>> showing that the system never exec any of my code.
>>
>>> halt
>>> resume 0x8000
>>
>> *System resets and boots from rom.
>>
>> Andy
>>
>>
>>>
>>> BR,
>>> Drasko
>>>
>>> On Tue, Mar 22, 2011 at 2:20 PM, Andrew Lyon  wrote:
>>>> Hi,
>>>>
>>>> I am using a ft2232 based jtag device with a mips board and the
>>>> performance is really terrible:
>>>>
>>>> 57344 bytes in 3119.897949s (0.018 kb/s)
>>>>
>>>> It seems to work ok in that I can halt, resume, read/write memory etc,
>>>> but every operation is very slow, halting takes almost 3 seconds.
>>>>
>>>> I pulled the code from git and have tried using both libftdi and
>>>> libftd2xx0.4.16 but there is little difference.
>>>>
>>>> The jtag came with a guruplug and although I no longer have the
>>>> guruplug itself I do recall reflashing the 225k uboot image and it
>>>> took only a few seconds.
>>>>
>>>> Is this expected performance? If not what do I need to do to debug?
>>>>
>>>> Andy
>>>> ___
>>>> Openocd-development mailing list
>>>> Openocd-development@lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/openocd-development
>>>>
>>>
>>
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] ft2232 jtag mips performance

[Andrew Lyon]

On Wed, Mar 23, 2011 at 2:06 PM, Drasko DRASKOVIC
 wrote:
> Hi Andy,
> are you using big or little endian CPU ?

big endian.

>
> Is mips32_pracc_fastdata_xfer() function called, and does it succeeds,
> or it falls back to simple mips_m4k_write_memory() ?

I realized I had not setup the working area properly and having done
so load_image is much faster (14.378 kb/s)

However I have noticed other problems, to give some background the
board is a mips router which already has a working factory firmware, I
am trying to port the uboot code released by the manufacturer into a
newer version of uboot, so I load my new uboot binary into memory and
resume to that address, but instead of running my code the system
seems to reset and boot from rom again.

So I tried a more simple binary which simply toggles a gpio to make a
led flash, but the same thing happens.

Here is a log with some notes.

> targets
TargetName Type   Endian TapNameState
--  -- -- -- -- 
 0* xway.cpu   mips_m4k   bigxway.cpu   running

*At this point the board has loaded uboot from rom and is at the uboot prompt.

> halt
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0x83fd7ac0
> load_image test1 0x8000
57344 bytes written at address 0x8000
downloaded 57344 bytes in 3.937115s (14.224 kb/s)
> step 0x8000
target state: halted
target halted in MIPS32 mode due to single-step, pc: 0x83fd7abc

*As you can see PC is not where I asked it to go.

> resume

*At this point the uboot prompt starts responding to input again,
showing that the system never exec any of my code.

> halt
> resume 0x8000

*System resets and boots from rom.

Andy


>
> BR,
> Drasko
>
> On Tue, Mar 22, 2011 at 2:20 PM, Andrew Lyon  wrote:
>> Hi,
>>
>> I am using a ft2232 based jtag device with a mips board and the
>> performance is really terrible:
>>
>> 57344 bytes in 3119.897949s (0.018 kb/s)
>>
>> It seems to work ok in that I can halt, resume, read/write memory etc,
>> but every operation is very slow, halting takes almost 3 seconds.
>>
>> I pulled the code from git and have tried using both libftdi and
>> libftd2xx0.4.16 but there is little difference.
>>
>> The jtag came with a guruplug and although I no longer have the
>> guruplug itself I do recall reflashing the 225k uboot image and it
>> took only a few seconds.
>>
>> Is this expected performance? If not what do I need to do to debug?
>>
>> Andy
>> ___
>> Openocd-development mailing list
>> Openocd-development@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/openocd-development
>>
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] ft2232 jtag mips performance

[Andrew Lyon]

Hi,

I am using a ft2232 based jtag device with a mips board and the
performance is really terrible:

57344 bytes in 3119.897949s (0.018 kb/s)

It seems to work ok in that I can halt, resume, read/write memory etc,
but every operation is very slow, halting takes almost 3 seconds.

I pulled the code from git and have tried using both libftdi and
libftd2xx0.4.16 but there is little difference.

The jtag came with a guruplug and although I no longer have the
guruplug itself I do recall reflashing the 225k uboot image and it
took only a few seconds.

Is this expected performance? If not what do I need to do to debug?

Andy
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development