[0/4] kbuild: create a list of DTBs and allow to install base dtb and overlays

1/4 and 2/4 are less controvertial refactoring. This will be useful
for future cleanups.

3/4 and 4/4 address the current dtbs_install limitation; when the
generic -dtbs syntax is used in Makefiles, only the final assembled
dtbs are installed. We need to manually copy base dtbs and overlays
if necessary. It would be sometimes useful to install such base
componennts.


Masahiro Yamada (4):
  kbuild: create a list of all built DTB files
  kbuild: simplify dtbs_install by reading the list of compiled DTBs
  kbuild: create a list of base and overlays for each DTB
  kbuild: allow 'make dtbs_install' to install primitive DTBs

 .gitignore                      |  2 ++
 Documentation/kbuild/kbuild.rst |  6 ++++++
 Makefile                        |  6 +++---
 scripts/Kbuild.include          |  6 ------
 scripts/Makefile.build          | 26 +++++++++++++++-------
 scripts/Makefile.dtbinst        | 38 +++++++++++++++++++++------------
 scripts/Makefile.lib            |  8 +++++++
 7 files changed, 61 insertions(+), 31 deletions(-)

On Tue, Jan 09, 2024 at 09:07:37PM +0900, Masahiro Yamada wrote:
> Commit 15d16d6dadf6 ("kbuild: Add generic rule to apply fdtoverlay")
> introduced the -dtbs syntax to apply overlays during the build process.
> 
> However, scripts/Makefile.dtbinst is not aware of the -dtbs syntax,
> so 'make dtbs_install' installs the files directly added to dtb-y.
> (Presumably, it was intentional.)

Yes. The intent was the Makefile should define what's installed or not. 
There's 2 reasons to apply overlays in the build. The first is so a DTB 
can be refactored into a base plus overlay(s) and we keep the original 
full DTB. The second is to test that overlays actually apply because 
testing that at boot time in bootloader is a poor experience and we 
don't want overlays which don't apply to upstream DTs.

Whatever targets you want installed put in dtb-y. Whatever targets are 
just for testing, put in dtb-. The latter are then enabled with 
CONFIG_OF_ALL_DTBS.

> For example, consider this case:
> 
>     foo1-dtbs := foo_base.dtb foo_overlay1.dtbo
>     foo2-dtbs := foo_base.dtb foo_overlay2.dtbo
>     dtb-y := foo1.dtb foo2.dtb
> 
> 'make dtbs_install' only installs foo1.dtb and foo2.dtb. It is suitable
> when the boot image supports a single hardware configuration, or when
> the boot loader in use does not support applying overlays.
> 
> However, when creating a boot image with multiple board supports, it
> wastes storage space, as foo1.dtb and foo2.dtb have foo_base.dtb in
> common.
> 
> From a space perspective, a more optimal solution is to install
> foo_base.dtb, foo_overlay1.dtbo, and foo_overlay2.dtbo, then assemble
> the final dtb (either foo1.dtb or foo2.dtb) on the boot loader.
> 
> This commit adds a new flag, INSTALL_DTBS_PRIMITIVE.
> 
> With INSTALL_DTBS_PRIMITIVE=1, 'make dtbs_install' will install primitive
> files (such as foo_base.dtb, foo_overlay1.dtbo, and foo_overlay2.dtbo in
> this case).

And not install foo1.dtb and foo2.dtb, right? What if one wants to 
install everything? Seems like this needs to be a 3-way option.

I'm not really convinced we need this in the first place though.

> 
> Without INSTALL_DTBS_PRIMITIVE, the current behavior is maintained
> (foo1.dtb and foo2.dtb will be installed in this case).