Hi Laurent,
On Sun, 3 Dec 2023 at 08:33, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Simon,
Thank you for the patch.
On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
Add a script which produces a Flat Image Tree (FIT), a single file containing the built kernel and associated devicetree files. Compression defaults to gzip which gives a good balance of size and performance.
The files compress from about 86MB to 24MB using this approach.
The FIT can be used by bootloaders which support it, such as U-Boot and Linuxboot. It permits automatic selection of the correct devicetree, matching the compatible string of the running board with the closest compatible string in the FIT. There is no need for filenames or other workarounds.
Add a 'make image.fit' build target for arm64, as well. Use FIT_COMPRESSION to select a different algorithm.
The FIT can be examined using 'dumpimage -l'.
This features requires pylibfdt (use 'pip install libfdt'). It also requires compression utilities for the algorithm being used. Supported compression options are the same as the Image.xxx files. For now there is no way to change the compression other than by editing the rule for $(obj)/image.fit
While FIT supports a ramdisk / initrd, no attempt is made to support this here, since it must be built separately from the Linux build.
FIT images are very useful, so I think this is a very welcome addition to the kernel build system. It can get tricky though: given the versatile nature of FIT images, there can't be any one-size-fits-them-all solution to build them, and striking the right balance between what makes sense for the kernel and the features that users may request will probably lead to bikeshedding. As we all love bikeshedding, I thought I would start selfishly, with a personal use case :-) This isn't a yak-shaving request though, I don't see any reason to delay merging this series.
OK, sounds good!
Have you envisioned building FIT images with a subset of DTBs, or adding DTBOs ? Both would be fairly trivial extensions to this script by extending the supported command line arguments. It would perhaps be more difficult to integrate in the kernel build system though. This leads me to a second question: would you consider merging extensions to this script if they are not used by the kernel build system, but meant for users who manually invoke the script ? More generally, is the script meant to be used stand-alone as well, in which case its command line arguments need to remain backward-compatible, or do you see it as being internal to the kernel ?
The script as written is internal to the kernel, but I am sure it could be expanded in some ways. I am waiting to see it merged before worrying too much about what might happen in the future!
[..]
Regards, Simon