I'm still a little bit new to dt. I thought the bootargs in chosen node will always apply when dt is enabled. It just took me some time to figure out that u-boot 'bootargs' env will anyway overwrite the one from chosen.
static int bootm_linux_fdt(int machid, bootm_headers_t *images) { ......
fdt_chosen(*of_flat_tree, 1);
...... }
int fdt_chosen(void *fdt, int force) { ......
/* * Create /chosen properites that don't exist in the fdt. * If the property exists, update it only if the "force" parameter * is true. */ str = getenv("bootargs"); if (str != NULL) { path = fdt_getprop(fdt, nodeoffset, "bootargs", NULL); if ((path == NULL) || force) { err = fdt_setprop(fdt, nodeoffset, "bootargs", str, strlen(str)+1); if (err < 0) printf("WARNING: could not set bootargs %s.\n", fdt_strerror(err)); } }
...... }
The 'force' is hard-coded as 1, so it always overwrites. Knowing that may save your some time, if you are green hands as me ;)
Dear Shawn Guo,
In message 20110226173040.GD2672@S2100-06.ap.freescale.net you wrote:
I'm still a little bit new to dt. I thought the bootargs in chosen node will always apply when dt is enabled. It just took me some time to figure out that u-boot 'bootargs' env will anyway overwrite the one from chosen.
This is not quite correct. U-Boot will not always overwrite the settings from "chosen", but only if you provide any "better" settings by defining the "bootargs" environment variable.
str = getenv("bootargs"); if (str != NULL) {
...
The 'force' is hard-coded as 1, so it always overwrites. Knowing that may save your some time, if you are green hands as me ;)
If you don't want to use the U-Boot settings, then just don't define any. If you bother to define such data, it is assumed that you actually want to see it used.
Best regards,
Wolfgang Denk
On Sun, Feb 27, 2011 at 05:09:13PM +0100, Wolfgang Denk wrote:
Dear Shawn Guo,
Hi Wolfgang,
In message 20110226173040.GD2672@S2100-06.ap.freescale.net you wrote:
I'm still a little bit new to dt. I thought the bootargs in chosen node will always apply when dt is enabled. It just took me some time to figure out that u-boot 'bootargs' env will anyway overwrite the one from chosen.
This is not quite correct. U-Boot will not always overwrite the settings from "chosen", but only if you provide any "better" settings by defining the "bootargs" environment variable.
str = getenv("bootargs"); if (str != NULL) {
...
Yes, that's what I meant. And I know I can force to get the bootargs from chosen node by clearing u-boot bootargs env with 'set bootargs'.
The 'force' is hard-coded as 1, so it always overwrites. Knowing that may save your some time, if you are green hands as me ;)
If you don't want to use the U-Boot settings, then just don't define any. If you bother to define such data, it is assumed that you actually want to see it used.
Yes, understood. Usually, we have u-boot bootargs env saved to play with non-dt kernel, so it is there for most cases. And I instinctively thought that bootargs from chosen node will be applied when booting a dt kernel. Clearly I was wrong.
I'm not blaming the implementation at all, and it actually makes the debugging easier for it let us change bootargs without running dtc and loading dtb over again. And I just want to share the info to save people's time, in case that someone else may misuse it as what I did.
Thanks.
Dear Shawn Guo,
In message 20110228013558.GA3452@S2100-06.ap.freescale.net you wrote:
Yes, understood. Usually, we have u-boot bootargs env saved to play with non-dt kernel, so it is there for most cases. And I instinctively thought that bootargs from chosen node will be applied when booting a dt kernel. Clearly I was wrong.
Most people seem to assume that the flexibility of a boot loader to build the kernel command line is more useful than a static configuration as you can provide as a default in the device tree.
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.
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.
With U-Boot, I have never seen any use for encoding this information in the device tree.
Keep in mind that a number of other parameters are handled the same way - memory map (start address and size of RAM and NOR flash), MAC addresses, ... The assumption is that such parameters dynamically determined by the boot loader should take precedence over static settings provided as defaults with the kernel or with the device tree.
I'm not blaming the implementation at all, and it actually makes the debugging easier for it let us change bootargs without running dtc and loading dtb over again. And I just want to share the info to save people's time, in case that someone else may misuse it as what I did.
Thanks.
Best regards,
Wolfgang Denk
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
On Sun, Feb 27, 2011 at 01:30:40AM +0800, Shawn Guo wrote:
I'm still a little bit new to dt. I thought the bootargs in chosen node will always apply when dt is enabled. It just took me some time to figure out that u-boot 'bootargs' env will anyway overwrite the one from chosen.
Correct; the purpose of the 'chosen' node is to pass configuration information from boot firmware to the kernel. You can put properties int the /chosen node in your .dts files, but they are merely a suggestion when firmware is devicetree aware.
g.
-
Andy Green -
Grant Likely -
Shawn Guo -
Wolfgang Denk