This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: RedBoot load command speedup
- From: Larice Robert <larice at vidisys dot de>
- To: Yoshinori Sato <qzb04471 at nifty dot ne dot jp>
- Cc: ecos-devel at sources dot redhat dot com
- Date: Mon, 1 Jul 2002 11:16:05 +0200 (CEST)
- Subject: Re: RedBoot load command speedup
Hello, Yoshinori Sato
I've tried your patch with a modified hal_delay_us (faked to hal_delay_50ns)
this leads to 731kByte/s download speed.
further I've searched the actual calls to hal_delay_us which bother
download speed in tftp raw mode.
the first happens in __udp_recvfrom, which is called for every received
512byte long tftp packet. there you will find a
start = MS_TICKS();
while ((MS_TICKS_DELAY() - start) < total_ms) {
__enet_poll(); // Handle the hardware
...
which means there is at least one 1ms delay for every 512 Byte packet
(in MS_TICKS_DELAY)
another delay happens in eth_drv_write, which is called to acknowledge every
received tftp packet. there you will find a
while (1) {
(sc->funs->poll)(sc);
if(packet_sent)
break;
CYGACC_CALL_IF_DELAY_US(2*1000);
...
which means, if you have bad luck (i had with your patch), there is
an additional 2ms delay per 512 Byte.
the reason why I've pointed you to hal_delay_us is, because I've found
the ecos implementation for sh4 to be definitely bogus. i glanced at the h8300
implementation, (there seem to be approx 3 of them), and I'd say they are
sufficient complex to provide room for bugs too.
I'd recommend to check hal_delay_us thoroughly.
anyway, I don't think the download speed is of such importance to justify
additional code complexity. after all the ecos redboot can be considered
to be just a kind of auxiliary development tool, more or less just to
support startup of development code. anything larger approx 200k/s should
be perfectly sufficient.
Robert Larice