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

Kim Phillips kim.phillips at freescale.com
Tue Sep 27 00:55:02 CEST 2011


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

> On 09/26/2011 01:09 PM, Wolfgang Denk wrote:
> > In message <20110926112756.bb93d41b.kim.phillips at 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



More information about the U-Boot mailing list