[U-Boot-Users] [PATCH] 1/5: cmd_boot

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

Hi, 

here are some last minute patches, I hope Wolfgang has time to check
them in before the release. 

-----

cmd_boot: 

- fix whitespace for bdinfo command
- fix garbage characters output
- add ctrl-c support for kermit download

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4
-------------- next part --------------
diff -x CVS -x ptx-patches -urN u-boot/common/cmd_boot.c u-boot-ptx/common/cmd_boot.c
--- u-boot/common/cmd_boot.c	2003-03-31 08:34:19.000000000 +0200
+++ u-boot-ptx/common/cmd_boot.c	2003-03-31 08:39:33.000000000 +0200
@@ -163,10 +163,10 @@
 		printf ("%c%02X", i ? ':' : ' ', bd->bi_enetaddr[i]);
 	}
 	printf ("\n"
-		"ip_addr       = ");
+		"ip_addr     = ");
 	print_IPaddr (bd->bi_ip_addr);
 	printf ("\n"
-		"baudrate      = %d bps\n", bd->bi_baudrate);
+		"baudrate    = %d bps\n", bd->bi_baudrate);
 
 	return 0;
 }
@@ -575,6 +575,7 @@
 #define XON_CHAR        17
 #define XOFF_CHAR       19
 #define START_CHAR      0x01
+#define ETX_CHAR	0x03
 #define END_CHAR        0x0D
 #define SPACE           0x20
 #define K_ESCAPE        0x23
@@ -687,11 +688,24 @@
 
 static ulong load_serial_bin (ulong offset)
 {
-	int size;
+	int size, i;
 	char buf[32];
 
 	set_kerm_bin_mode ((ulong *) offset);
 	size = k_recv ();
+
+	/*
+	 * Gather any trailing characters (for instance, the ^D which
+	 * is sent by 'cu' after sending a file), and give the
+	 * box some time (100 * 1 ms)
+	 */
+	for (i=0; i<100; ++i) {
+		if (serial_tstc()) {
+			(void) serial_getc();
+		}
+		udelay(1000);
+	}
+
 	flush_cache (offset, size);
 
 	printf("## Total Size      = 0x%08x = %d Bytes\n", size, size);
@@ -996,10 +1011,16 @@
 
 		/* get a packet */
 		/* wait for the starting character */
-		while (serial_getc () != START_CHAR);
+		do {
+			new_char = serial_getc();
+			if (new_char == ETX_CHAR) return 0;
+
+		} while (new_char != START_CHAR);
+
 		/* get length of packet */
 		sum = 0;
 		new_char = serial_getc ();
+
 		if ((new_char & 0xE0) == 0)
 			goto packet_error;
 		sum += new_char & 0xff;

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <20030331092850.GL7702@pengutronix.de> you wrote:
> 
> here are some last minute patches, I hope Wolfgang has time to check
> them in before the release. 
> 
> -----
> 
> cmd_boot: 
> 
> - fix whitespace for bdinfo command
> - fix garbage characters output
> - add ctrl-c support for kermit download

See below.

> --- u-boot/common/cmd_boot.c	2003-03-31 08:34:19.000000000 +0200
> +++ u-boot-ptx/common/cmd_boot.c	2003-03-31 08:39:33.000000000 +0200
> @@ -163,10 +163,10 @@
>  		printf ("%c%02X", i ? ':' : ' ', bd->bi_enetaddr[i]);
>  	}
>  	printf ("\n"
> -		"ip_addr       = ");
> +		"ip_addr     = ");
>  	print_IPaddr (bd->bi_ip_addr);
>  	printf ("\n"
> -		"baudrate      = %d bps\n", bd->bi_baudrate);
> +		"baudrate    = %d bps\n", bd->bi_baudrate);

