[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:44 PM, Jerry Van Baren wrote:

> 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...

I think this was lost long ago.  If we went with simple it would have  
just done the register setup and transfer and thats it.  leaving it to  
other commands to do decompression of images, etc.

Also we already have a number env vars that impact how bootm works.

- k