[U-Boot-Users] Loads function and flow control.
Hi.
I am just starting to work with loads function.
Is there any mechanism for software flow control ( XON, XOFF ) ? I have seen some define for loadb bu nothing for loads...
It seems that loads works fine when I download small files but get lost with big ones. So I fear a flow control problem.
What is the problem with minicom for loads ? I think that loads just expect to receive ascii data. Is it wrong to send srec file using ALT S in minicom ( and choosing ascii data ) ?
Chris
On Mon, May 26, 2003 at 04:37:31PM +0200, Christophe.LINDHEIMER@fr.thalesgroup.com wrote:
What is the problem with minicom for loads?
No problem if your name is not Wolfgang Denk ;)
I think that loads just expect to receive ascii data. Is it wrong to send srec file using ALT S in minicom ( and choosing ascii data ) ?
Put this into your "file transfer protocols" section:
G kermit /usr/bin/kermit -i -l %l -s Y U Y N N H kermit /usr/bin/kermit -i -l %l -r N D Y N N
Robert
Robert,
in message 20030526144315.GN24207@pengutronix.de you wrote:
What is the problem with minicom for loads?
No problem if your name is not Wolfgang Denk ;)
...except that it does not work in the default configuration, and to make it work reliably you either have to throttle speed below acceptable values, or you have to use external trools which can replace minicome (like kermit).
Put this into your "file transfer protocols" section:
G kermit /usr/bin/kermit -i -l %l -s Y U Y N N H kermit /usr/bin/kermit -i -l %l -r N D Y N N
Hereby I hand out the UUOMA (Useless Use Of Minicom Award) of the week to Robert Schwebel :-)
If you need kermit anyway, you can use it as terminal emulation program right from the beginning and avoid all the other problems.
Best regards,
Wolfgang Denk
On Mon, May 26, 2003 at 05:12:11PM +0200, Wolfgang Denk wrote:
...except that it does not work in the default configuration,
Well, it does.
make it work reliably you either have to throttle speed below acceptable values, or you have to use external trools which can replace minicome (like kermit).
... which is not a bug, IMHO. But that's of course a matter of taste.
If you need kermit anyway, you can use it as terminal emulation program right from the beginning and avoid all the other problems.
You will admit that you are using "echo" and "ed" as your main software development tools, won't you =8-) I'm using vim, so you see that I prefer modern high level approaces over stoneage tools ;)
Robert
Dear Christophe,
in message D96E2AFA0DF3D211B1390090274549480373629A@helios.gnv.tcc.thomson-csf.com you wrote:
Is there any mechanism for software flow control ( XON, XOFF ) ?
No there is none, and there is no need for one.
It seems that loads works fine when I download small files but get lost with big ones. So I fear a flow control problem.
I don't think so. Even at high baud rates (like 115200 bps) there is more than enough time to receive characters through the serial line - remember that U-Boot is strictly single-tasking, so the CPU has nothing better to do but to wait for characters.
What is the problem with minicom for loads ? I think that loads just expect
Minicom is broken.
to receive ascii data. Is it wrong to send srec file using ALT S in minicom ( and choosing ascii data ) ?
It's not exactly wrong, but it's calling for a lot of trouble. If you really must use S-Records, use the "cu" command from the UUCP package. Alternatively I recommend to use the "loadb" command and C-Kermit for the download. This is much faster, and more reliable.
Best regards,
Wolfgang Denk
On Mon, May 26, 2003 at 04:46:05PM +0200, Wolfgang Denk wrote:
No there is none, and there is no need for one.
... as the kermit protocol ensures that packets with incorrect checksums are resent.
I don't think so. Even at high baud rates (like 115200 bps) there is more than enough time to receive characters through the serial line - remember that U-Boot is strictly single-tasking, so the CPU has nothing better to do but to wait for characters.
Nevertheless there may be situations where for example cables make problems, so using a mechanism which checks if the data is correct is not the worst idea.
Minicom is broken.
Where did I know from that you would answer this...? =8-)
Robert
In message 20030526150145.GO24207@pengutronix.de you wrote:
On Mon, May 26, 2003 at 04:46:05PM +0200, Wolfgang Denk wrote:
[about flow control]
No there is none, and there is no need for one.
... as the kermit protocol ensures that packets with incorrect checksums are resent.
Flow control and checksums address two different kinds of problems. While checksumming can detect the effects of overrun problems, flow control cannot solve the other problems that can cause checksum errors.
So far, in all cases I have seen with U-Boot (including the pre- decessor projects PPCBoot and ARMBoot) the CPUs were fast enought o easily handle serial downloads using both "loadb" and "loads" at least at 115200 bps. Without any need for flow control.
I don't think so. Even at high baud rates (like 115200 bps) there is more than enough time to receive characters through the serial line - remember that U-Boot is strictly single-tasking, so the CPU has nothing better to do but to wait for characters.
Nevertheless there may be situations where for example cables make problems, so using a mechanism which checks if the data is correct is not the worst idea.
But this has nothing to do with flow control.
You are right, a protocol with error checking and recovery (like kermit binary protocol) _is_ superior to a protocol without or no protocol at all - but this was not the topic here.
Best regards,
Wolfgang Denk
What about in the case where you are loads-ing directly to a flash region? I ran across this problem recently (albeit it with PPCBoot-2.0.0).
-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Wolfgang Denk Sent: May 26, 2003 11:46 AM To: Christophe.LINDHEIMER@fr.thalesgroup.com Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Loads function and flow control.
Dear Christophe,
in message <D96E2AFA0DF3D211B1390090274549480373629A@helios.gnv.tcc.thomson-c sf.com> you wrote:
Is there any mechanism for software flow control ( XON, XOFF ) ?
No there is none, and there is no need for one.
It seems that loads works fine when I download small files but
get lost with
big ones. So I fear a flow control problem.
I don't think so. Even at high baud rates (like 115200 bps) there is more than enough time to receive characters through the serial line - remember that U-Boot is strictly single-tasking, so the CPU has nothing better to do but to wait for characters.
What is the problem with minicom for loads ? I think that loads
just expect
Minicom is broken.
to receive ascii data. Is it wrong to send srec file using ALT
S in minicom
( and choosing ascii data ) ?
It's not exactly wrong, but it's calling for a lot of trouble. If you really must use S-Records, use the "cu" command from the UUCP package. Alternatively I recommend to use the "loadb" command and C-Kermit for the download. This is much faster, and more reliable.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de panic: can't find /
This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 03May26.125207adt.7313@dragon.appliedmicro.ns.ca you wrote:
What about in the case where you are loads-ing directly to a flash region? I ran across this problem recently (albeit it with PPCBoot-2.0.0).
It worked fine in all configurations I have tested. Assume 8N1 at 115200 bps so you get a maximum of 11520 cps or about 87 us per byte. How long does your flash chip need for a byte to program?
Wolfgang Denk
I can't say off the top of my head. I'm using a 16 bit strataflash E28F128J3A in x8 mode, with a custom version of strataflash.c, on a custom-built Virtex-II Pro development board, with a *very* hacked down version of PPCboot that runs from about 50K of block RAM, so there are lots of places where I might have mucked things up. An 'interesting' configuration....
I hacked it to work by changing the loads code to echo a newline after the write to the flash has completed, and configuring kermit to wait until it sees a newline before it sends a new line. This works for me, so I stopped looking into the problem.
-Frank.
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: May 26, 2003 1:16 PM To: Frank Smith Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Loads function and flow control.
In message 03May26.125207adt.7313@dragon.appliedmicro.ns.ca you wrote:
What about in the case where you are loads-ing directly to a flash region? I ran across this problem recently (albeit it with
PPCBoot-2.0.0).
It worked fine in all configurations I have tested. Assume 8N1 at 115200 bps so you get a maximum of 11520 cps or about 87 us per byte. How long does your flash chip need for a byte to program?
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de ...the increased productivity fostered by a friendly environment and quality tools is essential to meet ever increasing demands for software. - M. D. McIlroy, E. N. Pinson and B. A. Tague
In message 03May26.133048adt.7307@dragon.appliedmicro.ns.ca you wrote:
I can't say off the top of my head. I'm using a 16 bit strataflash E28F128J3A in x8 mode, with a custom version of strataflash.c, on a custom-built Virtex-II Pro development board, with a *very* hacked down version of PPCboot that runs from about 50K of block RAM, so there are lots of places where I might have mucked things up. An 'interesting' configuration....
:-)
I hacked it to work by changing the loads code to echo a newline after the write to the flash has completed, and configuring kermit to wait until it sees a newline before it sends a new line. This works for me, so I stopped looking into the problem.
Ummm... "loads" allows to echo each input character depending on the setting of the "loads_echo" environment variable. This is something which is used by "cu", IIRC.
Best regards,
Wolfgang Denk
participants (5)
-
Christophe.LINDHEIMER＠fr.thalesgroup.com -
Frank Smith -
Robert Schwebel -
Robert Schwebel -
Wolfgang Denk