[U-Boot-Users] Warning for mpc8360emds users: fdt-cmd from u-boot-fdt.git
Jerry Van Baren
gvb.uboot at gmail.com
Thu Apr 5 05:08:50 CEST 2007
Wolfgang Denk wrote:
> In message <4613CF9F.4040501 at smiths-aerospace.com> you wrote:
>> I view autogenerating fdt entries inside "bootm" as being evil.
>> Obviously, if there are enough people on the Dark Side to overwhelm me,
>> that can be changed.
>
> "bootm" is intended to boot an image located somewhere in system
> memory. It will pass arguments like the booargs and the FDT to the
> kernel. It evaluates bootargs and substitured env vars for this. It
> might not be insane to expect that it also does reasonable things to
> the FDT.
>
> I'm not in a position to determine what's reasonable there, though.
>
> Best regards,
>
> Wolfgang Denk
Well, I'm feeling my way around here too. :-/
If bootm edits/augments the FDT, the boot scripts/user has no chance to
change the items it edits/augments (biggie: the chosen node), or even
print it before linux is launched. This defeats 90% of the purpose of
the fdt command - allowing the user/script customize the blob before
linux is launched.
My reasoning is that you can string together (or script) the proper
"fdt" commands to do what previously was done by "bootm" in one step, so
we are losing a small bit of convenience and gaining a whole lot of
flexibility. As a for instance, currently/previously you had to
uncomment the blob dump call and recompile u-boot to get a dump of what
is fed to linux - fugly. With the New Improved[tm] behavior, you simply
add "fdt print" to the super-bootm script and it Just Works[tm]. This
is actually the itch that started me down this path. :-/
Much, perhaps most, possibly even all of the current stuff that is
wedged into bootm is or should be passed through the blob.
Best regards,
gvb
More information about the U-Boot
mailing list