Which "whitespace" problem are you trying to fix? To me  the  current
output looks good:

	=> bdi
	memstart    = 0x00000000
	memsize     = 0x01000000
	flashstart  = 0x40000000
	flashsize   = 0x00800000
	flashoffset = 0x00040000
	sramstart   = 0x00000000
	sramsize    = 0x00000000
	immr_base   = 0xFFF00000
	bootflags   = 0x00000001
	intfreq     =     50 MHz
	busfreq     =     50 MHz
	ethaddr     = 00:D0:93:00:7B:8B
	IP addr     = 10.0.0.99
	baudrate    = 115200 bps


> @@ -575,6 +575,7 @@
>  #define XON_CHAR        17
>  #define XOFF_CHAR       19
>  #define START_CHAR      0x01
> +#define ETX_CHAR	0x03
>  #define END_CHAR        0x0D
>  #define SPACE           0x20
>  #define K_ESCAPE        0x23
> @@ -687,11 +688,24 @@
>  
>  static ulong load_serial_bin (ulong offset)
>  {
> -	int size;
> +	int size, i;
>  	char buf[32];
>  
>  	set_kerm_bin_mode ((ulong *) offset);
>  	size = k_recv ();
> +
> +	/*
> +	 * Gather any trailing characters (for instance, the ^D which
> +	 * is sent by 'cu' after sending a file), and give the
> +	 * box some time (100 * 1 ms)
> +	 */
> +	for (i=0; i<100; ++i) {
> +		if (serial_tstc()) {
> +			(void) serial_getc();
> +		}
> +		udelay(1000);
> +	}

This makes no sense to  me.  load_serial_bin()  is  used  for  kermit
serial  protocol download, but "cu" is used for S-Record (ASCII file)
download. So how would "cu" disturb load_serial_bin() ?

Can you please explain which problem you are trying to fix?


>  		/* wait for the starting character */
> -		while (serial_getc () != START_CHAR);
> +		do {
> +			new_char = serial_getc();
> +			if (new_char == ETX_CHAR) return 0;
> +
> +		} while (new_char != START_CHAR);
> +

Will add this.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
If there are self-made purgatories, then we all have to live in them.
	-- Spock, "This Side of Paradise", stardate 3417.7

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

On Mon, Mar 31, 2003 at 12:12:09PM +0200, Wolfgang Denk wrote:
> Which "whitespace" problem are you trying to fix? To me  the  current
> output looks good:
> 
> 	=> bdi
> 	memstart    = 0x00000000
> 	memsize     = 0x01000000
> 	flashstart  = 0x40000000
> 	flashsize   = 0x00800000
> 	flashoffset = 0x00040000
> 	sramstart   = 0x00000000
> 	sramsize    = 0x00000000
> 	immr_base   = 0xFFF00000
> 	bootflags   = 0x00000001
> 	intfreq     =     50 MHz
> 	busfreq     =     50 MHz
> 	ethaddr     = 00:D0:93:00:7B:8B
> 	IP addr     = 10.0.0.99
> 	baudrate    = 115200 bps

... but you have tried it on ppc, not on ARM :-) Your = is in column 13,
and so it is in my patch. 

> > +	/*
> > +	 * Gather any trailing characters (for instance, the ^D which
> > +	 * is sent by 'cu' after sending a file), and give the
> > +	 * box some time (100 * 1 ms)
> > +	 */
> > +	for (i=0; i<100; ++i) {
> > +		if (serial_tstc()) {
> > +			(void) serial_getc();
> > +		}
> > +		udelay(1000);
> > +	}
> 
> This makes no sense to  me.  load_serial_bin()  is  used  for  kermit
> serial  protocol download, but "cu" is used for S-Record (ASCII file)
> download. So how would "cu" disturb load_serial_bin() ?

Oops, documentation-cut-and-paste error. It's the same with kermit.
Without the code (which was there before including the comment, I just
moved it to the proper position, which I forgot in the last patch you've
already applied). 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <20030331103351.GQ7702@pengutronix.de> you wrote:
>
> ... but you have tried it on ppc, not on ARM :-) Your = is in column 13,
> and so it is in my patch. 

I see. Thanks for the explanation -- added.

> Oops, documentation-cut-and-paste error. It's the same with kermit.
> Without the code (which was there before including the comment, I just
> moved it to the proper position, which I forgot in the last patch you've
> already applied). 

I never experienced any problems with the kermit code, and I used  it
a  lot.  Can  you please describe in detail how you use it, and which
sort of problems you have?

You are _not_ using minicom by any chance?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
A meeting is an event at which the minutes are kept and the hours are
lost.

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

On Mon, Mar 31, 2003 at 12:55:53PM +0200, Wolfgang Denk wrote:
> > Oops, documentation-cut-and-paste error. It's the same with kermit.
> > Without the code (which was there before including the comment, I just
> > moved it to the proper position, which I forgot in the last patch you've
> > already applied). 
> 
> I never experienced any problems with the kermit code, and I used  it
> a  lot.  Can  you please describe in detail how you use it, and which
> sort of problems you have?
> 
> You are _not_ using minicom by any chance?

I do, and nobody was able to explain me why it should be bad. It simply
works with all other firmwares and it works with U-Boot with the patch. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <20030331111225.GT7702@pengutronix.de> you wrote:
>
> > You are _not_ using minicom by any chance?
> 
> I do, and nobody was able to explain me why it should be bad. It simply
> works with all other firmwares and it works with U-Boot with the patch. 

I recommend to kermit directly, and there will  be  no  problem.  The
patch  adds  code size in a critical area (there are some boards with
memory limitations) and does not fix any real  problem  (instead,  it
implements a workaround for other broken software).


Does anybody else really _need_ this patch?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It is much easier to suggest solutions when you know nothing

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

On Mon, Mar 31, 2003 at 01:38:00PM +0200, Wolfgang Denk wrote:
> I recommend to kermit directly, and there will  be  no  problem.  The
> patch  adds  code size in a critical area (there are some boards with
> memory limitations) and does not fix any real  problem  (instead,  it
> implements a workaround for other broken software).

Come on, minicom is by large the most used terminal program on Linux,
and I suppose u-boot should work with it. Don't tell me that I'm the
only one using it - nearly EVERYONE who works with serial hardware
(terminal servers, serve consoles, embedded boards) does it with minicom
today, and u-boot is the only firmware I've seen problems with so far. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Chris Elston]

Is there any reason we can't have an '#ifdef MINICOM'?

Chris.

> -----Original Message-----
> From: Robert Schwebel [mailto:robert at schwebel.de]
> Sent: 31 March 2003 12:45
> To: U-Boot Mailing List
> Subject: Re: [U-Boot-Users] [PATCH] 1/5: cmd_boot
> 
> 
> On Mon, Mar 31, 2003 at 01:38:00PM +0200, Wolfgang Denk wrote:
> > I recommend to kermit directly, and there will  be  no  
> problem.  The
> > patch  adds  code size in a critical area (there are some 
> boards with
> > memory limitations) and does not fix any real  problem  
> (instead,  it
> > implements a workaround for other broken software).
> 
> Come on, minicom is by large the most used terminal program on Linux,
> and I suppose u-boot should work with it. Don't tell me that I'm the
> only one using it - nearly EVERYONE who works with serial hardware
> (terminal servers, serve consoles, embedded boards) does it 
> with minicom
> today, and u-boot is the only firmware I've seen problems 
> with so far. 
> 
> Robert 
> -- 
>  Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
>  Pengutronix - Linux Solutions for Science and Industry
>    Braunschweiger Str. 79,  31134 Hildesheim, Germany
>    Handelsregister:  Amtsgericht Hildesheim, HRA 2686
>     Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
> ______________________________________________________________
> __________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ______________________________________________________________
> __________
> 

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <20030331114517.GW7702@pengutronix.de> you wrote:
> On Mon, Mar 31, 2003 at 01:38:00PM +0200, Wolfgang Denk wrote:
> > I recommend to kermit directly, and there will  be  no  problem.  The
> > patch  adds  code size in a critical area (there are some boards with
> > memory limitations) and does not fix any real  problem  (instead,  it
> > implements a workaround for other broken software).
> 
> Come on, minicom is by large the most used terminal program on Linux,

That does not mean that it doesn't show some weird behaviour.

