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

[Kumar Gala]

On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
>>> In message <Pine.LNX. 
>>> 4.64.0808041346350.3885 at 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.

Is that really any better than having the ability to "execute" an  
environment variable that has 'fdt' commands in it as part of bootm?

- k