[U-Boot] U-Boot doesn't silent the output
Hi everyone,
I searched the Internet but the help I found didn't work. I hope someone here may know how to fix it, here's the situation:
I have this ARM9 SAM9G25 which is accessed by its ttyS0. I want to disable all of the output, that was made during the U-Boot (v. 2010.06) boot, to decrease the CPU's load. Therefore there is the
setenv silent 1
parameter, which i put into the BOOTCMD string like:
#define CONFIG_BOOTCOMMAND " setenv silent 1;" \
"bootm "
and there is (as mentioned in the Readme.silent http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=doc/README.silen... ) the #define CONFIG_SILENT_CONSOLE #define CONFIG_SYS_DEVICE_NULLDEV #define CONFIG_SILENT_CONSOLE_UPDATE_ON_SET
command, neither one is working (the lines printed out are still the same and the boot time didn't change). Whereas the setenv varify n is working, just to give an example.
Does somebody see the error ?
BTW (I'm not sure if this is related to this) in the referenced link there is the information, that u-boot sets the kernel command line to "console=" so that in the end there will be no output for the kernel too, but that didn't happen and it doesn't even happen if i force to boot Linux with "console=" in the default Linux command line string Thanks for your help. Kind Regards, Frank
Hi Frank,
On 4 March 2014 01:43, Frank Ihle frank.ihle@hs-offenburg.de wrote:
Hi everyone,
I searched the Internet but the help I found didn't work. I hope someone here may know how to fix it, here's the situation:
I have this ARM9 SAM9G25 which is accessed by its ttyS0. I want to disable all of the output, that was made during the U-Boot (v. 2010.06) boot, to decrease the CPU's load. Therefore there is the
setenv silent 1
parameter, which i put into the BOOTCMD string like:
#define CONFIG_BOOTCOMMAND " setenv silent 1;" \
"bootm "
The check is done in console_init_f(), the 'f' meaning before relocation, and thus before the environment is loaded and much before the boot command is run. You need to put "silent=1" into your built-in environment in the board config file.
See also serial_s5p.c which uses the device tree to make the console silent based on a device tree setting (i.e. not compiled into U-Boot). However, I doubt your board is using device tree.
and there is (as mentioned in the Readme.silent http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=doc/README.silen... ) the #define CONFIG_SILENT_CONSOLE #define CONFIG_SYS_DEVICE_NULLDEV #define CONFIG_SILENT_CONSOLE_UPDATE_ON_SET
Maybe you need CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC?
command, neither one is working (the lines printed out are still the same and the boot time didn't change). Whereas the setenv varify n is working, just to give an example.
Does somebody see the error ?
BTW (I'm not sure if this is related to this) in the referenced link there is the information, that u-boot sets the kernel command line to "console=" so that in the end there will be no output for the kernel too, but that didn't happen and it doesn't even happen if i force to boot Linux with "console=" in the default Linux command line string
Do you see that in the Linux command line on boot?
If you have silent_linux=yes in U-Boot, then it will make Linux silent. See fixup_silent_linux() for the full details.
Regards, Simon
Thanks for your help. Kind Regards, Frank
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
The check is done in console_init_f(), the 'f' meaning before relocation, and thus before the environment is loaded and much before the boot command is run. You need to put "silent=1" into your built-in environment in the board config file.
In my U-boot 2010.06, I tried with #define CONFIG_BOOTCOMMAND " setenv silent 1;". When I hit "printenv", then there's a printout with all the commands from CONFIG_BOOTCOMMAND in just one line (here it's just "setenv silent 1;" - and not "silent=1"). I could do this manually during boot then I get a silent=1, but even then the boot is the same (and after reboot everything is gone, since I'm booting from SD card).
Well Maybe I have to say with the "setenv verify n;" in the CONFIG_BOOTCOMMAND, a similar line comes out like "setenv verify n;" instead of "verify=n", but the verify is working.
Maybe you need CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC?
I just put this instead of #define CONFIG_SILENT_CONSOLE_UPDATE_ON_SET, nothing changed
Do you see that in the Linux command line on boot?
Yes the kernel command line is shown during boot, including the "console=" or "console=null". Maybe the kernel version 2.6.39 is just too old for that feature.
If you have silent_linux=yes in U-Boot, then it will make Linux silent. See fixup_silent_linux() for the full details.
As far as I know hitting "silent=1" should silent Linux too (?) if a particular command hasn't been set in the board-headerfile.
Regards, Simon
Kind Regards,
Frank
Hi Frank,
On 17 March 2014 01:17, Frank Ihle frank.ihle@hs-offenburg.de wrote:
The check is done in console_init_f(), the 'f' meaning before relocation, and thus before the environment is loaded and much before the boot command is run. You need to put "silent=1" into your built-in environment in the board config file.
(you did not copy me on the reply so I missed this)
In my U-boot 2010.06, I tried with #define CONFIG_BOOTCOMMAND " setenv silent 1;". When I hit "printenv", then there's a printout with all the commands from CONFIG_BOOTCOMMAND in just one line (here it's just "setenv silent 1;" - and not "silent=1"). I could do this manually during boot then I get a silent=1, but even then the boot is the same (and after reboot everything is gone, since I'm booting from SD card).
Well Maybe I have to say with the "setenv verify n;" in the CONFIG_BOOTCOMMAND, a similar line comes out like "setenv verify n;" instead of "verify=n", but the verify is working.
CONFIG_BOOTCOMMAND is not the build-in environment. See CONFIG_EXTRA_ENV_SETTINGS.
Maybe you need CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC?
I just put this instead of #define CONFIG_SILENT_CONSOLE_UPDATE_ON_SET, nothing changed
Do you see that in the Linux command line on boot?
Yes the kernel command line is shown during boot, including the "console=" or "console=null". Maybe the kernel version 2.6.39 is just too old for that feature.
I doubt it - that feature has been there forever.
If you have silent_linux=yes in U-Boot, then it will make Linux silent. See fixup_silent_linux() for the full details.
As far as I know hitting "silent=1" should silent Linux too (?) if a particular command hasn't been set in the board-headerfile.
OK well one thing at a time. Try the CONFIG_EXTRA_ENV_SETTINGS above.
Regards, Simon
CONFIG_BOOTCOMMAND is not the build-in environment. See CONFIG_EXTRA_ENV_SETTINGS.
Now that I'll have in the board header file the lines
#define CONFIG_EXTRA_ENV_SETTINGS \ "silent=1\0"
and it works :) I really feel happy about this, thanks for your help! The output is disabled during U-Boot sequence, but returns when the kernel starts. I didn't expected that Linux is not influenced by this, but it's alright ATM.
Anyway I wonder why the "setenv verify n" worked with the BOOTCOMMAND but the "silent" didn't. Should I shift all the commands from CONFIG_BOOTCOMMAND to CONFIG_EXTRA_ENV_SETTINGS to be sure all the commands are really executed?
Do you see that in the Linux command line on boot?
Yes the kernel command line is shown during boot, including the "console=" or "console=null". Maybe the kernel version 2.6.39 is just too old >for that feature.
I doubt it - that feature has been there forever.
I really don't know the reason why Linux keeps talking during boot when using "console=", whereas "quiet" and changing the loglevel is working. I already asked in some forums about this, but it was as strange to them as it is to me - strange because it's a vanilla kernel I'm using, so the only thing that came to my mind is that this function is just not included into v. 2.6.3.9.
Thanks again for your help!
Kind Regards
Frank
Dear Frank,
In message 532816E0020000460004BEFA@gwia2.rz.hs-offenburg.de you wrote:
Anyway I wonder why the "setenv verify n" worked with the BOOTCOMMAND but the "silent" didn't. Should I shift all the commands from CONFIG_BOOTCOMMAND to CONFIG_EXTRA_ENV_SETTINGS to be sure all the commands are really executed?
I think you should try to get a deeper understanding of what is what. first, it is important to remember that there are two different sets of environment variables. With all the CONFIG_ settings you define only the _default_ environment, which gets used as a default (hence the name) only when the normale environment does not exist or is not valid (like corrupted checksum). So as long as you have a valid environment stored somewhere on your system, installing a new U-Boot with different settings of the default environment will have zero effect.
Second, CONFIG_BOOTCOMMAND defines exactly one environment variable, "bootcmd". As documented, the values of this variable is apssed to the Linux kernel as boot argument - and this is the only function of this variable. You can add random things to it, even U-Boot commands, but this will never have any effect on the operation of U-Boot - it might only consfuse the Linux kernel.
I really don't know the reason why Linux keeps talking during boot when using "console=", whereas "quiet" and changing the loglevel is working. I already asked in some forums about this, but it was as
What exactly did you pass in the kernel command line - just "console=", i. e. without a value? Did you try passing a valid device name instead, like "console=null"?
Also, are you sure early debug output is disabled in your kernel configuration? Otherwise this will get printed even before the Linux kernel's console driver has been started.
Best regards,
Wolfgang Denk
Wolfgang Denk 18.03.14 10.05 Uhr >>>
Dear Frank,
In message 532816E0020000460004BEFA@gwia2.rz.hs-offenburg.de you wrote:
Anyway I wonder why the "setenv verify n" worked with the BOOTCOMMAND but the "silent" didn't. Should I shift all the commands from CONFIG_BOOTCOMMAND to CONFIG_EXTRA_ENV_SETTINGS to be sure all the commands are really executed?
I think you should try to get a deeper understanding of what is what. first, it is important to remember that there are two different sets of environment variables. With all the CONFIG_ settings you define only the _default_ environment, which gets used as a default (hence the name) only when the normale environment does not exist or is not valid (like corrupted checksum). So as long as you have a valid environment stored somewhere on your system, installing a new U-Boot with different settings of the default environment will have zero effect.
Thanks for the advise, I'll have a closer look ASAP. The way I got into this U-Boot 2010.06 was: I used an already existing board header file (that was not a standard U-Boot board header file) and that's how it was implemented there.
Second, CONFIG_BOOTCOMMAND defines exactly one environment variable, "bootcmd". As documented, the values of this variable is apssed to the Linux kernel as boot argument - and this is the only function of this variable. You can add random things to it, even U-Boot commands, but this will never have any effect on the operation of U-Boot - it might only consfuse the Linux kernel.
Well the variables I pass to the kernel command line are stored not in the CONFIG_BOOTCOMMAND, but in the CONFIG_BOOTARGS. When checking the kernel command line during boot, it is the same like the one defined in the BOOTARGS.
In that mentioned header file, with what I started U-Boot, there are commands in the CONFIG_BOOTCOMMAND like "nand write, tftp, setenv ipaddr" etc. - since those are the commands from the U-Boot menu on target, I thought enqueuing the BOOTCOMMAND with "silent", or "verify" would work too, though "verify" worked this way (a recognizable boot time was decreased).
I really don't know the reason why Linux keeps talking during boot when using "console=", whereas "quiet" and changing the loglevel is working. I already asked in some forums about this, but it was as
What exactly did you pass in the kernel command line - just "console=", i. e. without a value? Did you try passing a valid device name instead, like "console=null"?
Yes I tried with "console=" and "console=null".
Also, are you sure early debug output is disabled in your kernel configuration? Otherwise this will get printed even before the Linux kernel's console driver has been started.
If you mean the "early printk" then yes, otherwise I need more information what is meant by early debug output.
Kind Regards,
Frank
Dear Frank,
In message 53281FB1020000460004BF46@gwia2.rz.hs-offenburg.de you wrote:
Second, CONFIG_BOOTCOMMAND defines exactly one environment variable, "bootcmd". As documented, the values of this variable is apssed to the Linux kernel as boot argument - and this is the only function of this variable. You can add random things to it, even U-Boot commands, but this will never have any effect on the operation of U-Boot - it might only consfuse the Linux kernel.
Well the variables I pass to the kernel command line are stored not in the CONFIG_BOOTCOMMAND, but in the CONFIG_BOOTARGS. When checking the kernel command line during boot, it is the same like the one defined in the BOOTARGS.
oops. Sorry, of course you are right - I confused this. Guess I need more tea...
In that mentioned header file, with what I started U-Boot, there are commands in the CONFIG_BOOTCOMMAND like "nand write, tftp, setenv ipaddr" etc. - since those are the commands from the U-Boot menu on target, I thought enqueuing the BOOTCOMMAND with " silent", or "verify" would work too, though "verify" worked this way (a recognizable boot time was decreased).
Again - CONFIG_BOOTCOMMAND affects only the default environment, it does not change the setting of the "bootcmd" variable in your normal environment.
Also, are you sure early debug output is disabled in your kernel configuration? Otherwise this will get printed even before the Linux kernel's console driver has been started.
If you mean the "early printk" then yes, otherwise I need more information what is meant by early debug output.
Yes.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On 18 March 2014 09:03, Wolfgang Denk wd@denx.de wrote:
What exactly did you pass in the kernel command line - just "console=", i. e. without a value? Did you try passing a valid device name instead, like "console=null"?
Apologies for hijacking this thread.
If I remember, fixup_silent_linux ensures that 'console=' is present in the kernel arguments (i.e. it will replace console=/dev/ttyS0 (or similar) with console=).
I think preferred behavior for this may be to instead leave any 'console' arguments as they are and instead ensure that 'quiet' or 'loglevel=1' is present instead. There are two motivations for doing this - the first is that when using a lower loglevel you still get suppressed kernel output - but you also get any errors. Thus if something goes wrong you'll see why rather than wonder if U-Boot even started the kernel. The second is that I've seen a few times in the past where setting console to nothing (console=) results in strange behavior (it once increased boot time). After all we want a console we just don't want to use it as much. I can provide a patch for this if you think you may take it?
Thanks,
Andrew Murray
I think preferred behavior for this may be to instead leave any 'console' arguments as they are and instead ensure that 'quiet' or 'loglevel=1' is present instead. There are two motivations for doing this - the first is that when using a lower loglevel you still get suppressed kernel output - but you also get any errors. Thus if something goes wrong you'll see why rather than wonder if U-Boot even started the kernel. The second is that I've seen a few times in the past where setting console to nothing (console=) results in strange behavior (it once increased boot time). After all we want a console we just don't want to use it as much. I can provide a patch for this if you think you may take it?
Thanks,
Andrew Murray
Well let me tell you about the circumstances:
I use these Images for an embedded system without any console at all, but of a serial debug port (for developing). So if the development phase is finished then I really need absolutely no output in any boot sequence or anytime later, since nobody will read it at all. Because, the actual aim: I want to have my system booting as fast as any possible, that means excluding all unused features (here: it's the output).
Now, if you think the patch you mentioned could help me, by disabling all output but keep everything else in the same way as it was, then I would really appreciate that if you could share it.
Thank you
Dear Andrew,
In message CAPcvp5FNJo9y3mKhUdgar1jx0tfHkeXU06BbTg5NCCSQ3Wb_uQ@mail.gmail.com you wrote:
If I remember, fixup_silent_linux ensures that 'console=' is present in the kernel arguments (i.e. it will replace console=/dev/ttyS0 (or similar) with console=).
I think preferred behavior for this may be to instead leave any 'console' arguments as they are and instead ensure that 'quiet' or 'loglevel=1' is present instead. There are two motivations for doing this - the first is that when using a lower loglevel you still get suppressed kernel output - but you also get any errors. Thus if something goes wrong you'll see why rather than wonder if U-Boot even started the kernel. The second is that I've seen a few times in the past where setting console to nothing (console=) results in strange behavior (it once increased boot time). After all we want a console we just don't want to use it as much. I can provide a patch for this if you think you may take it?
I have to admit that I don't know if this is a good idea. I do know that some users use this feature to make sure the console port is completely free, and no characters ever are sent to it, for example because they use it for application specific purposes. Of course one might ask if this is a good idea (IMO a separate console port is a very useful feature), but you know how some companies design their hardware...
Best regards,
Wolfgang Denk
On 18 March 2014 11:30, Wolfgang Denk wd@denx.de wrote:
Dear Andrew,
In message <
CAPcvp5FNJo9y3mKhUdgar1jx0tfHkeXU06BbTg5NCCSQ3Wb_uQ@mail.gmail.com> you wrote:
If I remember, fixup_silent_linux ensures that 'console=' is present in the kernel arguments (i.e. it will replace console=/dev/ttyS0 (or similar) with console=).
I think preferred behavior for this may be to instead leave any 'console' arguments as they are and instead ensure that 'quiet' or 'loglevel=1' is present instead. There are two motivations for doing this - the first is that when using a lower loglevel you still get suppressed kernel output - but you also get any errors. Thus if something goes wrong you'll see why rather than wonder if U-Boot even started the kernel. The second is that I've seen a few times in the past where setting console to nothing (console=) results in strange behavior (it once increased boot time). After all we want a console we just don't want to use it as much. I can provide a patch for this if you think you may take it?
I have to admit that I don't know if this is a good idea. I do know that some users use this feature to make sure the console port is completely free, and no characters ever are sent to it, for example because they use it for application specific purposes. Of course one might ask if this is a good idea (IMO a separate console port is a very useful feature), but you know how some companies design their hardware...
Yes I can understand why they would want to do that.
However I would argue that using the 'silent' feature isn't the correct way to achieve it. If a user depends on having a console completely free then they probably shouldn't add a 'console=xyz' to their boot args in the first place.
Thanks,
Andrew Murray
Dear Andrew,
In message CAPcvp5EkXdB_Y16SYM7x2cLN67hBG4jt8jkoS7n8+fsD8dRBJg@mail.gmail.com you wrote:
However I would argue that using the 'silent' feature isn't the correct way to achieve it. If a user depends on having a console completely free then they probably shouldn't add a 'console=xyz' to their boot args in the first place.
Even if it is "console=null" ?
Best regards,
Wolfgang Denk
On 18 March 2014 14:17, Wolfgang Denk wd@denx.de wrote:
Dear Andrew,
In message CAPcvp5EkXdB_Y16SYM7x2cLN67hBG4jt8jkoS7n8+fsD8dRBJg@mail.gmail.com you wrote:
However I would argue that using the 'silent' feature isn't the correct way to achieve it. If a user depends on having a console completely free then they probably shouldn't add a 'console=xyz' to their boot args in the first place.
Even if it is "console=null" ?
If it is 'console=null' (which as you point out would be sensible), then the existing 'silent' feature will change that to 'console=' (which shouldn't ought to make a difference anyway).
Where a user has 'console=null' in their bootargs, then my console would turn that into 'console=null loglevel=1' rather that the present which would be 'console='.
Thanks,
Andrew Murray
participants (4)
-
Andrew Murray -
Frank Ihle -
Simon Glass -
Wolfgang Denk