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