[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Kim Phillips]

Make users lives easier by allowing for setting env vars such as nfsboot.

Reported-by: Brian Grayson <bgrayson@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
 include/configs/corenet_ds.h |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index adf9906..e08b034 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -618,11 +618,7 @@
 #define CONFIG_AUTO_COMPLETE			/* add autocompletion support */
 #define CONFIG_SYS_LOAD_ADDR	0x2000000	/* default load address */
 #define CONFIG_SYS_PROMPT	"=> "		/* Monitor Command Prompt */
-#ifdef CONFIG_CMD_KGDB
 #define CONFIG_SYS_CBSIZE	1024		/* Console I/O Buffer Size */
-#else
-#define CONFIG_SYS_CBSIZE	256		/* Console I/O Buffer Size */
-#endif
 #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16) /* Print Buffer Size */
 #define CONFIG_SYS_MAXARGS	16		/* max number of command args */
 #define CONFIG_SYS_BARGSIZE	CONFIG_SYS_CBSIZE	/* Boot Argument Buffer Size */
-- 
1.7.6

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Kumar Gala]

On Sep 22, 2011, at 11:38 AM, Kim Phillips wrote:

> Make users lives easier by allowing for setting env vars such as nfsboot.
> 
> Reported-by: Brian Grayson <bgrayson@freescale.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> include/configs/corenet_ds.h |    4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)

Can you explain this in a bit more detail.

- k

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Kim Phillips]

On Fri, 23 Sep 2011 13:22:08 -0500
Kumar Gala <kumar.gala@freescale.com> wrote:

> 
> On Sep 22, 2011, at 11:38 AM, Kim Phillips wrote:
> 
> > Make users lives easier by allowing for setting env vars such as nfsboot.
> > 
> > Reported-by: Brian Grayson <bgrayson@freescale.com>
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > ---
> > include/configs/corenet_ds.h |    4 ----
> > 1 files changed, 0 insertions(+), 4 deletions(-)
> 
> Can you explain this in a bit more detail.

if, for whatever reason, the nfsboot env var has been
modified/deleted, one can't restore it via the command line
because it doesn't fit in the buffer.  Currently command-line typing
stops 2 chars short of its full definition, i.e,. at the 2nd 'd' in
'fdtaddr':

=> setenv nfsboot 'setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtadd

this patch avoids this unnecessary inconvenience.

Kim

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Wolfgang Denk]

Dear Kim Phillips,

In message <20110923140020.1eac241b.kim.phillips@freescale.com> you wrote:
>
> > Can you explain this in a bit more detail.
> 
> if, for whatever reason, the nfsboot env var has been
> modified/deleted, one can't restore it via the command line
> because it doesn't fit in the buffer.  Currently command-line typing
> stops 2 chars short of its full definition, i.e,. at the 2nd 'd' in
> 'fdtaddr':
> 
> => setenv nfsboot 'setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $
> fdtadd

Instead of extending buffer sizes just to be able to enter some
incomrephensible looooong variable setting you should try and figure
out how to structure environment settings, so they become easier to
understand and to manage to the end user.

The manual holds some pretty edicative examples.

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 little knowledge is a dangerous thing."                - Doug Gwyn

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Kim Phillips]

On Sun, 25 Sep 2011 22:11:34 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Kim Phillips,
> 
> In message <20110923140020.1eac241b.kim.phillips@freescale.com> you wrote:
> >
> > > Can you explain this in a bit more detail.
> > 
> > if, for whatever reason, the nfsboot env var has been
> > modified/deleted, one can't restore it via the command line
> > because it doesn't fit in the buffer.  Currently command-line typing
> > stops 2 chars short of its full definition, i.e,. at the 2nd 'd' in
> > 'fdtaddr':
> > 
> > => setenv nfsboot 'setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $
> > fdtadd
> 
> Instead of extending buffer sizes just to be able to enter some
> incomrephensible looooong variable setting you should try and figure

this variable (which I have been comprehending for years now), is
part of the default environment configuration for that board, and
many others - it's defined in the board config file.

> out how to structure environment settings, so they become easier to
> understand and to manage to the end user.

with the amount of boardfarm users we have (recall the 'my_boot' and
'my_dtb' env vars in the grepenv rationale?), it's unrealistic to
expect all to agree on how they want to set up and use their
environment.  

We need to enable reverting an env var to its original default
definition.

> The manual holds some pretty edicative examples.

Perhaps over time the nfsboot norm setting should be migrated to
something more modular in the board config files, but right now,
users are complaining about simply expecting to being able to type
two more characters on the command line.

Kim

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Wolfgang Denk]

Dear Kim Phillips,

