Wow ! What a speed-up :
Adding :
int retval;
if ((retval = jtag_execute_queue()) != ERROR_OK)
{
LOG_ERROR("register read failed");
return retval;
}
At the end of mips_ejtag_fastdata_scan() got me to :
downloaded 361540 bytes in 12.171962s (29.007 KiB/s)
Why this step is necessary ?
BR,
Drasko
On Fri, Apr 1, 2011 at 7:44 PM, Drasko DRASKOVIC
<[email protected]> wrote:
> On Fri, Apr 1, 2011 at 6:42 PM, Øyvind Harboe <[email protected]> wrote:
>>> last time i benchmarked the mips code removing the keep_alive made no change
>>> - only tested flash programming.
>>
>> There are a LOT of unnecessary USB roundtrips and Drasko is looking
>> into replacing clock out / in with clock out only where applicable.
>>
>> The added bonus of only clocking out is that clocking out can not fail,
>> so there is no need to propagate return values.
>
> Yes, and actually I saw that I introduced unnecessary latency with the
> latest patch, trying to correct wait_for_pracc_rw().
>
> As an optimization, I tried taking out repeating instruction send, like this :
>
> /* wait for the PrAcc to become "1" */
> mips_ejtag_set_instr(ejtag_info, EJTAG_INST_CONTROL);
> ejtag_ctrl = ejtag_info->ejtag_ctrl;
>
> int retval;
> if ((retval = jtag_execute_queue()) != ERROR_OK)
> {
> LOG_ERROR("fastdata load failed");
> return retval;
> }
>
> while (1)
> {
> retval = mips_ejtag_drscan_32(ejtag_info, &ejtag_ctrl);
> if (retval != ERROR_OK)
> return retval;
>
> if (ejtag_ctrl & EJTAG_CTRL_PRACC)
> break;
>
> if ( (timeout = timeval_ms()-then) > 1000 )
> {
> LOG_DEBUG("DEBUGMODULE: No memory access in
> progress!");
> return ERROR_JTAG_DEVICE_ERROR;
> }
> }
>
>
> As a result we have :
> downloaded 361540 bytes in 182.160828s (1.938 KiB/s)
>
> compared to previous :
> downloaded 361540 bytes in 362.964050s (0.973 KiB/s)
>
> I am really wondering for the FASTDATA loop, do we have to wait on
> PrAcc to be "1"... But trying not to wait (in order to prevent
> instruction sending, like in previous case), I am getting :
> Debug: 444 11073 ft2232.c:1959 ft2232_execute_scan(): ft2232 buffer
> size reached, sending queued commands (first_unsent: 0xb7bcb008, cmd:
> 0xb7cc122c)
>
> A lot of similar errors...
>
> BR,
> Drasko
>
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
