Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
Ok, here is a summary of what I have found out so, with the help of Wolfgang. Many thanks.
1) Wolfgang refers to the manual for system setup: http://www.denx.de/wiki/view/DULG/SystemSetup He recommends Linux programs cu and Kermit.
2) When using the "loads" command to upload an S-record file, only use the upload text feature of your terminal emulator. Do not use any of the protocols (like Kermit, YMODEM, ...). In the Windows program Teraterm, this corresponds to menu: File | Send file ... In Hyperterminal, this would be Transfer | Send text File ...
3) Also, U-boot does NOT use Hardware protocol or XON/OFF. So protocol is set to None.
4) I can not get this to work on our system (our U-boot is configured for 115200 baud). The following explanation is based on my observation. I might be wrong and please correct me if I am: U-boot can not keep up with the incoming text stream while parsing the S-records, i.e. I saw that it processed the first S0-record correctly, but when parsing the next record, it breaks off because the following record contains junk. As far as I can see, this seems to be because the Terminal program keeps sending data when U-boot is busy parsing a received S-record. Even after the S-record parser breaks off, the terminal program keeps sending the file content, which U-boot interprets a unknown commands. The junk record is basically what is left in the buffer by the time U-boot gets around to parsing the next record.
5) I was able to make this work by slowing down the file upload. In some terminal programs (like TeraTerm, menu Setup | Serial port ...) you can specify a delay after every character and a delay after every line. The above theory suggest (and was also suggested by Wolfgang) to put in a delay after every line to allow U-boot to process. However that did not work for me, even with putting in delays of 500 to 600 ms after each line. I might make it work with putting in higher values but that would be ridiculous. I was able to make it work with putting in delays after each character. Unfortunately, Teraterm and many other terminal programs do not allow delays of less than 1 msec. It works for me with a 1 msec delay after each character but at a grueling slow pace. A file of 3 Mbytes takes hours.
6) maybe I can get this to work by making the RX buffer much bigger, but haven't tried it yet.
7) Our board is based on the PowerPC-based ADS5121running at 400MHz. U-boot is configured at 115200 baud
8) People that use Kermit under Linux seem to have no problem, but I do not know in what sense their systems differ from mine.
9) Please do not suggest I switch to Linux. it is not an option. Personally I would like to, but we can not enforce this upon our clients.
10) The system I work on is a bareboard embedded system using U-boot to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux.
Ok, here is a summary of what I have found out so, with the help of Wolfgang. Many thanks.
1) Wolfgang refers to the manual for system setup: http://www.denx.de/wiki/view/DULG/SystemSetup He recommends Linux programs cu and Kermit.
2) When using the "loads" command to upload an S-record file, only use the upload text feature of your terminal emulator. Do not use any of the protocols (like Kermit, YMODEM, ...). In the Windows program Teraterm, this corresponds to menu: File | Send file ... In Hyperterminal, this would be Transfer | Send text File ...
3) Also, U-boot does NOT use Hardware protocol or XON/OFF. So protocol is set to None.
4) I can not get this to work on our system (our U-boot is configured for 115200 baud). The following explanation is based on my observation. I might be wrong and please correct me if I am: U-boot can not keep up with the incoming text stream while parsing the S-records, i.e. I saw that it processed the first S0-record correctly, but when parsing the next record, it breaks off because the following record contains junk. As far as I can see, this seems to be because the Terminal program keeps sending data when U-boot is busy parsing a received S-record. Even after the S-record parser breaks off, the terminal program keeps sending the file content, which U-boot interprets a unknown commands. The junk record is basically what is left in the buffer by the time U-boot gets around to parsing the next record.
5) I was able to make this work by slowing down the file upload. In some terminal programs (like TeraTerm, menu Setup | Serial port ...) you can specify a delay after every character and a delay after every line. The above theory suggest (and was also suggested by Wolfgang) to put in a delay after every line to allow U-boot to process. However that did not work for me, even with putting in delays of 500 to 600 ms after each line. I might make it work with putting in higher values but that would be ridiculous. I was able to make it work with putting in delays after each character. Unfortunately, Teraterm and many other terminal programs do not allow delays of less than 1 msec. It works for me with a 1 msec delay after each character but at a grueling slow pace. A file of 3 Mbytes takes hours.
6) maybe I can get this to work by making the RX buffer much bigger, but haven't tried it yet.
7) Our board is based on the PowerPC-based ADS5121running at 400MHz. U-boot is configured at 115200 baud
8) People that use Kermit under Linux seem to have no problem, but I do not know in what sense their systems differ from mine.
9) Please do not suggest I switch to Linux. it is not an option. Personally I would like to, but we can not enforce this upon our clients.
10) The system I work on is a bareboard embedded system using U-boot to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux.
On 2010/08/19 7:28 PM, Jef Mangelschots wrote:
Ok, here is a summary of what I have found out so, with the help of Wolfgang. Many thanks.
- I can not get this to work on our system (our U-boot is configured
for 115200 baud). The following explanation is based on my observation. I might be wrong and please correct me if I am: U-boot can not keep up with the incoming text stream while parsing the S-records, i.e. I saw that it processed the first S0-record correctly, but when parsing the next record, it breaks off because the following record contains junk. As far as I can see, this seems to be because the Terminal program keeps sending data when U-boot is busy parsing a received S-record. Even after the S-record parser breaks off, the terminal program keeps sending the file content, which U-boot interprets a unknown commands. The junk record is basically what is left in the buffer by the time U-boot gets around to parsing the next record.
Have you tried configuring your serial port to operate at a lower speed?
setenv baudrate 57600
should tell u-boot to adjust the serial port settings, do the same in your terminal software, and you should be able to continue. Press Enter a couple of times to get your prompt back.
While it will be slower than 115200, it will likely be better than introducing artificial delays after each character.
Rogan
Dear Jef Mangelschots,
In message AANLkTi=7zuPGN3ES_zqe6Qrwc+akB4S=JnkLNvsssj_T@mail.gmail.com you wrote:
- I can not get this to work on our system (our U-boot is configured
for 115200 baud). The following explanation is based on my observation. I might be wrong and please correct me if I am: U-boot can not keep up with the incoming text stream while parsing the S-records, i.e. I saw that it processed the first S0-record correctly, but when parsing the next record, it breaks off because the following
It is not exactly _parsing_ the record, but storing the decoded data to it's final destination, which usually includes flash programming cycles.
record contains junk. As far as I can see, this seems to be because the Terminal program keeps sending data when U-boot is busy parsing a received S-record. Even after the S-record parser breaks off, the
Right. We recommend "cu" and setting the CONFIG_LOADS_ECHO option in your board config file, because "cu" appears to implemnt a simple kind of handshake in the form that after sending a line to the target it waits until it receives a line (the echo) back. Without that, you need to insert inter-line delays.
in delays after each character. Unfortunately, Teraterm and many other terminal programs do not allow delays of less than 1 msec. It works for me with a 1 msec delay after each character but at a grueling slow pace. A file of 3 Mbytes takes hours.
Apply better tools. Use for example "expect", which allows fine-graded inter-charatcer and inter-line timings ( see the "send-slow" command). "expect" is also available for Windows, I understand.
- maybe I can get this to work by making the RX buffer much bigger,
but haven't tried it yet.
This will not help. U-Boot uses polling drivers. When it is programming the flash, it is simply nt listening on the serial port - no matter how big the buffers are.
- People that use Kermit under Linux seem to have no problem, but I
do not know in what sense their systems differ from mine.
Kermit binary protocol is not only much more eficient than S-Records, but also much more robust nd reliable.
- The system I work on is a bareboard embedded system using U-boot
to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux.
So you do have a network interface on your board? Heck, why don;t you use TFTP then???
Best regards,
Wolfgang Denk
It is not exactly _parsing_ the record, but storing the decoded data to it's final destination, which usually includes flash programming cycles.
Whenever some code takes a ASCII string (in my case an S-record), extracts fields from it, converts these to numeric values, then I call that parsing.
- People that use Kermit under Linux seem to have no problem, but I
do not know in what sense their systems differ from mine.
Kermit binary protocol is not only much more eficient than S-Records, but also much more robust nd reliable.
Yes, there is the Kermit program and the Kermit protocol implemented by many terminal programs. Kermit protocol works great for us for transferring binary files (using both Teraterm and Hyperterminal). It is my understanding that we cannot use Kermit PROTOCOL to transfer S-record files with loads command. I though you indicated that in your previous email and it simply doesn't work when I try.
The question was not about how to transfer binary files using Kermit protocol (works for us) but transferring S-record files.
I am aware that you have suggested in many places AGAINST the use of S-record, but there is a genuine use for it. When using U-boot in a non-Linux bareboard embedded system, you need a way to give your users the capability to upload now software. An embedded software image is not a 'file' like in Linux but a memory image where data needs to reside at fixed addresses. In an multi-megabyte address space, the 'executable image' can consist of chunks of data spread over a wide range. 2 options here: (1) create a binary image of the entire Flash area, (2) a file that specifies which byte go in which address, i.e. an S-record file. Option (1) results in a big file with very little. Unless you break it up in smaller pieces and ask your user to burn image 1 at offset x and image 2 at offset y, ...
- The system I work on is a bareboard embedded system using U-boot
to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux.
So you do have a network interface on your board? Heck, why don;t you use TFTP then???
I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation.
Dear Jef Mangelschots,
In message AANLkTinLu+nJp-s1BwJ+ZOcASdptWfEQr020jW2wT=b=@mail.gmail.com you wrote:
It is not exactly _parsing_ the record, but storing the decoded data to it's final destination, which usually includes flash programming cycles.
Whenever some code takes a ASCII string (in my case an S-record), extracts fields from it, converts these to numeric values, then I call that parsing.
Me too, but that's not what is taking the time. It is the flash programming cycles.
Kermit protocol works great for us for transferring binary files (using both Teraterm and Hyperterminal). It is my understanding that we cannot use Kermit PROTOCOL to transfer S-record files with loads command. I though you indicated that in your previous email and it simply doesn't work when I try.
Sorry if I was not clear enough. I always meant to refer to using kermit binary protocol in combinationwith the loadb command.
I am aware that you have suggested in many places AGAINST the use of S-record, but there is a genuine use for it. When using U-boot in a non-Linux bareboard embedded system, you need a way to give your users the capability to upload now software. An embedded software image is not a 'file' like in Linux but a memory image where data needs to reside at fixed addresses. In an multi-megabyte address space, the 'executable image' can consist of chunks of data spread over a wide range. 2 options here: (1) create a binary image of the entire Flash area, (2) a file that specifies which byte go in which address, i.e. an S-record file. Option (1) results in a big file with very little. Unless you break it up in smaller pieces and ask your user to burn image 1 at offset x and image 2 at offset y, ...
You could probably wrap the parts in a FIT image, transfer it in binary mode, and use a script to extract the parts and move them into place.
Best regards,
Wolfgang Denk
Dear Jef Mangelschots,
In message AANLkTinLu+nJp-s1BwJ+ZOcASdptWfEQr020jW2wT=b=@mail.gmail.com you wrote: ...
I am aware that you have suggested in many places AGAINST the use of S-record, but there is a genuine use for it.
BTW - there are UUCP versions for Windows out there, too. You might want to install one and try using "cu" ...
Best regards,
Wolfgang Denk
Hi Jef,
- The system I work on is a bareboard embedded system using U-boot
to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux.
So you do have a network interface on your board? Heck, why don;t you use TFTP then???
I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation.
We use tftp in U-Boot exactly because we also do not have a TCP/IP stack :)
tftp needs only udp is thus "not too complex" to implement on bare ethernet. Maybe you can implement a server on your hardware?
Just a thought...
Cheers Detlev
On 2010-08-23, Detlev Zundel dzu@denx.de wrote:
Hi Jef,
- The system I work on is a bareboard embedded system using U-boot
to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux.
So you do have a network interface on your board? Heck, why don;t you use TFTP then???
I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation.
We use tftp in U-Boot exactly because we also do not have a TCP/IP stack :)
tftp needs only udp is thus "not too complex" to implement on bare ethernet.
Doesn't "our bareboard system doesn't support Ethernet" preclude the use of Ethernet (UDP or otherwise)?
Maybe you can implement a server on your hardware?
What sort of server?
Hi Grant,
On 2010-08-23, Detlev Zundel dzu@denx.de wrote:
Hi Jef,
- The system I work on is a bareboard embedded system using U-boot
to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux.
So you do have a network interface on your board? Heck, why don;t you use TFTP then???
I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation.
We use tftp in U-Boot exactly because we also do not have a TCP/IP stack :)
tftp needs only udp is thus "not too complex" to implement on bare ethernet.
Doesn't "our bareboard system doesn't support Ethernet" preclude the use of Ethernet (UDP or otherwise)?
Yes, sorry. I was mislead by the "and not the more efficient FTP used in Linux". The pure mentioning of FTP which does not make any sense without a network port made me read the following statement not close enough.
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.
Cheers Detlev
On 2010-08-23, Detlev Zundel dzu@denx.de wrote:
I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation.
We use tftp in U-Boot exactly because we also do not have a TCP/IP stack :)
tftp needs only udp is thus "not too complex" to implement on bare ethernet.
Doesn't "our bareboard system doesn't support Ethernet" preclude the use of Ethernet (UDP or otherwise)?
Yes, sorry. I was mislead by the "and not the more efficient FTP used in Linux". The pure mentioning of FTP which does not make any sense without a network port made me read the following statement not close enough.
I thought maybe I had lost track of who posted what. :)
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.
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.
Hi Grant,
On 8/23/2010 2:10 PM, Grant Edwards wrote:
On 2010-08-23, Detlev Zundeldzu@denx.de wrote:
I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation.
We use tftp in U-Boot exactly because we also do not have a TCP/IP stack :)
tftp needs only udp is thus "not too complex" to implement on bare ethernet.
Doesn't "our bareboard system doesn't support Ethernet" preclude the use of Ethernet (UDP or otherwise)?
Yes, sorry. I was mislead by the "and not the more efficient FTP used in Linux". The pure mentioning of FTP which does not make any sense without a network port made me read the following statement not close enough.
I thought maybe I had lost track of who posted what. :)
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.
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 :)
regards, Ben
On 2010-08-23, Ben Warren biggerbadderben@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@12345678
Writes receive data into ram starting at address 12345678 (decimal).
nand@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@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@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@0x12345678:0x4321
Sends 0x4321 bytes of data from ram starting at address 0x12345678.
cmd@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@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@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.
========================================================================
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
On 2010-08-23, Detlev Zundel dzu@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@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.
participants (6)
-
Ben Warren -
Detlev Zundel -
Grant Edwards -
Jef Mangelschots -
Rogan Dawes -
Wolfgang Denk