> and I suppose u-boot should work with it. Don't tell me that I'm the

Ummm... if there are better. working alternatives I feel  tempted  to
ignore broken software.

> only one using it - nearly EVERYONE who works with serial hardware
> (terminal servers, serve consoles, embedded boards) does it with minicom

Really? I don't. And I don't recommend it. Instead,  I  recommend  to
ignore  it.  I  see little advanteages. Use Ckermit - it is much more
flexible, it works, and it it available for a  plethora  of  systems,
not only Linux.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
What was sliced bread the greatest thing since?

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Chris Elston]

I don't use minicom myself, all our targets have ethernet as a minimum.  But
wouldn't including the patch with an '#ifdef MINICOM' be a reasonable
compromise?

Chris.

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: 31 March 2003 13:35
> To: Chris Elston
> Cc: U-Boot Mailing List (E-mail)
> Subject: Re: [U-Boot-Users] [PATCH] 1/5: cmd_boot 
> 
> 
> In message 
> <A1DD009E87CDD2119E940008C7334DA402339AFF@exchange01> you wrote:
> > Is there any reason we can't have an '#ifdef MINICOM'?
> 
> Ar you just asking, or do you really experience any  minicom  related
> problems your own? [Why do you use it, then?]
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> It is impractical for  the  standard  to  attempt  to  constrain  the
> behavior  of code that does not obey the constraints of the standard.
>                                                           - Doug Gwyn
> 
> ______________________________________________________________
> __________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ______________________________________________________________
> __________
> 

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <A1DD009E87CDD2119E940008C7334DA402339AFF@exchange01> you wrote:
> Is there any reason we can't have an '#ifdef MINICOM'?

Ar you just asking, or do you really experience any  minicom  related
problems your own? [Why do you use it, then?]


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
                                                          - Doug Gwyn

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

On Mon, Mar 31, 2003 at 02:31:56PM +0200, Wolfgang Denk wrote:
> That does not mean that it doesn't show some weird behaviour.

Are you sure the weird behaviour comes from minicom? Or is it the
combination of minicom and some of it's backend programs? 

> Ummm... if there are better. working alternatives I feel  tempted  to
> ignore broken software.

I generally have no problem with using stone aged software, but for a
terminal program (which is also used by non-hackers) I prefer using
something with at least a _little_ bit of usability comfort (menues and
stuff). Unfortunately, there is no better thing than minicom around for
Linux...

> Really? I don't. And I don't recommend it. Instead,  I  recommend  to
> ignore  it.  I  see little advanteages. Use Ckermit - it is much more
> flexible, it works, and it it available for a  plethora  of  systems,
> not only Linux.

People use it, so it should be supported. Other question: does my patch
do any harm to your ckermit? If not, what's the problem? 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Jerry Van Baren]

There is another reasonable compromise (that Wolfgang will endorse, I'm 
sure :-).  I looked at minicom, and it uses "ascii-xfr -dsv" to send an 
ASCII file.  The "-d" says to send ^D as the end-of-file marker.  The only 
other alternative is ^Z, which is no good either.

I suggest the <proper> approach to this is to get the source to ascii-xfr 
and add a parameter to suppress sending _anything_ as a "EOF" marker.  Then 
there should not be any issue.

Hmmm, I just downloaded minicom 2.0 and looked at ascii-xfr.c -- it uses 
the flag "-e" to tell minicom to send the EOF (or not) and the "-d" flag to 
select ^D vs. ^Z, so it looks like all you need to do is upgrade your 
minicom and change your ASCII download configuration to be "ascii-xfr -esv".

Usage: ascii-xfr -s|-r [-dvn] [-l linedelay] [-c character delay] filename
        -s:  send
        -r:  receive
        -e:  send the End Of File character (default is not to)
        -d:  set End Of File character to Control-D (instead of Control-Z)
        -v:  verbose (statistics on stderr output)
        -n:  do not translate CRLF <--> LF
        Delays are in milliseconds.

gvb


