[U-Boot] [PATCH] powerpc/85xx: corenet_ds: increase console buffer size to 1024
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 */
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
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
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
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
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
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
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
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
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
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
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
participants (5)
-
Brian Grayson -
Kim Phillips -
Kumar Gala -
Scott Wood -
Wolfgang Denk