On 02/28/2011 06:32 AM, Somebody in the thread at some point said:
Hi -
Many powerful features can be implemented this way - install and update scripts, booting alternative kernels, root file systems or system configurations, enablign IP autoconfiguration using the same network settings as already used by the boot loader, providing an elegant method for dynamic configuration of the MTD partitions, etc. etc.
Actually all that stuff is better done by Linux no matter how hard the bootloader tries, I think we can agree.
Being able to provide a kernel command line in the DT (or in the static kernel configuration) is only really useful with stupid boot loaders that cannot pass boot arguments.
Qi builds up a kernel commandline from static and filesystem data like this:
[arch specific part] [board specific part] [board revision part] [kernel source part] [append file from kernel source part]
The first is static and decided by the arch, eg, OMAP3; the second is decided by the board type that was probed; the third allows override by board revision which is also probed (so you can deal with console UART moving between revisions); the fourth part is defined by the source of the kernel you are trying to boot, so it can set, eg, root=/dev/mmcblk0p2 reflecting where the associated filesystem for that kernel can be found; and the last part comes from a file in the same filesystem as the kernel bring booted to allow arbitrary user additions.
Typically, the probing approach narrows down the correct commandline that you don't need the user file, but if you do want to override stuff, you can do it there.
-Andy