At 01:32 PM 3/31/2003 -0500, elston at radstone.co.uk wrote:
>I don't use minicom myself, all our targets have ethernet as a minimum.  But
>wouldn't including the patch with an '#ifdef MINICOM' be a reasonable
>compromise?
>
>Chris.
>
> > -----Original Message-----
> > From: Wolfgang Denk [mailto:wd at denx.de]
> > Sent: 31 March 2003 13:35
> > To: Chris Elston
> > Cc: U-Boot Mailing List (E-mail)
> > Subject: Re: [U-Boot-Users] [PATCH] 1/5: cmd_boot
> >
> >
> > In message
> > <A1DD009E87CDD2119E940008C7334DA402339AFF@exchange01> you wrote:
> > > Is there any reason we can't have an '#ifdef MINICOM'?
> >
> > Ar you just asking, or do you really experience any  minicom  related
> > problems your own? [Why do you use it, then?]
> >
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > --
> > Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> > Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> > It is impractical for  the  standard  to  attempt  to  constrain  the
> > behavior  of code that does not obey the constraints of the standard.
> >                                                           - Doug Gwyn
> >
> > ______________________________________________________________
> > __________
> > This e-mail has been scanned for all viruses by Star Internet. The
> > service is powered by MessageLabs. For more information on a proactive
> > anti-virus service working around the clock, around the globe, visit:
> > http://www.star.net.uk
> > ______________________________________________________________
> > __________
> >
>
>________________________________________________________________________
>This e-mail has been scanned for all viruses by Star Internet. The
>service is powered by MessageLabs. For more information on a proactive
>anti-virus service working around the clock, around the globe, visit:
>http://www.star.net.uk
>________________________________________________________________________
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ValueWeb:
>Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
>No other company gives more support or power for your dedicated server
>http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
>_______________________________________________
>U-Boot-Users mailing list
>U-Boot-Users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users



**********************************************************************
This e-mail and any files transmitted with it are confidential and may
be legally privileged or otherwise exempt from disclosure under
applicable law. This e-mail and its files are intended solely for
the individual or entity to whom they are addressed and their content
is the property of Smiths Aerospace.  If you are not the intended
recipient, please do not read, copy, use or disclose this communication.
If you have received this e-mail in error please notify the e-mail 
administrator at postmaster at si.com and then delete this e-mail, its
files and any copies.

This footnote also confirms that this e-mail message has been scanned
for the presence of known computer viruses.
***********************************************************************

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

On Mon, Mar 31, 2003 at 08:18:20AM -0500, Jerry Van Baren wrote:
> Hmmm, I just downloaded minicom 2.0 and looked at ascii-xfr.c -- it
> uses the flag "-e" to tell minicom to send the EOF (or not) and the
> "-d" flag to select ^D vs. ^Z, so it looks like all you need to do is
> upgrade your minicom and change your ASCII download configuration to
> be "ascii-xfr -esv".

The problem happened with download via kermit, not with ascii-xfr. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Jerry Van Baren]

Well, then switch back to ascii-xfr :-P  ;-)

Seriously, if you are running kermit to do the transfer using minicom, why 
bother with minicom?  Document for your users how to use kermit and make 
them type the commands -- menus aren't everything and minicom's menus are 
anything to write home about anyway.

gvb


At 03:41 PM 3/31/2003 -0500, robert at schwebel.de wrote:
>On Mon, Mar 31, 2003 at 08:18:20AM -0500, Jerry Van Baren wrote:
> > Hmmm, I just downloaded minicom 2.0 and looked at ascii-xfr.c -- it
> > uses the flag "-e" to tell minicom to send the EOF (or not) and the
> > "-d" flag to select ^D vs. ^Z, so it looks like all you need to do is
> > upgrade your minicom and change your ASCII download configuration to
> > be "ascii-xfr -esv".
>
>The problem happened with download via kermit, not with ascii-xfr.
>
>Robert
>--
>  Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
>  Pengutronix - Linux Solutions for Science and Industry
>    Braunschweiger Str. 79,  31134 Hildesheim, Germany
>    Handelsregister:  Amtsgericht Hildesheim, HRA 2686
>     Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ValueWeb:
>Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
>No other company gives more support or power for your dedicated server
>http://click.atdmt.com/AFF/go/sdnxxaff003



