Dear Shawn Guo, In message <20110228013558.ga3...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's a small world, but I wouldn't want to paint it. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
