FT u-boot shim

[Jerry Van Baren]

Kumar Gala wrote:
>> Let's say we have to support such situations, too.
>>
>>> * dts owned by u-boot??
>> I'm not sure about this. I tend to believe the  dts  belongs  to  the
>> kernel.
>>
>>> Some questions/issues:
>>> * ownership of .dts is problematic.  I hate having a file duplicated
>>> by both u-boot and kernel.  However it also seems bad to make the
>>> build of either depend on the user grabbing a dts from some third
>>> party.  Ideas?  A concrete example would be the MPC8349 ADS/SYS/MDS
>>> port.  Boards ship with an "old" u-boot, thus we need a kernel
>>> wrapper with .dts.  However, newer u-boot's can (hopefully will) have
>>> a dts in them
>> Can we provide the dts as a separate blob that gets  built  with  the
>> kernel image? From U-Boot's point of view, this could be a multi-file
>> image  which  combines  the  dts and the kernel into a single file so
>> that users don't have to care much about this.
> 
> The problem is that there are somethings that u-boot knows that needs  
> to go into the blob (memory size, boot args, initrd info,  
> frequencies, etc.)

[snip]

> - kumar

A thought that keeps recurring (but I've suppressed because I don't have 
time to play...) is that it would be Really Cool[tm] to store the u-boot 
env variables in a flat tree and then pass the env/tree to linux.  It 
also sounds like a major change & disruption to u-boot :-(.  I haven't 
looked at what it would do to code size either.

U-boot could then be a better OpenBoot than OpenBoot ;-)

gvb