[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