Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Laurent,

On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> > > 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:
> > > > > 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 ?
> >
> > That's exactly the idea. The mapping compatible string could be untied
> > from the base board's compatible string if needed (which we probably do).
> >
> > So something like:
> >
> > config {
> >     config-1 {
> >         compatible = "google,krane-sku0";
> >         fdt = "krane-baseboard", "krane-sku0-overlay";
> >     };
> > };
> >
> > With "krane-sku0-overlay" being an overlay that holds the differences
> > between the SKUs, in this case the display panel and MIPI camera (not
> > upstreamed) that applies to SKU0 in particular.
>
> The kernel DT makefiles already contain information on what overlays to
> apply to what base boards, in order to test the overlays and produce
> "full" DTBs. Maybe that information could be leveraged to create the
> configurations in the FIT image ?

Although the "full" DTBs created may only be a subset of all possible
combinations (I believe Rob just started with creating one "full" DTB
for each overlay, cfr. the additions I made in commit a09c3e105a208580
("arm64: dts: renesas: Apply overlays to base dtbs")), that could
definitely be a start.

Now, since the kernel build system already creates "full" DTBs, does
that mean that all of the base DTBs, overlays, and "full" DTBs will
end up in the FIT image?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds