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. But unlike netconsole the "client side" is fully standard. Indeed very interesting. Can you pass back results, i.e. the output of an md command?
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 ;)
Cheers Detlev