FT u-boot shim

[Kumar Gala]

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

>> * updating of dts:  In case 1, this is trivial since its part of the
>> kernel blob.  Case 2. is more difficult.  What do people think of
>> treating the dts like the environment.  You have a version compiled
>
> I don't like this idea.
>
>> in, but can alternately have a blob in another location that will be
>> used if exists.  This would allow one to update the dts portion w/o
>> effecting the actual boot loader.
>
> If we consider this, then we might as well combine the dts  with  the
> kernel  image.  Alternatively,  the dts might be stored in a separate
> location in memory. It would be easy to extend the "bootm" command to
> take an additional argument (dts address).

How would we distinguish the bootm command that takes a blob versus  
the ones we have today?

>> * one solution to the copies of .dts is that we make the wrapper
>> portion of the kernel the owner of the official latest and
>> greatest .dts.  Every so often a maintainer can sync their .dts with
>> u-boot to keep them relatively in sync.  However, the main mechanism
>> would be to load the latest .dts blob into the secondary location.
>
> Why not load it separately or as part of the Linux kernel image?

As stated before, the main issue is doing some runtime fix ups to the  
blob before its handed to the kernel.

The following pieces of info are setup at runtime that are board  
specific:

linux,stdout_path
cpus/<foo>/clock-frequency
cpus/<foo>/timebase-frequency
cpus/<foo>/bus-frequency
<soc>/pci/bus-range
<soc>/bus-frequency
<soc>/serial/clock-frequecny
<soc>/ethernet/address

We could hand bootm a memory location with a blob and do the fix ups  
at runtime, we would still have some coupling between the blob and u- 
boot build.  At least the blob wouldn't be built into u-boot.

- kumar