In message <20110926112756.bb93d41b.kim.phillips@freescale.com> you wrote:
>
> > Instead of extending buffer sizes just to be able to enter some
> > incomrephensible looooong variable setting you should try and figure
> 
> this variable (which I have been comprehending for years now), is
> part of the default environment configuration for that board, and
> many others - it's defined in the board config file.

Yes, I perfectly understand this.

However, this is not exactly a good reson not to fix (or atl east
improve) that code.

> We need to enable reverting an env var to its original default
> definition.

Do we? We have not had that feature for over a decade and nobody ever
really suffered from it. Now we have "env -f reset" for almost a
year, and guess how many percent of the users even know about this
command? And how many have ever actually used it yet?

> Perhaps over time the nfsboot norm setting should be migrated to
> something more modular in the board config files, but right now,
> users are complaining about simply expecting to being able to type
> two more characters on the command line.

Then educate your users that a boot loader is a resource restricted
environment, and that there at least 10 different ways to do what they
want, at least 8 of them resulting in a much simpler and easier to
comprehend environment setup.

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
Of course there's no reason for it, it's just our policy.

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Scott Wood]

On 09/26/2011 01:09 PM, Wolfgang Denk wrote:
> In message <20110926112756.bb93d41b.kim.phillips@freescale.com> you wrote:
>> We need to enable reverting an env var to its original default
>> definition.
> 
> Do we? We have not had that feature for over a decade and nobody ever
> really suffered from it. Now we have "env -f reset" for almost a
> year, and guess how many percent of the users even know about this
> command? And how many have ever actually used it yet?

I think he's saying that one shouldn't be prohibited by length from
manually typing "setenv nfsboot ..." to set a value that is no longer
than (or even is identical to) the default value.

>> Perhaps over time the nfsboot norm setting should be migrated to
>> something more modular in the board config files, but right now,
>> users are complaining about simply expecting to being able to type
>> two more characters on the command line.
> 
> Then educate your users that a boot loader is a resource restricted
> environment, and that there at least 10 different ways to do what they
> want, at least 8 of them resulting in a much simpler and easier to
> comprehend environment setup.

What is the resource constraint here that prevents accepting longer
console commands?  This is a change to the config for a board that comes
with multiple gigabytes of RAM.  This is not code that runs prior to
relocation.

Whether the environment scripts could, in time, be structured better is
a separate issue from whether there's a good reason to keep this
arbitrary limit at its current value that prevents people from manually
typing in what is currently being used.

-Scott

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Brian Grayson]

On Mon, Sep 26, 2011 at 04:11:14PM -0500, Scott Wood wrote:
> 
> What is the resource constraint here that prevents accepting longer
> console commands?  This is a change to the config for a board that comes
> with multiple gigabytes of RAM.  This is not code that runs prior to
> relocation.

  Exactly.  From a quick grep, around 280 configs currently
have CONFIG_SYS_CBSIZE set to 1024, while some use 512, and
over 400 boards use 256.  All we're asking is to add one more
(high-end) board family to that vaulted 1024-byte population.  Or
should all the other boards be brought down to 256 instead?  I
would think not...

  Brian Grayson

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Kim Phillips]

On Mon, 26 Sep 2011 16:11:14 -0500
Scott Wood <scottwood@freescale.com> wrote:

> On 09/26/2011 01:09 PM, Wolfgang Denk wrote:
> > In message <20110926112756.bb93d41b.kim.phillips@freescale.com> you wrote:
> >> We need to enable reverting an env var to its original default
> >> definition.
> > 
> > Do we? We have not had that feature for over a decade and nobody ever
> > really suffered from it. Now we have "env -f reset" for almost a

I have suffered.  I eventually found a trick - to omit the
$othbootargs reference in nfsboot, which would eventually come back
to haunt me when I really did want to use $othbootargs.

> > year, and guess how many percent of the users even know about this
> > command? And how many have ever actually used it yet?

That's because the author didn't include feature self-advertisement
code to setenv that detects whether a user starts setting too many
variables to values that match their original default, and goes
"<sigh> You know you could have just done an 'env -f reset',
right?" ;)

But that doesn't necessarily help either - we may want to keep some
of the other (modified) env vars, such as hw_config.

> I think he's saying that one shouldn't be prohibited by length from
> manually typing "setenv nfsboot ..." to set a value that is no longer
> than (or even is identical to) the default value.

right.

