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

[Grant Edwards]

On 2010-08-23, Detlev Zundel <dzu at denx.de> wrote:
> Hi Grant,
>
>>>>> Maybe you can implement a server on your hardware?
>>>>
>>>> What sort of server?
>>>
>>> It would be a tftp server of course but that is out of the question
>>> without a network hardware.
>>
>> Now that you mention it, I have implemented a tftp server for U-Boot.
>
> Nice job!
>
>> 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. 
>
> Yes, I can see that this is very nice in some scenarios.
>
>> [It also U-Boot commands to be sent via the tftp protocol.]
>
> Now this is actually very intersting.  I never considered something like
> this.  Of course it has the possibility to do "bad things" from the
> outside, but the netconsole code has the same problem.

True.  In order to be useful for de-brikcing, the tftp server must let
"outsiders" write stuff into flash.  Once you've decided to allow
that...

> But unlike netconsole the "client side" is fully standard.

Exactly.

> Indeed very interesting.  Can you pass back results, i.e. the output
> of an md command?

Yes:

   $ atftp -g -l foo.txt -r 'cmd at md.b 0 0x100' 10.0.0.99
   
   $ cat foo.txt
   00000000: 0d 00 00 ea 05 00 00 ea 05 00 00 ea 05 00 00 ea    ................
   00000010: 05 00 00 ea ac 11 00 00 05 00 00 ea 05 00 00 ea    ................
   00000020: fe ff ff ea fe ff ff ea fe ff ff ea fe ff ff ea    ................
   00000030: fe ff ff ea fe ff ff ea fe ff ff ea d4 d0 9f e5    ................
   00000040: d4 00 9f e5 00 10 90 e5 01 20 a0 e3 02 10 11 e0    ......... ......
   00000050: 09 00 00 1a c4 00 9f e5 01 19 a0 e3 01 20 a0 e3    ............. ..
   00000060: 02 10 81 e1 00 10 80 e5 ac 00 9f e5 00 10 90 e5    ................
   00000070: 01 20 a0 e3 02 10 11 e0 fb ff ff 0a a0 00 9f e5    . ..............
   00000080: 03 10 a0 e3 00 20 90 e5 01 20 02 e0 00 10 a0 e3    ..... ... ......
   00000090: 02 00 51 e1 0e 00 00 1a 01 10 a0 e3 00 20 a0 e3    ..Q.......... ..
   000000a0: 02 10 81 e1 00 10 80 e5 6c 00 9f e5 00 10 90 e5    ........l.......
   000000b0: 08 20 a0 e3 02 10 11 e0 fb ff ff 0a 64 20 9f e5    . ..........d ..
   000000c0: 1a 00 92 e8 04 00 53 e1 04 20 91 34 04 20 83 34    ......S.. .4. .4
   000000d0: fb ff ff 3a 34 20 8f e2 18 00 92 e8 00 20 a0 e3    ...:4 ....... ..
   000000e0: 04 00 53 e1 04 20 83 34 fc ff ff 3a 38 40 9f e5    ..S.. .4...:8 at ..
   000000f0: 0f e0 a0 e1 14 ff 2f e1 30 10 9f e5 0f e0 a0 e1    ....../.0.......


>> 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.
>
> Maybe I can talk you into posting the patches?  It would be an awful
> waste of effort not to at least post your (working!) implementation
> here and thus (at least) get it archieved.  In Free Software written
> code always has the potential to change minds ;)

OK, I'll clean it up and post it.

-- 
Grant Edwards               grant.b.edwards        Yow! People humiliating
                                  at               a salami!
                              gmail.com