FT u-boot shim

[Wolfgang Denk]

In message <6E3621C5-A379-4ABC-99C0-9A02B48D525D at kernel.crashing.org>
Kumar Gala wrote:
> 
> 1. boot with an "old" u-boot (via bd_t):
> * Have a boot wrapper that takes bd_t and dts and merges them @ runtime
> * Boot wrapper has to be custom based on bd_t definition for the system
> * dts owned by kernel??

Since we cannot go back in time and fix the "old" U-Boot  this  seems
to be the only option.

> 2. boot with a "new" u-boot (has a .dts in it):
> * capable of booting arch/powerpc kernel directly w/o modification

OK.

> * in a production system don't want to update u-boot

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.

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

> * 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?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No user-servicable parts inside. Refer to qualified service personnel.