Message-ID: <CAK7LNARADnpCHvNWHLqb9acVNqzwDRuLiKbKe4XZwM4_Ts+ypg@mail.gmail.com>
Date: Wed, 6 Mar 2024 01:30:18 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Chen-Yu Tsai <wenst@...omium.org>
Cc: Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Simon Glass <sjg@...omium.org>
Subject: Re: [PATCH RFC] kbuild: create a list of all built DTB files

On Mon, Mar 4, 2024 at 1:37 PM Chen-Yu Tsai <wenst@...omium.org> wrote:
>
> On Thu, Feb 29, 2024 at 11:35 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
> >
> > On Thu, Feb 29, 2024 at 11:38 AM Chen-Yu Tsai <wenst@...omium.org> wrote:
> > >
> > > On Sun, Feb 25, 2024 at 4:21 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
> > > >
> > > > On Fri, Feb 23, 2024 at 6:23 PM Chen-Yu Tsai <wenst@...omium.org> wrote:
> > > > >
> > > > > It is useful to have a list of all composite *.dtb files, along with
> > > > > their individual components, generated from the current build.
> > > > >
> > > > > With this commit, 'make dtbs' creates arch/*/boot/dts/dtbs-components,
> > > > > which lists the composite dtb files created in the current build. It
> > > > > maintains the order of the dtb-y additions in Makefiles although the
> > > > > order is not important for DTBs.
> > > > >
> > > > > This compliments the list of all *.dtb and *.dtbo files in dtbs-list,
> > > > > which only includes the files directly added to dtb-y.
> > > > >
> > > > > For example, consider this case:
> > > > >
> > > > >     foo-dtbs := foo_base.dtb foo_overlay.dtbo
> > > > >     dtb-y := bar.dtb foo.dtb
> > > > >
> > > > > In this example, the new list will include foo.dtb with foo_base.dtb and
> > > > > foo_overlay.dtbo on the same line, but not bar.dtb.
> > > > >
> > > > > Signed-off-by: Chen-Yu Tsai <wenst@...omium.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 image
> > > > > generation or other toolchains to consume. For example, instead of
> > > > > including each dtb, a toolchain could realize that some are put together
> > > > > using others, and if the bootloader supports it, put together commands
> > > > > to reassemble the end result from the original parts.
> > > > >
> > > > > This is based on and complements Masahiro-san's recent dtbs-list work.
> > > >
> > > >
> > > >
> > > > 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 after all).
> > > >
> > > > This should be discussed together with how Simon's script will look like.
> > > >
> > > > 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 top
> > > 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?


Yes.
It is possible to implement it, but I do not see a point
to implement what we do not know how to use.



>
> 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.

It makes the purpose of this work even more obscure.

For the purpose of avoiding duplication,
we can take the first DTB (or the smallest size)
when we encounter a duplicated compatible string.



>
> 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.


That is one way, but I do not think such a configuration file
is maintainable.

Rob suggested overwriting the compatible string,
but I do not think we got consensus.



> 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.

I think this is yet another way, but I am not sure
how to derive the extension compatible string.






Even if we decide to implement base/overlay split,
we may not need to add anything to Makefile.

We already have .*.cmd files, and we can know
if it is a combined DTB or not, by parsing the .*.cmd
from the python script.

It might be a bit messy, but it is what we do
in scripts/clang-tools/gen_compile_commands.py









>
>
> ChenYu
>
> [1] https://lore.kernel.org/u-boot/CAPnjgZ06s64C2ux1rABNAnMv3q4W++sjhNGCO_uPMH_9sTF7Mw@mail.gmail.com/
--
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists