linux-kernel - Re: [PATCH RFC] kbuild: create a list of all built DTB files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXv+5HB7gXJ0x1uVdgbWaRWS8+rN6FwEgyGLObxr_cfyLty6A@mail.gmail.com>
Date: Mon, 4 Mar 2024 12:36:55 +0800
From: Chen-Yu Tsai <wenst@...omium.org>
To: Masahiro Yamada <masahiroy@...nel.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 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?

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_uPMH_9sTF7Mw@mail.gmail.com/