**********************************************************************
This e-mail and any files transmitted with it are confidential and may
be legally privileged or otherwise exempt from disclosure under
applicable law. This e-mail and its files are intended solely for
the individual or entity to whom they are addressed and their content
is the property of Smiths Aerospace.  If you are not the intended
recipient, please do not read, copy, use or disclose this communication.
If you have received this e-mail in error please notify the e-mail 
administrator at postmaster at si.com and then delete this e-mail, its
files and any copies.

This footnote also confirms that this e-mail message has been scanned
for the presence of known computer viruses.
***********************************************************************

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <20030331124357.GA7702@pengutronix.de> you wrote:
> On Mon, Mar 31, 2003 at 02:31:56PM +0200, Wolfgang Denk wrote:
> > That does not mean that it doesn't show some weird behaviour.
> 
> Are you sure the weird behaviour comes from minicom? Or is it the
> combination of minicom and some of it's backend programs? 

I don't know.

> stuff). Unfortunately, there is no better thing than minicom around for
> Linux...

Ummm... YMMV, but IMHO a working  tool  is  _always_  better  than  a
broken one, no matter which user interface it has.

> People use it, so it should be supported. Other question: does my patch
> do any harm to your ckermit? If not, what's the problem? 

Code size. Yes, even these few bytes.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Life would be so much easier if we could  just  look  at  the  source
code.                                                   -- Dave Olson

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <5.1.0.14.2.20030331080614.02611dc0@falcon.si.com> you wrote:
> There is another reasonable compromise (that Wolfgang will endorse, I'm 
> sure :-).  I looked at minicom, and it uses "ascii-xfr -dsv" to send an 

Thanks, Jerry.

> Hmmm, I just downloaded minicom 2.0 and looked at ascii-xfr.c -- it uses 
> the flag "-e" to tell minicom to send the EOF (or not) and the "-d" flag to 
> select ^D vs. ^Z, so it looks like all you need to do is upgrade your 
> minicom and change your ASCII download configuration to be "ascii-xfr -esv".

But Robert was talking about  kermit  _binary_  download.  Will  this
still use ascii-xfr.c at all?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Quantum Mechanics is God's version of "Trust me."

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

On Mon, Mar 31, 2003 at 04:03:45PM +0200, Wolfgang Denk wrote:
> Ummm... YMMV, but IMHO a working  tool  is  _always_  better  than  a
> broken one, no matter which user interface it has.

Above you stated that you don't know if minicom is broken or if it has
another reason. 

> > People use it, so it should be supported. Other question: does my patch
> > do any harm to your ckermit? If not, what's the problem? 
> 
> Code size. Yes, even these few bytes.

Wolfgang, the code has been in that file for ages. The only thing I did
is to move it to the right location, which is _before_ the printf() in
load_serial_bin(), not _after_ the function returned. Please explain why
moving code changes the binary size. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Holger Schurig]

> The problem happened with download via kermit, not with ascii-xfr.

In this case change the command string for kernel downloads in Minicom so that 
it uses ckermit for the download --- you don't have to like the ckermit "UI" 
to use it for batch file transfer.

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <20030331141607.GI7702@pengutronix.de> you wrote:
>
> Wolfgang, the code has been in that file for ages. The only thing I did
> is to move it to the right location, which is _before_ the printf() in
> load_serial_bin(), not _after_ the function returned. Please explain why
> moving code changes the binary size. 

You patch does not delete code, but  it  adds  code,  increasing  the
size:

--- u-boot/common/cmd_boot.c	2003-03-31 08:34:19.000000000 +0200
+++ u-boot-ptx/common/cmd_boot.c	2003-03-31 08:39:33.000000000 +0200
@@ -163,10 +163,10 @@
 		printf ("%c%02X", i ? ':' : ' ', bd->bi_enetaddr[i]);
 	}
 	printf ("\n"
-		"ip_addr       = ");
+		"ip_addr     = ");
 	print_IPaddr (bd->bi_ip_addr);
 	printf ("\n"
-		"baudrate      = %d bps\n", bd->bi_baudrate);
+		"baudrate    = %d bps\n", bd->bi_baudrate);
 
 	return 0;
 }
