FT u-boot shim

[Kumar Gala]

On Apr 28, 2006, at 6:28 AM, Paul Mackerras wrote:

> Kumar Gala writes:
>
>> If we have a u-boot shim there are some questions that need  
>> answering:
>> * where should the .dts live (hate duplicating the file both in u-
>> boot and kernel source tree)
>> * how does build system find .dts
>> * a Kconfig option to enable shim
>> * assume done as a boot wrapper of sorts
>
> What I think would be useful is a stand-alone tool that would take a
> kernel and a dts and construct an image that is bootable on a given
> board by its existing firmware.  That means there would either need to
> be a version of the tool for each firmware, or alternatively a set of
> command-line options to tell it what sort of firmware you have.
>
> This wouldn't have to be done at kernel build time; it could be
> potentially be done much later.  Hopefully then the board vendors
> could take on the job of generating the dts.  In fact for some boards
> the board-support package could be just the dts.
>
> This tool would need to insert a suitable shim, which might actually
> need to contain code to pull stuff out of a firmware-specific
> structure such as a bd_t, and stuff it into the dts.  That should be
> doable provided there is a convention about labels in the dts for
> things such as memory size, ethernet mac address, etc.
>
> Clearly it is neater if the firmware can supply the device-tree blob
> directly, and just boot a raw kernel.  However, there will always be
> situations where we don't get to choose the firmware, so I think we
> need this tool.

I agree with this (after having it beaten into me :).

However, I really hate introducing some third project that is  
required.  If we decide to pull ALL of boot wrappers out of the  
kernel tree than I'd be ok with it.  But until that time I think this  
lives under arch/powerpc/boot/...

What I envision as the way one boots for something like u-boot is one  
of three options:
1. using an old u-boot + boot wrapper (bd_t -> wrapper -> kernel)
2. using a u-boot that is ft aware + dtb (boot command in u-boot  
takes kernel & dtb images, updates blob and passes to kernel)
3. using a u-boot that is ft aware + built in dtb.

The issue is that for a given system/board you may need to support  
multiple or all three.  This raises the question where does the .dts  
live.  For the time being I say it lives in the boot wrapper part of  
the kernel tree.  Thus we handle the three cases as follows:

1. built as part of the boot wrapper
2. build a multi image u-boot image, one section for the blob
3. point u-boot build system at .dts

- kumar