> >> Perhaps over time the nfsboot norm setting should be migrated to
> >> something more modular in the board config files, but right now,
> >> users are complaining about simply expecting to being able to type
> >> two more characters on the command line.
> > 
> > Then educate your users that a boot loader is a resource restricted
> > environment, and that there at least 10 different ways to do what they
> > want, at least 8 of them resulting in a much simpler and easier to
> > comprehend environment setup.
> 
> What is the resource constraint here that prevents accepting longer
> console commands?  This is a change to the config for a board that comes
> with multiple gigabytes of RAM.  This is not code that runs prior to
> relocation.
> 
> Whether the environment scripts could, in time, be structured better is
> a separate issue from whether there's a good reason to keep this
> arbitrary limit at its current value that prevents people from manually
> typing in what is currently being used.

right, this is a flat-out user convenience patch - it saves
development time in the short term.  The long term goal of
reprogramming hundreds of users in u-boot environment variable
theory is not the purpose here.

Kim

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Wolfgang Denk]

Dear Scott Wood,

In message <4E80EA72.3090807@freescale.com> you wrote:
>
> > Do we? We have not had that feature for over a decade and nobody ever
> > really suffered from it. Now we have "env -f reset" for almost a
> > year, and guess how many percent of the users even know about this
> > command? And how many have ever actually used it yet?
> 
> I think he's saying that one shouldn't be prohibited by length from
> manually typing "setenv nfsboot ..." to set a value that is no longer
> than (or even is identical to) the default value.

It is up to the board maintainer not to set any default values that
are longer than the buffer size he defines himself in the same config
file.

> What is the resource constraint here that prevents accepting longer
> console commands?  This is a change to the config for a board that comes
> with multiple gigabytes of RAM.  This is not code that runs prior to
> relocation.

It is simply braindead to define variables which are so long. They
are unreadable and a PITA to edit.

You don't write all your C code in a single line per function, or do
you?

> Whether the environment scripts could, in time, be structured better is
> a separate issue from whether there's a good reason to keep this
> arbitrary limit at its current value that prevents people from manually
> typing in what is currently being used.

The question is what the bug is.  My point of view is that the bug is
with a variable definition that is longer than the limit, so the
variable should be changed (as the limit is already more than
reasonably long).

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
Business is like a wheelbarrow. Nothing ever happens until you  start
pushing.

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Scott Wood]

On 09/27/2011 04:45 AM, Wolfgang Denk wrote:
> Dear Scott Wood,
> 
> In message <4E80EA72.3090807@freescale.com> you wrote:
>>
>>> Do we? We have not had that feature for over a decade and nobody ever
>>> really suffered from it. Now we have "env -f reset" for almost a
>>> year, and guess how many percent of the users even know about this
>>> command? And how many have ever actually used it yet?
>>
>> I think he's saying that one shouldn't be prohibited by length from
>> manually typing "setenv nfsboot ..." to set a value that is no longer
>> than (or even is identical to) the default value.
> 
> It is up to the board maintainer not to set any default values that
> are longer than the buffer size he defines himself in the same config
> file.

And there are two ways of fixing such a situation.

>> What is the resource constraint here that prevents accepting longer
>> console commands?  This is a change to the config for a board that comes
>> with multiple gigabytes of RAM.  This is not code that runs prior to
>> relocation.
> 
> It is simply braindead to define variables which are so long. They
> are unreadable and a PITA to edit.
> 
> You don't write all your C code in a single line per function, or do
> you?

Of course not, but this a rather different environment, that doesn't
support multiline code in the same way.  It's more like macro
substitution, and yes, there are times when I'd have C macros that are
more than 256 characters.

>> Whether the environment scripts could, in time, be structured better is
>> a separate issue from whether there's a good reason to keep this
>> arbitrary limit at its current value that prevents people from manually
>> typing in what is currently being used.
> 
> The question is what the bug is.  My point of view is that the bug is
> with a variable definition that is longer than the limit, so the
> variable should be changed (as the limit is already more than
> reasonably long).

If 256 is "more than reasonably long", are you going to force all the
boards that set it to 512 or 1024 to change?  Or does this just apply to
those boards that were unlucky enough to not have the bigger limit from
day one?

-Scott

[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024

[Wolfgang Denk]

Dear Scott Wood,

In message <4E821558.8030902@freescale.com> you wrote:
>
> > You don't write all your C code in a single line per function, or do
> > you?
> 
> Of course not, but this a rather different environment, that doesn't
> support multiline code in the same way.  It's more like macro
> substitution, and yes, there are times when I'd have C macros that are
> more than 256 characters.

Actually U-Boot does support multi-line macro definitions...

> If 256 is "more than reasonably long", are you going to force all the
> boards that set it to 512 or 1024 to change?  Or does this just apply to
> those boards that were unlucky enough to not have the bigger limit from
> day one?

Neither one nore the other.

It applies to boards that use strings in their default environment
that exceed the length of the buffer.

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
It's hard to think of you as the end result of millions of  years  of
evolution.