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

[Peter Tyser <ptyser@xes-inc.com>]

<snip>

> Note that the FIT image can also be made to contain a number of DT
> blobs, and selection of a "board profile" then can be used to boot the
> very sane FIT image file on any of the supported boards - so FIT
> images inherently support multibooting.

I agree with Wolfgang.  Additionally, if a FIT image does contain a .dtb 
file, firmware can ignore it and load a different .dtb file.  So for the 
fitImage.<boardname> target you could think of it as including a 
"default/fallback" .dtb file, not a mandatory one.  So the FIT image 
could still be used as a multiplatform image even if it contained dtbs.

>>> 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:)
>>
>> Define 'better'.  :-)
>
> FIT images are better than the old uImage format because they:
>
> - allow for strong checksum algorithms like MD5, SHA1, ... (the plain
>    CRC32 method is not good enough if you for example want to run
>    software in a slot machine in Las Vegas).
>
> - can combine multiple kernel images, device tree blobs and root file
>    system images in arbitrary combinations; this allows for example
>    for multibooting the same image on different boards by selecting
>    the right DTB, for software updates with automatic fall-back, etc.
>
> - can be extended to add new features, images types or whatever in a
>    standard way, using a standard technology (device tree support)
>    which is already present anyway, i. e. without additional code
>    overhead.

Other advantages of FIT images that I see day-to-day include:
- Adding meta-data such as timestamps and version information for each 
component of the FIT image.  Its great to be able to easily display the 
contents of a FIT image to determine which kernel versions it contains, etc.

- Embed multiple OS/dtb images in one FIT image.  As a board vendor its 
nice to give a customer 1 image that has example dtb(s) and Linux, 
VxWorks, QNX, diagnostic, etc kernels.  They can boot a number of OSes 
on a number of different boards with 1 image.

- You can extract the images contained in a FIT image using 'dtc' to 
convert the FIT image to a ".dts" file that has the raw image contents. 
  Other image formats are more difficult to extract contents from.

<snip>

>> I'd be okay (perhaps not happy, but okay) with merging fitImage and
>> fitImage.initrd targets (no dtb).  I will resist merging fitImage.%
>> and fitImage.initrd.% targets because I see that very much as a
>> project specific deployment target and I'm not convinced yet that it
>> the pattern is right or that it is even needed in the kernel at all.
>
> Is this just your personal opinion, or do you think that this is
> really what a majority of kernel developers and users are wanting?
>
> Speaking for myself, I have to admit that I don't understand and don't
> share this attitude.

I agree with Wolfgang that many people would find the combined 
kernel/dtb/ramfs useful, but understand Grant's reservations.  Assuming 
I rework the patch to include a "fitImage" (no dtb) target, for the 
users that basic multiplatform images are important to, they could build 
this kernel-only FIT image.  For people such as Wolfgang, Peter, and 
myself who would like to bundle a kernel + dtb(s), we could use the 
fitImage.<boardname> target.  Wouldn't both parties be happy then?  I 
could make the FIT documentation explain the benefits of multiplatform 
images or warn about the combined kernel/dtb FIT images if that made a 
difference too.

Best,
Peter