[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