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 0xa0400000 Debug: 83 4571433 command.c:151 script_debug(): command - load_image ocd_load_image u-boot.t2 0xa0400000 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 0xa0400000 Debug: 88 4571440 mips_m4k.c:1037 mips_m4k_bulk_write_memory(): address: 0xa0400000, count: 0x0000740b Debug: 89 4571440 target.c:1157 target_alloc_working_area_try(): MMU disabled, using physical address for working memory 0xa0010000 Debug: 90 4571440 target.c:1217 target_alloc_working_area_try(): allocated new working area at address 0xa0010000 Debug: 94 4573359 mips32_pracc.c:1018 mips32_pracc_fastdata_xfer(): mips32_pracc_fastdata_xfer using 0xa0010000 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 0xa0400000 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 <drasko.drasko...@gmail.com> wrote: > Does the patch #3 remove these warnings for you ? > > On Mon, Apr 4, 2011 at 6:02 PM, Andrew Lyon <andrew.l...@gmail.com> wrote: >> On Mon, Apr 4, 2011 at 4:55 PM, Drasko DRASKOVIC >> <drasko.drasko...@gmail.com> 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 0xa0010000 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 0xa0400000 >> >> Andy >> >>> >>> On Mon, Apr 4, 2011 at 5:50 PM, Andrew Lyon <andrew.l...@gmail.com> wrote: >>>> On Mon, Apr 4, 2011 at 4:21 PM, Drasko DRASKOVIC >>>> <drasko.drasko...@gmail.com> 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 <andrew.l...@gmail.com> wrote: >>>>>> On Mon, Apr 4, 2011 at 2:51 PM, Drasko DRASKOVIC >>>>>> <drasko.drasko...@gmail.com> 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 0xa0400000 >>>>>> Debug: 147 227897 command.c:151 script_debug(): command - load_image >>>>>> ocd_load_image u-boot.bin.new 0xa0400000 >>>>>> 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 0xa0400000 >>>>>> Debug: 152 227904 mips_m4k.c:1037 mips_m4k_bulk_write_memory(): >>>>>> address: 0xa0400000, count: 0x00006b0f >>>>>> Debug: 153 227904 target.c:1157 target_alloc_working_area_try(): MMU >>>>>> disabled, using physical address for working memory 0xa0010000 >>>>>> Debug: 154 227904 target.c:1217 target_alloc_working_area_try(): >>>>>> allocated new working area at address 0xa0010000 >>>>>> Debug: 158 229698 mips32_pracc.c:1018 mips32_pracc_fastdata_xfer(): >>>>>> mips32_pracc_fastdata_xfer using 0xa0010000 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 0xa0400000 >>>>>> 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 0xa0400000 >>>>>> Debug: 117 54993 command.c:151 script_debug(): command - load_image >>>>>> ocd_load_image u-boot.bin.new 0xa0400000 >>>>>> 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 0xa0400000 >>>>>> Debug: 122 55000 mips_m4k.c:1016 mips_m4k_bulk_write_memory(): >>>>>> address: 0xa0400000, count: 0x00006b0f >>>>>> Debug: 123 55000 target.c:1157 target_alloc_working_area_try(): MMU >>>>>> disabled, using physical address for working memory 0xa0010000 >>>>>> Debug: 124 55000 target.c:1217 target_alloc_working_area_try(): >>>>>> allocated new working area at address 0xa0010000 >>>>>> Debug: 131 58210 mips32_pracc.c:995 mips32_pracc_fastdata_xfer(): >>>>>> mips32_pracc_fastdata_xfer using 0xa0010000 for write handler >>>>>> Debug: 133 58513 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer >>>>>> size reached, sending queued commands (first_unsent: 0xb74db008, cmd: >>>>>> 0xb73e1fe8) >>>>>> Debug: 134 58781 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer >>>>>> size reached, sending queued commands (first_unsent: 0xb73e1fe8, cmd: >>>>>> 0xb72e8fac) >>>>>> Debug: 135 59049 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer >>>>>> size reached, sending queued commands (first_unsent: 0xb72e8fac, cmd: >>>>>> 0xb71eff28) >>>>>> User : 137 59354 command.c:557 command_print(): 109628 bytes written >>>>>> at address 0xa0400000 >>>>>> User : 138 59354 command.c:557 command_print(): downloaded 109628 >>>>>> bytes in 4.355341s (24.581 KiB/s) >>>>>> >>>>>> Andy >>>>>> >>>>> >>>> >>> >> > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
