Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
MIME-Version: 1.0
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com> <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
 <20231209152946.GC13421@pendragon.ideasonboard.com> <CAMuHMdVMZs6mnwWBgFwktO=8o=QzROv60cfZe085MhD6HxQjpQ@mail.gmail.com>
 <CAGXv+5Est3FL-XcEL-vB-6zVNas0mqb2cNYa==Yb7W2SQU9xVQ@mail.gmail.com>
In-Reply-To: <CAGXv+5Est3FL-XcEL-vB-6zVNas0mqb2cNYa==Yb7W2SQU9xVQ@mail.gmail.com>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu, 14 Dec 2023 15:12:07 +0900
Message-ID: <CAK7LNATyD-PeNbaLTjJmU9=koqqE+V6QvFe09c2VrXopWvjpcw@mail.gmail.com>
Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
To:     Chen-Yu Tsai <wenst@chromium.org>
Cc:     Geert Uytterhoeven <geert@linux-m68k.org>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Simon Glass <sjg@chromium.org>,
        linux-arm-kernel@lists.infradead.org,
        Ahmad Fatoum <a.fatoum@pengutronix.de>,
        U-Boot Mailing List <u-boot@lists.denx.de>,
        Nicolas Schier <nicolas@fjasle.eu>,
        Tom Rini <trini@konsulko.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Terrell <terrelln@fb.com>, Will Deacon <will@kernel.org>,
        linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org,
        linux-kernel@vger.kernel.org, workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Dec 14, 2023 at 1:03=E2=80=AFPM Chen-Yu Tsai <wenst@chromium.org> w=
rote:
>
> On Sun, Dec 10, 2023 at 1:31=E2=80=AFAM Geert Uytterhoeven <geert@linux-m=
68k.org> wrote:
> >
> > Hi Laurent,
> >
> > On Sat, Dec 9, 2023 at 4:29=E2=80=AFPM 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=E2=80=AFPM 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 wrot=
e:
> > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > Add a script which produces a Flat Image Tree (FIT), a sing=
le 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 appro=
ach.
> > > > > > > >
> > > > > > > > The FIT can be used by bootloaders which support it, such a=
s U-Boot
> > > > > > > > and Linuxboot. It permits automatic selection of the correc=
t
> > > > > > > > devicetree, matching the compatible string of the running b=
oard 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. Fo=
r now there
> > > > > > > > is no way to change the compression other than by editing t=
he rule for
> > > > > > > > $(obj)/image.fit
> > > > > > > >
> > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made t=
o 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 t=
he
> > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > one-size-fits-them-all solution to build them, and striking t=
he right
> > > > > > > balance between what makes sense for the kernel and the featu=
res that
> > > > > > > users may request will probably lead to bikeshedding. As we a=
ll love
> > > > > > > bikeshedding, I thought I would start selfishly, with a perso=
nal 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 scrip=
t by
> > > > > > > extending the supported command line arguments. It would perh=
aps be more
> > > > > > > difficult to integrate in the kernel build system though. Thi=
s leads me
> > > > > > > to a second question: would you consider merging extensions t=
o this
> > > > > > > script if they are not used by the kernel build system, but m=
eant for
> > > > > > > users who manually invoke the script ? More generally, is the=
 script
> > > > > >
> > > > > > We'd also be interested in some customization, though in a diff=
erent way.
> > > > > > We imagine having a rule file that says X compatible string sho=
uld 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 D=
TBOs
> > > > > > carry all the possible second source components, like different=
 display
> > > > > > panels or MIPI cameras for instance. This could drastically red=
uce the
> > > > > > size of FIT images in ChromeOS by deduplicating all the common =
stuff.
> > > > >
> > > > > Do you envision the "mapping" compatible string mapping to a conf=
ig
> > > > > 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 unt=
ied
> > > > from the base board's compatible string if needed (which we probabl=
y do).
> > > >
> > > > So something like:
> > > >
> > > > config {
> > > >     config-1 {
> > > >         compatible =3D "google,krane-sku0";
> > > >         fdt =3D "krane-baseboard", "krane-sku0-overlay";
> > > >     };
> > > > };
> > > >
> > > > With "krane-sku0-overlay" being an overlay that holds the differenc=
es
> > > > between the SKUs, in this case the display panel and MIPI camera (n=
ot
> > > > 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?
>
> I suppose we could add an option to the packing tool to be able to _not_
> add the "full" DTBs if they can also be assembled with a base DTB and
> overlays. Think of it as a firmware compatibility option: if the firmware
> supports overlays, then you almost always want the deconstructed parts,
> not the fully assembled ones. Vice versa.
>
> If we don't we could end up with two configurations that have the same
> compatible string?


Right.

We would end up with such situations because applying
an overlay does not change the compatible string.


With this code in arch/arm64/boot/dts/ti/Makefile:

k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs :=3D \
      k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtb=
o
k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs :=3D \
      k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo


$ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb
2>/dev/null| head -n15 | tail -n2
    model =3D "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
    compatible =3D "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
"ti,am642";


$ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
2>/dev/null| head -n15 | tail -n2
    model =3D "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
    compatible =3D "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
"ti,am642";


These two go into image.fit, but one of them is completely dead
since there is no way to distinguish them.


$ fdtdump  arch/arm64/boot/image.fit

        ...

        conf-10 {
            compatible =3D "tq,am642-tqma6442l-mbax4xxl",
"tq,am642-tqma6442l", "ti,am642";
            description =3D "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier b=
oard";
            fdt =3D "fdt-10";
            kernel =3D "kernel";
        };

        ...

        conf-25 {
            compatible =3D "tq,am642-tqma6442l-mbax4xxl",
"tq,am642-tqma6442l", "ti,am642";
            description =3D "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier b=
oard";
            fdt =3D "fdt-25";
            kernel =3D "kernel";
        };


I agree with Chen-Yu.

FIT should not include full DTBs.

Bootloaders should assemble the final DTB
from base and overlays on-the-fly.


The FIT spec allows the "fdt" property to list
multiple image nodes.


o config-1
 |- description =3D "configuration description"
 |- kernel =3D "kernel sub-node unit name"
 |- fdt =3D "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", .=
..]
 |- loadables =3D "loadables sub-node unit-name"
 |- script =3D "
 |- compatible =3D "vendor


>
> ChenYu
>
>
> > 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 li=
ke that.
> >                                 -- Linus Torvalds


--
Best Regards
Masahiro Yamada