[U-Boot-Users] Silent console enhancement patch
The silent console as currently implemented is not silent if a board has been newly manufactured. I.e., some messages are printed prior to being able to set the "silent" environment variable the first time.
The following patch adds a new configuration option, CONFIG_VERY_SILENT_CONSOLE, which modifies the behavior slightly. If this option is selected, then the absence of the "silent" variable will result in a default behavior of "silent". Also, if "silent" is set to "1", then the behavior will be "silent". Only if a different value, say "0", is selected will the behavior be "verbose".
This patch doesn't change the behavior for any existing BSP's because they will not have selected the CONFIG_VERY_SILENT_CONSOLE option.
Signed-off-by: Steve Falco sfalco@harris.com
diff --git a/common/console.c b/common/console.c index d8a0cb6..4c98eef 100644 --- a/common/console.c +++ b/common/console.c @@ -361,12 +361,22 @@ int console_assign (int file, char *devname) /* Called before relocation - use serial functions */ int console_init_f (void) { +#ifdef CONFIG_VERY_SILENT_CONSOLE + char *pSilent; +#endif + gd->have_console = 1;
#ifdef CONFIG_SILENT_CONSOLE +#ifdef CONFIG_VERY_SILENT_CONSOLE + pSilent = getenv("silent"); + if(!pSilent || *pSilent == '1') + gd->flags |= GD_FLG_SILENT; +#else if (getenv("silent") != NULL) gd->flags |= GD_FLG_SILENT; #endif +#endif
return (0); }
In message 48515F51.5030504@harris.com you wrote:
The silent console as currently implemented is not silent if a board has been newly manufactured. I.e., some messages are printed prior to being able to set the "silent" environment variable the first time.
The following patch adds a new configuration option, CONFIG_VERY_SILENT_CONSOLE, which modifies the behavior slightly. If this option is selected, then the absence of the "silent" variable will result in a default behavior of "silent". Also, if "silent" is set to "1", then the behavior will be "silent". Only if a different value, say "0", is selected will the behavior be "verbose".
This patch doesn't change the behavior for any existing BSP's because they will not have selected the CONFIG_VERY_SILENT_CONSOLE option.
I consider this seriously confusing.
Also I don't see what your problem is, assuming you provide a valid environment with your newly manufactured systems.
I thend to reject this patch.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 48515F51.5030504@harris.com you wrote:
The silent console as currently implemented is not silent if a board has been newly manufactured. I.e., some messages are printed prior to being able to set the "silent" environment variable the first time.
The following patch adds a new configuration option, CONFIG_VERY_SILENT_CONSOLE, which modifies the behavior slightly. If this option is selected, then the absence of the "silent" variable will result in a default behavior of "silent". Also, if "silent" is set to "1", then the behavior will be "silent". Only if a different value, say "0", is selected will the behavior be "verbose".
This patch doesn't change the behavior for any existing BSP's because they will not have selected the CONFIG_VERY_SILENT_CONSOLE option.
I consider this seriously confusing.
Also I don't see what your problem is, assuming you provide a valid environment with your newly manufactured systems.
I thend to reject this patch.
Best regards,
Wolfgang Denk
When we manufacture a new board, we will load the flash via jtag. All I had planned to put in at that stage was the u-boot image itself. I did not plan to put in an initial environment, because the environment can easily be constructed by u-boot. The problem is that by the time the initial environment is constructed, some messages that I want to suppress will already have been printed, because "silent" is not defined yet. The purpose of the patch is to suppress messages in this case.
I currently construct the environment in my BSP.c file, like so:
if(setenv("flash_self", "run flash_dhcp")) return 1; if(setHex("kernel0_addr", CFG_KERNEL0_ADDR)) return 1;
I do this rather than using CONFIG_EXTRA_ENV_SETTINGS because some of the values have to be computed. So, I guess I could write a host tool to construct the environment by linking with my BSP.c file, and then merge the constructed environment with the u-boot executable, so that jtag could put everything in at once. But that is much more complicated.
How do other people construct the initial environment, so that it can be loaded via jtag along with the u-boot executable?
Steve
In message 4852775C.1040401@harris.com you wrote:
When we manufacture a new board, we will load the flash via jtag. All I had planned to put in at that stage was the u-boot image itself. I did not plan to put in an initial environment, because the environment can easily be constructed by u-boot. The problem is that by the time the initial environment is constructed, some messages that I want to suppress will already have been printed, because "silent" is not defined yet. The purpose of the patch is to suppress messages in this case.
Why isn't "silent" defined as needed in your defualkt environment that gets used when there is no valid environment?
How do other people construct the initial environment, so that it can be loaded via jtag along with the u-boot executable?
The easiest way is set up everything as needed, or example by including the environment sector(s) with the U-Boot image (i. e. chosing a configuration which uses ENV_IS_EMBEDDED).
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Why isn't "silent" defined as needed in your defualkt environment that gets used when there is no valid environment?
The easiest way is set up everything as needed, or example by including the environment sector(s) with the U-Boot image (i. e. chosing a configuration which uses ENV_IS_EMBEDDED).
Thank you! I believe ENV_IS_EMBEDDED will do what I need. I had based my bsp on sequoia, which did not have this set.
Also, I had a misconception about ENV_IS_EMBEDDED - I had thought it meant that the environment was permanently part of the text segment, which would not be good for me. But after studying the code, I now understand that ENV_IS_EMBEDDED is only for the initial environment.
I would like to withdraw my patch.
I would still like to pursue my proposed "setenv.patch" - that one changes setenv() to return an integer rather than void. If you have any comments on it, please let me know.
Thanks again, Steve
In message 48569898.6060005@harris.com you wrote:
Also, I had a misconception about ENV_IS_EMBEDDED - I had thought it meant that the environment was permanently part of the text segment,
It has nothing to do with the text segment itself, but with the location of the environment relative to the test segment.
which would not be good for me. But after studying the code, I now understand that ENV_IS_EMBEDDED is only for the initial environment.
No, it is for the regulatr envrionment, not for the default copy which is part of the data segment.
Best regards,
Wolfgang Denk
participants (2)
-
Steven A. Falco -
Wolfgang Denk