[U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Peter Tyser
ptyser at xes-inc.com
Mon Jan 4 02:07:09 CET 2010
<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
More information about the U-Boot
mailing list