[PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
> On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser <ptyser at xes-inc.com> wrote:
> > Hi Grant,
> > I put U-Boot ML on CC.
> 
> Thinking further, I do actually have another concern, at least with
> regard to the way the current patch set implements things.  Is it
> expected or even "recommended" that fit images will *always* contain a
> .dtb image?  The current patch only handles the case of a .dtb
> embedded inside the fit image.

I'm not aware of any recommendations as far as what FIT images should
contain and there isn't a requirement that it should contain a .dtb
image - its just a flexible image format.

I believe in the most common FIT usage scenario the image would contain
both a kernel image and .dtb file though.  For example, most people I
deal with just have boardX and boardY that they want to boot Linux on.

Currently they have to make a "legacy" uImage, manually run the device
tree compiler with the proper flags to generate a board-specific .dtb
file, transfer the uImage to to boardX, transfer the .dtb file to
boardX, set some U-Boot variables, then boot to Linux.  For boardY they
would have to redo the steps with the exception of recreating the legacy
uImage.  (To add to the confusion, the format of device trees is a
somewhat moving target, so .dtb files aren't always compatible with
different kernel versions.)

The FIT+.dtb patches I sent make it so the same process is shortened to:
make a FIT image for boardX which contains a .dtb, download it to
boardX, and boot it.  Then repeat the same steps for boardY.

> Personally, I don't get any benefit out of the new image format, so I
> haven't spent any time looking at it.  However, I'm concerned about
> the drift back towards a different image per target when the move over
> the last 4 years has been towards multiplatform kernel images.  I
> certainly don't want to encourage embedding the device tree blob into
> the kernel image, and I'm not very interested in merging code to do
> that into the kernel tree.  If someone really needs to do that for
> their particular target, it is certainly easy enough for them to weld
> in the .dtb after the fact before transferring the image to the
> target, but I want that mode to be the exception, not the rule.

I see your point.  The main goal of the patch was to introduce FIT image
support as its the new, more flexible, "better", standard image format
for U-Boot going forward.  Also, lots people aren't aware of FIT images
and the cool stuff they can do with them, so what better way to get the
word out than getting support for FIT images included in the kernel
proper:)

I think it would be nice to generate a FIT image that contained the
kernel + .dtb as it significantly simplifies the process of booting
Linux for the common case for lots of U-Boot users and showcases one of
the benefits of the FIT format.  If you'd prefer not to have this
portion of the patch included, I can respin so that the FIT image
created only contains a kernel image, not a .dtb or initramfs.  Or I
could make targets of fitImage (no dtb included), fitImage.<board> (dtb
included), and fitImage.initrd.<board> (dtb and initramfs included).
Either way is fine with me, it'd just be nice to see FIT support get in
in some form.

Thanks,
Peter