On Fri, Apr 1, 2011 at 6:42 PM, Øyvind Harboe <oyvind.har...@zylin.com> 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
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