@@ -575,6 +575,7 @@
 #define XON_CHAR        17
 #define XOFF_CHAR       19
 #define START_CHAR      0x01
+#define ETX_CHAR	0x03
 #define END_CHAR        0x0D
 #define SPACE           0x20
 #define K_ESCAPE        0x23
@@ -687,11 +688,24 @@
 
 static ulong load_serial_bin (ulong offset)
 {
-	int size;
+	int size, i;
 	char buf[32];
 
 	set_kerm_bin_mode ((ulong *) offset);
 	size = k_recv ();
+
+	/*
+	 * Gather any trailing characters (for instance, the ^D which
+	 * is sent by 'cu' after sending a file), and give the
+	 * box some time (100 * 1 ms)
+	 */
+	for (i=0; i<100; ++i) {
+		if (serial_tstc()) {
+			(void) serial_getc();
+		}
+		udelay(1000);
+	}
+
 	flush_cache (offset, size);
 
 	printf("## Total Size      = 0x%08x = %d Bytes\n", size, size);
...


Let's wait a day if anybody speaks up who has the same  problem  like
you. if not, I will ignore this.

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
If it happens once, it's a bug.
If it happens twice, it's a feature.
If it happens more than twice, it's a design philosophy.

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

On Mon, Mar 31, 2003 at 04:47:32PM +0200, Wolfgang Denk wrote:
> You patch does not delete code, but  it  adds  code,  increasing  the
> size:

We are talking about this piece of code, right? 

> +
> +	/*
> +	 * Gather any trailing characters (for instance, the ^D which
> +	 * is sent by 'cu' after sending a file), and give the
> +	 * box some time (100 * 1 ms)
> +	 */
> +	for (i=0; i<100; ++i) {
> +		if (serial_tstc()) {
> +			(void) serial_getc();
> +		}
> +		udelay(1000);
> +	}
> +

Exactly this code sniplet was located directly after the call to
load_serial_bin() in cmd_boot.c:do_load_serial_bin() before I started
looking for the problems. When I sent my first patch which _removed_
this code I somehow forgot to send you the hunk which adds it at the
right place. So this patch does not add new code, it only re-adds the
hunk which was removed instead of re-located to the right place.

Before: 
	load_serial_bin();
		download via kermit
		say "I'm finished"
	throw away garbage characters
	go on

Now: 
	load_serial_bin();
		download via kermit
		throw away garbage characters
		say "I'm finished"
	go on. 

I hope you understand what I mean... 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

On Mon, Mar 31, 2003 at 09:00:23AM -0500, Jerry Van Baren wrote:
> Well, then switch back to ascii-xfr :-P  ;-)
> 
> Seriously, if you are running kermit to do the transfer using minicom, why 
> bother with minicom?  Document for your users how to use kermit and make 
> them type the commands -- menus aren't everything and minicom's menus are 
> anything to write home about anyway.

Users may use Linux or Windows for their console machine, so the
transfer protocol has to be machine independend and should be available
out of the box on most of the machines out there. Which limits it to
xmodem, zmodem and kermit. 

Folks, Linux is about having the choice. I like the user interface of
minicom better than that one of a command line tool like ckermit. U-Boot
shouldn't force people on one policy.

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Jerry Van Baren]

At 04:06 PM 3/31/2003 -0500, wd at denx.de wrote:
>In message <5.1.0.14.2.20030331080614.02611dc0@falcon.si.com> you wrote:
> > There is another reasonable compromise (that Wolfgang will endorse, I'm
> > sure :-).  I looked at minicom, and it uses "ascii-xfr -dsv" to send an
>
>Thanks, Jerry.
>
> > Hmmm, I just downloaded minicom 2.0 and looked at ascii-xfr.c -- it uses
> > the flag "-e" to tell minicom to send the EOF (or not) and the "-d" 
> flag to
> > select ^D vs. ^Z, so it looks like all you need to do is upgrade your
> > minicom and change your ASCII download configuration to be "ascii-xfr 
> -esv".
>
>But Robert was talking about  kermit  _binary_  download.  Will  this
>still use ascii-xfr.c at all?

