<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