This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]