No.  My mistake, sorry.  I got all excited about finding the ^D reference 
in the ascii-xfr command.

Since I put my left foot in my mouth already, let's see if the right foot 
will fit... why doesn't "cat" work for binary transfer?  It seems like 
"cat" (IO-Red. set to "Y") should work for minicom.

gvb


>Best regards,
>
>Wolfgang Denk



**********************************************************************
This e-mail and any files transmitted with it are confidential and may
be legally privileged or otherwise exempt from disclosure under
applicable law. This e-mail and its files are intended solely for
the individual or entity to whom they are addressed and their content
is the property of Smiths Aerospace.  If you are not the intended
recipient, please do not read, copy, use or disclose this communication.
If you have received this e-mail in error please notify the e-mail 
administrator at postmaster at si.com and then delete this e-mail, its
files and any copies.

This footnote also confirms that this e-mail message has been scanned
for the presence of known computer viruses.
***********************************************************************

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <5.1.0.14.2.20030331100849.02682620@falcon.si.com> you wrote:
>
> Since I put my left foot in my mouth already, let's see if the right foot 
> will fit... why doesn't "cat" work for binary transfer?  It seems like 
> "cat" (IO-Red. set to "Y") should work for minicom.

It doesn't work because the code implements kermit  binary  protocol,
which is more than a binary stream of data.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Military secrets are the most fleeting of all.
	-- Spock, "The Enterprise Incident", stardate 5027.4

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <20030331151712.GL7702@pengutronix.de> you wrote:
>
> > Seriously, if you are running kermit to do the transfer using minicom, why 
> > bother with minicom?  Document for your users how to use kermit and make 
> > them type the commands -- menus aren't everything and minicom's menus are 
> > anything to write home about anyway.
> 
> Users may use Linux or Windows for their console machine, so the
> transfer protocol has to be machine independend and should be available
> out of the box on most of the machines out there. Which limits it to
> xmodem, zmodem and kermit. 

Don't forget S-Record. Actually most  people  I've  seen  working  on
windoze   boxen  preferred  S-Record  download  using  hyperterm  (or
whatever this tool was called).

> Folks, Linux is about having the choice. I like the user interface of
> minicom better than that one of a command line tool like ckermit. U-Boot
> shouldn't force people on one policy.

You write: "the transfer protocol has to be machine  independend  and
should  be  available  out  of  the  box  on most of the machines out
there".

Please name a terminal program that is available in  a  more  machine
independend way or on more machines out there than CKermit.


To me the only logical conclusion of your own arguments is  that  you
should be using CKermit.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The software required `Windows 95 or better', so I installed Linux.

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Wolfgang Denk]

In message <20030331150355.GK7702@pengutronix.de> you wrote:
>
> Exactly this code sniplet was located directly after the call to
> load_serial_bin() in cmd_boot.c:do_load_serial_bin() before I started
> looking for the problems. When I sent my first patch which _removed_
> this code I somehow forgot to send you the hunk which adds it at the
> right place. So this patch does not add new code, it only re-adds the
> hunk which was removed instead of re-located to the right place.

Aaaaarggghhh.... why didn't you clearly say so?

Added.

And it would be really nice if you didn't split two parts of the same
patch over a distance of 12+ days :-(

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Actual war is a very messy business. Very, very messy business.
	-- Kirk, "A Taste of Armageddon", stardate 3193.0

[U-Boot-Users] [PATCH] 1/5: cmd_boot

[Robert Schwebel]

On Mon, Mar 31, 2003 at 08:10:01PM +0200, Wolfgang Denk wrote:
> Aaaaarggghhh.... why didn't you clearly say so?

I tried my best... 

> And it would be really nice if you didn't split two parts of the same
> patch over a distance of 12+ days :-(

Sorry, it was just a mistake...

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4