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

[Jerry Van Baren]

Kumar Gala wrote:
> 
> 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

I don't like it that bootm is calling out to all sorts of functions that 
could better be scripted.  It complicates the bootm code (badly!), it 
prevents users from doing clever things (because it hard codes the calls 
and sequences of the calls to loosely related functions), and it 
violates the unix principle of doing only one thing and doing it well 
(bootm code is one big ugly awkward swissarmyknife[tm] tool).

Best regards,
gvb

P.S. This battle was probably lost many years ago, but it still makes me 
feel better to pound the desk and shout.  Oh-oh, people are looking...