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

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

[Jef Mangelschots]

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.

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

[Jef Mangelschots]

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.

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

[Rogan Dawes]

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.
> 

> 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.

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

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

[Wolfgang Denk]

Dear Jef Mangelschots,

In message <AANLkTi=7zuPGN3ES_zqe6Qrwc+akB4S=JnkLNvsssj_T@mail.gmail.com> you wrote:
>
> 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

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.

> 6) 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.

> 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.

Kermit binary protocol is not only much more eficient than S-Records,
but also much more robust nd reliable.

> 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.

So you do have a network interface on your board?  Heck, why don;t you
use TFTP then???

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Peace was the way.
	-- Kirk, "The City on the Edge of Forever", stardate unknown

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

[Jef Mangelschots]

> 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.


>> 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.
> 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, ...


>
>> 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.
> 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.

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A day without sunshine is like night.

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
... not meant for the weak-at-heart: /^(?=.*one)(?=.*two)/
If you can follow that, you can use it.
          - Randal L. Schwartz in <ukpw67rhl3.fsf@julie.teleport.com>

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

[Detlev Zundel]

Hi Jef,

>>> 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.
>> 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

-- 
To summarize:  It is a well known and lamented fact  that those people who
most want to  rule people are,  ipso facto, those  least suited  to do it.
To summarize the summary: anyone who is capable of getting themselves made
President should on no account be allowed to do the job.
                              -- The Hitchhikers Guide To The Galaxy
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[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@denx.de> wrote:
> Hi Jef,
>
>>>> 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.
>>> 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?

-- 
Grant Edwards               grant.b.edwards        Yow! If I pull this SWITCH
                                  at               I'll be RITA HAYWORTH!!
                              gmail.com            Or a SCIENTOLOGIST!

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

[Detlev Zundel]

Hi Grant,

> On 2010-08-23, Detlev Zundel <dzu@denx.de> wrote:
>> Hi Jef,
>>
>>>>> 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.
>>>> 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

-- 
So maybe I lost track of my point.  But if I left a mark, C-x C-x should be
all I need.
      -- David Kastrup, emacs-devel.gnu.org <87hbj37v4x.fsf@lola.goethe.zz>
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[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@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.

-- 
Grant Edwards               grant.b.edwards        Yow! Life is a POPULARITY
                                  at               CONTEST!  I'm REFRESHINGLY
                              gmail.com            CANDID!!

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

[Ben Warren]

  Hi Grant,

On 8/23/2010 2:10 PM, Grant Edwards wrote:
> 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.
>
I can see how this could be useful.  Please reconsider and we'll try to 
keep the scolding to a minimum :)

regards,
Ben

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

[Detlev Zundel]

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

-- 
... what [Microsoft] Exchange provides is *like* email, but it is *not* email.
Once you start trying to use it for real email, you find it's broken by design
in a large number of ways.  It makes no  sense for [a company] to require that
you use Exchange for Internet email, because that's not what Exchange does.
                      -- David Woodhouse <1281348164.12908.47.camel@localhost>
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

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

[Grant Edwards]

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 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!!

[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@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