On 2010-08-23, Detlev Zundel <d...@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 'c...@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...@.. 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot