[U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?

Grant Edwards grant.b.edwards at gmail.com
Mon Aug 23 23:42:53 CEST 2010


On 2010-08-23, Ben Warren <biggerbadderben at gmail.com> wrote:
> On 8/23/2010 2:10 PM, Grant Edwards wrote:

>> Now that you mention it, I have implemented a tftp server for U-Boot.
>>
>> We needed a way to recover "bricked" units in the field, and there's
>> simply no way we could require out customers to install a tftp server
>> on their machines.  Making U-Boot the tftp server and our "restore"
>> program the client solved several problems.  I also find have U-Boot
>> be the server is a lot more convenient for development use.  [It also
>> U-Boot commands to be sent via the tftp protocol.]
>>
>> I thought about submitting patches (it's pretty much a stand-alone
>> addition except for 3-4 lines in net.[ch]).  But it was made
>> abundantly clear that tftp server code for U-Boot would never be
>> considered -- I was scolded for even asking about it.
>
> I can see how this could be useful.  Please reconsider and we'll try to 
> keep the scolding to a minimum :)

OK.  I need clean up the sources a little.  There's still some debug
code that doesn't really need to be there any longer.

There's one bit of ugliness on which I could use some advice.  The
tftp server knows how to write to NAND flash, and uses a RAM buffer
the same size as an erase block.  Right now I just arbitrarily use a
128K block of RAM starting 256K below text base.  That works for my
board, but I'm sure isn't the "right" way to do things.  What is the
right way for a command to allocate a large, temporary buffer?
Increasing the stack/heap size to accomodate a 128K buffer doesn't
seem like the right thing to do, nor does statically allocating it.

It also only supports a single nand device.

In the meantime, here's the document describing how it works:


========================================================================

The U-Boot tftp server is run as a normal U-Boot command and uses
special filenames to specify source/destination of data and actions to
be performed:

  Destination (used with "put" or "write" requests)

       ram at 12345678

           Writes receive data into ram starting at address
           12345678 (decimal).

       nand at 0x2C00000

           Writes receive data into nand flash starting at address
           0x2C00000.  Nand will be erased before writing.  Writes to
           nand flash must start on 128K page boundaries and write
           sizes will be rounded up to the next 4K page boundary.

       cmd at ubootcmdstring

           Discards any data sent. After transfer completes,
           interprets 'ubootcmdstring' as if it were entered at the
           U-Boot command prompt.  Command output will appear on
           normal console device.

  Source (used with "get" or "read" request)

       nand at 0x12345678:4321

           Sends 4321 bytes of data from nand flash starting at
           address 0x12345678.  Reads from nand must start on a 512
           byte boundary.

       ram at 0x12345678:0x4321

           Sends 0x4321 bytes of data from ram starting at address
           0x12345678.

       cmd at ubootcmdstring

           Interprets 'ubootcmdstring' as if it were entered at the
           U-Boot command prompt and then sends the output of that
           command as tftp data.  If this is used for commands like
           "boot", the transfer will hang because executing the
           command will terminate U-Boot.  Such commands should be
           executed using a "write" request rather than a "read"
           request.


  Either Destination or source (either "put" or "get")

       The following "filenames" return 0 bytes of data when read from
       and will discard any data when written to.  After the 0 byte
       "data transfer" completes, they invoke the actions described.

       nanderase at 0x800000:0x20000

           Erases 0x20000 bytes of nand flash starting at address
           0x800000. Erase operation must start on 128K page boundary
           and erase size must be an integral multiple of 128K.

       go at 0x12345678

           Jump to address 0x12345678.

       reset@

           Reset the board.

       exitok@

           Exit tftp server with "success" status.

       exitfail@

           Exit tftp server with "fail" status.



When invoking the U-Boot tftp server, an idle-timeout (in seconds) may
be specified.  If no tftp requests are received within that time, the
server will terminate (with a "success" status).  If two arguments are
specified, the first is the idle-timeout at startup, and the second is
the idle-timeout that is used after the first tftp request has been
handled.  Timeout values of 0 mean 'run until somebody hits Ctrl-C on
the console'.

When the tftpserver terminates due to an idle timeout after an initial
command has been received, it exits with a "failure" status.

========================================================================


-- 
Grant Edwards               grant.b.edwards        Yow! This is a NO-FRILLS
                                  at               flight -- hold th' CANADIAN
                              gmail.com            BACON!!



More information about the U-Boot mailing list