On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote: > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart 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. > > > > 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 > > We'd also be interested in some customization, though in a different way. > We imagine having a rule file that says X compatible string should map > to A base DTB, plus B and C DTBO for the configuration section. The base > DTB would carry all common elements of some device, while the DTBOs > carry all the possible second source components, like different display > panels or MIPI cameras for instance. This could drastically reduce the > size of FIT images in ChromeOS by deduplicating all the common stuff. Do you envision the "mapping" compatible string mapping to a config section in the FIT image, that would bundle the base DTB and the DTBOs ? > > 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 ? > > [...] > > ChenYu -- Regards, Laurent Pinchart
