[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Kumar Gala wrote:
> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
> 
>> In message <Pine.LNX.4.64.0808041346350.3885@blarg.am.freescale.net>  
>> you wrote:
>>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'  
>>> commands
>>> that the user can supply to manipulate the device tree after  
>>> ft_board_setup()
>>> and before the tree is handled to the kernel.
>> Where exactly is the needed, i. e. which spoecific situation  do  you
>> have  in  mind  where  this function cannot be implemented as part of
>> either a "preboot" or a standard "bootcmd" command sequence?
> 
> The situation is if we are fixing up or adding properties or nodes via  
> the ft_board_setup() how do I go about modifying that before the  
> device tree is handed to the kernel.
> 
> An example would be if we start adding the i2c node via code in u-boot  
> and after we have done that we want to add a frequency property at  
> runtime w/o changing the u-boot code.
> 
> - k

My original way long ago initial cut didn't do the board and /chosen 
fixups as part of the bootm execution.  My original intent was that we 
would run "fdt chosen" and "fdt bd" and whatever else was necessary 
before running "bootm", including addressing Kumar's need.

Unfortunately, it would have also broken backwards compatibility and so 
the concept was sacrificed for backwards compatibility.  :-/

Is there a better way of doing this... perhaps have a flag that says if 
"fdt chosen" and/or "fdt bd" is run, don't re-run it as part of bootm? 
Maybe have an env variable that suppressed the calling of "fdt chosen" 
and "fdt bd" in bootm ("nofdtfixup"?)?  Still ugly, but it would 
maintain backwards compatibility but also allow us finer grained control 
of when "fdt chosen" and "fdt bd" (add "fdt cpu"?) is run and allow our 
users to wedge additional fdt stuff in the boot sequence.

gvb