Received-SPF: pass (google.com: domain of linux-kernel+bounces-90043-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240223092338.2433632-1-wenst@chromium.org> <CAK7LNAQmvyftnFJaByyjH+f4nxcNUKpjkDXwebEH5AhMF6U0Kw@mail.gmail.com>
 <CAGXv+5GmkZdqpNZDFN4dcTyZ-qVS0TjrrqBrBAei6DP+eXLnJg@mail.gmail.com> <CAK7LNAS8tLuHYcPTb5pJZixn5Hb0yjo0nmbrfSUr5Cd_pc+WMg@mail.gmail.com>
In-Reply-To: <CAK7LNAS8tLuHYcPTb5pJZixn5Hb0yjo0nmbrfSUr5Cd_pc+WMg@mail.gmail.com>
From: Chen-Yu Tsai <wenst@chromium.org>
Date: Mon, 4 Mar 2024 12:36:55 +0800
Message-ID: <CAGXv+5HB7gXJ0x1uVdgbWaRWS8+rN6FwEgyGLObxr_cfyLty6A@mail.gmail.com>
Subject: Re: [PATCH RFC] kbuild: create a list of all built DTB files
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>, Nicolas Schier <nicolas@fjasle.eu>, linux-kbuild@vger.kernel.org, 
	linux-kernel@vger.kernel.org, Simon Glass <sjg@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 29, 2024 at 11:35=E2=80=AFPM Masahiro Yamada <masahiroy@kernel.=
org> wrote:
>
> On Thu, Feb 29, 2024 at 11:38=E2=80=AFAM Chen-Yu Tsai <wenst@chromium.org=
> wrote:
> >
> > On Sun, Feb 25, 2024 at 4:21=E2=80=AFPM Masahiro Yamada <masahiroy@kern=
el.org> wrote:
> > >
> > > On Fri, Feb 23, 2024 at 6:23=E2=80=AFPM Chen-Yu Tsai <wenst@chromium.=
org> wrote:
> > > >
> > > > It is useful to have a list of all composite *.dtb files, along wit=
h
> > > > their individual components, generated from the current build.
> > > >
> > > > With this commit, 'make dtbs' creates arch/*/boot/dts/dtbs-componen=
ts,
> > > > which lists the composite dtb files created in the current build. I=
t
> > > > maintains the order of the dtb-y additions in Makefiles although th=
e
> > > > order is not important for DTBs.
> > > >
> > > > This compliments the list of all *.dtb and *.dtbo files in dtbs-lis=
t,
> > > > which only includes the files directly added to dtb-y.
> > > >
> > > > For example, consider this case:
> > > >
> > > >     foo-dtbs :=3D foo_base.dtb foo_overlay.dtbo
> > > >     dtb-y :=3D bar.dtb foo.dtb
> > > >
> > > > In this example, the new list will include foo.dtb with foo_base.dt=
b and
> > > > foo_overlay.dtbo on the same line, but not bar.dtb.
> > > >
> > > > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> > > > ---
> > > > Hi,
> > > >
> > > > I hacked up this new thing to list out the individual components of=
 each
> > > > composite dtb. I think this information would be useful for FIT ima=
ge
> > > > generation or other toolchains to consume. For example, instead of
> > > > including each dtb, a toolchain could realize that some are put tog=
ether
> > > > using others, and if the bootloader supports it, put together comma=
nds
> > > > to reassemble the end result from the original parts.
> > > >
> > > > This is based on and complements Masahiro-san's recent dtbs-list wo=
rk.
> > >
> > >
> > >
> > > This is another format of my previous per-dtb "*.dtlst"
> > > (but I did not pick up 3/4, 4/4 because I did not know what we need a=
fter all).
> > >
> > > This should be discussed together with how Simon's script will look l=
ike.
> > >
> > > I can understand your Makefile code, but I still do not know
> > > how the entire overlay stuff will work in a big picture.
> >
> > How would you like to proceed? I can through together some changes on t=
op
> > of Simon's patches as an initial proposal if that helps?
> >
> > I can use your format if you prefer.
>
>
> How would you select base+addonX among
> other base+addonY or base+addonZ configurations?

I assume you are alluding to the existing in-tree composite DTs that
share the same board compatible strings?

Under the current FIT image design with compatible strings populated from
the FDTs, I don't think there's any way to automatically select among them.
The FIT image simply does not have the information available. Nor do the
overlays themselves. The toolchain can only either include all of them
and let the bootloader figure things out, or filter out all the duplicates.
With the composite list, at least it will be able to consistently keep
only the base DT and drop the ones with the addons.

In one of my previous replies to v9 I mentioned adding a user provided
mapping between "configuration" compatible string and FDT filename. The
mapping could be maintained in-tree for those base+addonXYZ FDTs if
desired.

Also, Simon's FIT image "extensions" proposal [1] adds more metadata to
the FIT image to cover these addons that currently don't have distinct
compatible strings.


ChenYu

[1] https://lore.kernel.org/u-boot/CAPnjgZ06s64C2ux1rABNAnMv3q4W++sjhNGCO_u=
PMH_9sTF7Mw@mail.gmail.com/