diff mbox series

[v2] linux: add support for device tree overlays

Message ID 20240902112735.728574-1-michael@walle.cc
State New
Headers show
Series [v2] linux: add support for device tree overlays | expand

Commit Message

Michael Walle Sept. 2, 2024, 11:27 a.m. UTC
The linux kernel can build device tree overlays (.dtbo) itself. Add
support to build and copy them along with the actual device trees.
These can either be in-tree device tree overlays
(BR2_LINUX_KERNEL_INTREE_DTSO_NAMES) or they can be provided outside of
the kernel (BR2_LINUX_KERNEL_CUSTOM_DTS_PATH). In the latter case, the
overlay source files will be copied into the kernel tree first.

Signed-off-by: Michael Walle <michael@walle.cc>
---
Regarding using the .dtso suffix (or the lack of here) in the
config symbol: I guess BR2_LINUX_KERNEL_INTREE_DTS_NAME used to
just a name in the good old days (and for arm32). But nowadays that
"name" also need a path prefix which makes it kind of a mix between
name and filename, i.e. freescale/imx8mm-evk. IMHO that looks a bit
odd, but I don't care too much and for the sake of consistency the
new config option also just use the "name" variant.

v2:
 - don't use the ".dtso" suffix, just use the name
 - renamed BR2_LINUX_KERNEL_INTREE_DTBOS to
   BR2_LINUX_KERNEL_INTREE_DTSO_NAMES
 - remove leftover $(error debug)
 - rebased to latest next

 linux/Config.in | 14 +++++++++++---
 linux/linux.mk  |  7 +++++--
 2 files changed, 16 insertions(+), 5 deletions(-)

Comments

Niklas Cassel Sept. 2, 2024, 12:38 p.m. UTC | #1
On Mon, Sep 02, 2024 at 01:27:35PM +0200, Michael Walle wrote:
> The linux kernel can build device tree overlays (.dtbo) itself. Add
> support to build and copy them along with the actual device trees.
> These can either be in-tree device tree overlays
> (BR2_LINUX_KERNEL_INTREE_DTSO_NAMES) or they can be provided outside of
> the kernel (BR2_LINUX_KERNEL_CUSTOM_DTS_PATH). In the latter case, the
> overlay source files will be copied into the kernel tree first.
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> Regarding using the .dtso suffix (or the lack of here) in the
> config symbol: I guess BR2_LINUX_KERNEL_INTREE_DTS_NAME used to
> just a name in the good old days (and for arm32). But nowadays that
> "name" also need a path prefix which makes it kind of a mix between
> name and filename, i.e. freescale/imx8mm-evk. IMHO that looks a bit
> odd, but I don't care too much and for the sake of consistency the
> new config option also just use the "name" variant.

Well, like you say, the need to specify a "machine arch" prefix is how
it currently works for BR2_LINUX_KERNEL_INTREE_DTS_NAME, see e.g.:
configs/pine64_star64_defconfig:BR2_LINUX_KERNEL_INTREE_DTS_NAME="starfive/jh7110-pine64-star64"
configs/qemu_arm_vexpress_defconfig:BR2_LINUX_KERNEL_INTREE_DTS_NAME="arm/vexpress-v2p-ca9"
configs/raspberrypi0_defconfig:BR2_LINUX_KERNEL_INTREE_DTS_NAME="broadcom/bcm2708-rpi-zero"
configs/roc_pc_rk3399_defconfig:BR2_LINUX_KERNEL_INTREE_DTS_NAME="rockchip/rk3399-roc-pc"

So this is nothing new, so I don't think it is anything to worry about.


> 
> v2:
>  - don't use the ".dtso" suffix, just use the name
>  - renamed BR2_LINUX_KERNEL_INTREE_DTBOS to
>    BR2_LINUX_KERNEL_INTREE_DTSO_NAMES
>  - remove leftover $(error debug)
>  - rebased to latest next
> 
>  linux/Config.in | 14 +++++++++++---
>  linux/linux.mk  |  7 +++++--
>  2 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/linux/Config.in b/linux/Config.in
> index 429a7eabef..e2432dadd0 100644
> --- a/linux/Config.in
> +++ b/linux/Config.in
> @@ -417,12 +417,20 @@ config BR2_LINUX_KERNEL_INTREE_DTS_NAME
>  	  the trailing .dts. You can provide a list of
>  	  dts files to build, separated by spaces.
>  
> +config BR2_LINUX_KERNEL_INTREE_DTSO_NAMES

Hm... the config for DTS is called:
BR2_LINUX_KERNEL_INTREE_DTS_NAME
and supports multiple names separated by spaces.

This new option also supports multiple names supported by spaces,
but is called:
BR2_LINUX_KERNEL_INTREE_DTSO_NAMES

For consistency, should this new option perhaps be called
BR2_LINUX_KERNEL_INTREE_DTSO_NAME ?

Either way:
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>


> +	string "In-tree Device Tree Overlay file names"
> +	help
> +	  Names of in-tree device tree overlay, without the trailing
> +	  .dtso which should be built and installed into the target
> +	  system, separated by spaces.
> +
>  config BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
>  	string "Out-of-tree Device Tree Source file paths"
>  	help
> -	  Paths to out-of-tree Device Tree Source (.dts) and Device Tree
> -	  Source Include (.dtsi) files, separated by spaces. These files
> -	  will be copied to the kernel sources and the .dts files will
> +	  Paths to out-of-tree Device Tree Source (.dts), Device Tree
> +	  Source Include (.dtsi) and Device Tree Overlay Source (.dtso)
> +	  files, separated by spaces. These files will be copied to the
> +	  kernel sources and the .dts files will
>  	  be compiled from there.
>  
>  config BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME
> diff --git a/linux/linux.mk b/linux/linux.mk
> index 16d9f19470..a850353718 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -193,14 +193,17 @@ endif
>  LINUX_VERSION_PROBED = `MAKEFLAGS='$(filter-out w,$(MAKEFLAGS))' $(BR2_MAKE) $(LINUX_MAKE_FLAGS) -C $(LINUX_DIR) --no-print-directory -s kernelrelease 2>/dev/null`
>  
>  LINUX_DTS_NAME += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTS_NAME))
> +LINUX_DTSO_NAMES += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTSO_NAMES))
>  
>  # We keep only the .dts files, so that the user can specify both .dts
>  # and .dtsi files in BR2_LINUX_KERNEL_CUSTOM_DTS_PATH. Both will be
>  # copied to arch/<arch>/boot/dts, but only the .dts files will
>  # actually be generated as .dtb.
> -LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))
> +LINUX_CUSTOM_DTS_PATH = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH))
> +LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
> +LINUX_DTSO_NAMES += $(basename $(filter %.dtso,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
>  
> -LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME))
> +LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME)) $(addsuffix .dtbo,$(LINUX_DTSO_NAMES))
>  
>  ifeq ($(BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM),y)
>  LINUX_IMAGE_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_IMAGE_NAME))
> -- 
> 2.39.2
>
Fiona Klute Sept. 2, 2024, 2:32 p.m. UTC | #2
Am 02.09.24 um 13:27 schrieb Michael Walle via buildroot:
> The linux kernel can build device tree overlays (.dtbo) itself. Add
> support to build and copy them along with the actual device trees.
> These can either be in-tree device tree overlays
> (BR2_LINUX_KERNEL_INTREE_DTSO_NAMES) or they can be provided outside of
> the kernel (BR2_LINUX_KERNEL_CUSTOM_DTS_PATH). In the latter case, the
> overlay source files will be copied into the kernel tree first.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> Regarding using the .dtso suffix (or the lack of here) in the
> config symbol: I guess BR2_LINUX_KERNEL_INTREE_DTS_NAME used to
> just a name in the good old days (and for arm32). But nowadays that
> "name" also need a path prefix which makes it kind of a mix between
> name and filename, i.e. freescale/imx8mm-evk. IMHO that looks a bit
> odd, but I don't care too much and for the sake of consistency the
> new config option also just use the "name" variant.
>
> v2:
>   - don't use the ".dtso" suffix, just use the name
>   - renamed BR2_LINUX_KERNEL_INTREE_DTBOS to
>     BR2_LINUX_KERNEL_INTREE_DTSO_NAMES
>   - remove leftover $(error debug)
>   - rebased to latest next
>
>   linux/Config.in | 14 +++++++++++---
>   linux/linux.mk  |  7 +++++--
>   2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/linux/Config.in b/linux/Config.in
> index 429a7eabef..e2432dadd0 100644
> --- a/linux/Config.in
> +++ b/linux/Config.in
> @@ -417,12 +417,20 @@ config BR2_LINUX_KERNEL_INTREE_DTS_NAME
>   	  the trailing .dts. You can provide a list of
>   	  dts files to build, separated by spaces.
>
> +config BR2_LINUX_KERNEL_INTREE_DTSO_NAMES
> +	string "In-tree Device Tree Overlay file names"
> +	help
> +	  Names of in-tree device tree overlay, without the trailing
> +	  .dtso which should be built and installed into the target
> +	  system, separated by spaces.
> +
>   config BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
>   	string "Out-of-tree Device Tree Source file paths"
>   	help
> -	  Paths to out-of-tree Device Tree Source (.dts) and Device Tree
> -	  Source Include (.dtsi) files, separated by spaces. These files
> -	  will be copied to the kernel sources and the .dts files will
> +	  Paths to out-of-tree Device Tree Source (.dts), Device Tree
> +	  Source Include (.dtsi) and Device Tree Overlay Source (.dtso)
> +	  files, separated by spaces. These files will be copied to the
> +	  kernel sources and the .dts files will
>   	  be compiled from there.
>
>   config BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME
> diff --git a/linux/linux.mk b/linux/linux.mk
> index 16d9f19470..a850353718 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -193,14 +193,17 @@ endif
>   LINUX_VERSION_PROBED = `MAKEFLAGS='$(filter-out w,$(MAKEFLAGS))' $(BR2_MAKE) $(LINUX_MAKE_FLAGS) -C $(LINUX_DIR) --no-print-directory -s kernelrelease 2>/dev/null`
>
>   LINUX_DTS_NAME += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTS_NAME))
> +LINUX_DTSO_NAMES += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTSO_NAMES))
>
>   # We keep only the .dts files, so that the user can specify both .dts
>   # and .dtsi files in BR2_LINUX_KERNEL_CUSTOM_DTS_PATH. Both will be
>   # copied to arch/<arch>/boot/dts, but only the .dts files will
>   # actually be generated as .dtb.
> -LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))
> +LINUX_CUSTOM_DTS_PATH = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH))
> +LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
> +LINUX_DTSO_NAMES += $(basename $(filter %.dtso,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
>
> -LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME))
> +LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME)) $(addsuffix .dtbo,$(LINUX_DTSO_NAMES))

This looks like the DTBOs will be installed to $BINARIES_DIR along with
the DTBs. At least on RPi platforms it'd be preferable to be able to put
them in an overlays/ directory, to make it easier to create the
structure expected by the firmware in a genimage config without
templating. I don't know how common this is across other platforms that
use DT overlays.

Would it be practical to add an option to install DTBOs in a
(configurable) subdirectory?

Either way thank you for working on this!

Best regards,
Fiona

>   ifeq ($(BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM),y)
>   LINUX_IMAGE_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_IMAGE_NAME))
Michael Walle Sept. 2, 2024, 3:02 p.m. UTC | #3
Hi,

> This looks like the DTBOs will be installed to $BINARIES_DIR along with
> the DTBs. At least on RPi platforms it'd be preferable to be able to 
> put
> them in an overlays/ directory, to make it easier to create the
> structure expected by the firmware in a genimage config without
> templating. I don't know how common this is across other platforms that
> use DT overlays.
> 
> Would it be practical to add an option to install DTBOs in a
> (configurable) subdirectory?

Isn't that what is the BR2_ROOTFS_*_SCRIPT are for? I.e. to customize
the final image to your/the board likings?

-michael
Michael Walle Sept. 2, 2024, 3:07 p.m. UTC | #4
Hi,

>> The linux kernel can build device tree overlays (.dtbo) itself. Add
>> support to build and copy them along with the actual device trees.
>> These can either be in-tree device tree overlays
>> (BR2_LINUX_KERNEL_INTREE_DTSO_NAMES) or they can be provided outside 
>> of
>> the kernel (BR2_LINUX_KERNEL_CUSTOM_DTS_PATH). In the latter case, the
>> overlay source files will be copied into the kernel tree first.
>> 
>> Signed-off-by: Michael Walle <michael@walle.cc>
>> ---
>> Regarding using the .dtso suffix (or the lack of here) in the
>> config symbol: I guess BR2_LINUX_KERNEL_INTREE_DTS_NAME used to
>> just a name in the good old days (and for arm32). But nowadays that
>> "name" also need a path prefix which makes it kind of a mix between
>> name and filename, i.e. freescale/imx8mm-evk. IMHO that looks a bit
>> odd, but I don't care too much and for the sake of consistency the
>> new config option also just use the "name" variant.
> 
> Well, like you say, the need to specify a "machine arch" prefix is how
> it currently works for BR2_LINUX_KERNEL_INTREE_DTS_NAME, see e.g.:
> configs/pine64_star64_defconfig:BR2_LINUX_KERNEL_INTREE_DTS_NAME="starfive/jh7110-pine64-star64"
> configs/qemu_arm_vexpress_defconfig:BR2_LINUX_KERNEL_INTREE_DTS_NAME="arm/vexpress-v2p-ca9"
> configs/raspberrypi0_defconfig:BR2_LINUX_KERNEL_INTREE_DTS_NAME="broadcom/bcm2708-rpi-zero"
> configs/roc_pc_rk3399_defconfig:BR2_LINUX_KERNEL_INTREE_DTS_NAME="rockchip/rk3399-roc-pc"
> 
> So this is nothing new, so I don't think it is anything to worry about.

Just because it was always this way doesn't make it correct :) In fact,
as explained in v1, if the extension would have been carried along, one 
could
have used that to add the .dtso support (by distiguishing between .dts 
and .dtso)

>> v2:
>>  - don't use the ".dtso" suffix, just use the name
>>  - renamed BR2_LINUX_KERNEL_INTREE_DTBOS to
>>    BR2_LINUX_KERNEL_INTREE_DTSO_NAMES
>>  - remove leftover $(error debug)
>>  - rebased to latest next
>> 
>>  linux/Config.in | 14 +++++++++++---
>>  linux/linux.mk  |  7 +++++--
>>  2 files changed, 16 insertions(+), 5 deletions(-)
>> 
>> diff --git a/linux/Config.in b/linux/Config.in
>> index 429a7eabef..e2432dadd0 100644
>> --- a/linux/Config.in
>> +++ b/linux/Config.in
>> @@ -417,12 +417,20 @@ config BR2_LINUX_KERNEL_INTREE_DTS_NAME
>>  	  the trailing .dts. You can provide a list of
>>  	  dts files to build, separated by spaces.
>> 
>> +config BR2_LINUX_KERNEL_INTREE_DTSO_NAMES
> 
> Hm... the config for DTS is called:
> BR2_LINUX_KERNEL_INTREE_DTS_NAME
> and supports multiple names separated by spaces.
> 
> This new option also supports multiple names supported by spaces,
> but is called:
> BR2_LINUX_KERNEL_INTREE_DTSO_NAMES
> 
> For consistency, should this new option perhaps be called
> BR2_LINUX_KERNEL_INTREE_DTSO_NAME ?

Same as above, I'd say the DTS_NAME is a legacy naming, thus I don't
think we should use the singular here. We already know this will support
multiple names.

> Either way:
> Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>

Thanks!

-michael
Fiona Klute Sept. 2, 2024, 3:33 p.m. UTC | #5
Am 02.09.24 um 17:02 schrieb Michael Walle:
> Hi,
>
>> This looks like the DTBOs will be installed to $BINARIES_DIR along with
>> the DTBs. At least on RPi platforms it'd be preferable to be able to put
>> them in an overlays/ directory, to make it easier to create the
>> structure expected by the firmware in a genimage config without
>> templating. I don't know how common this is across other platforms that
>> use DT overlays.
>>
>> Would it be practical to add an option to install DTBOs in a
>> (configurable) subdirectory?
>
> Isn't that what is the BR2_ROOTFS_*_SCRIPT are for? I.e. to customize
> the final image to your/the board likings?
It's definitely possible, the configurable install dir would just make
the post image script that builds a disk image from the rootfs and files
in $BINARIES_DIR simpler:

With all DTBOs installed into $BINARIES_DIR/overlays I only need to list
that directory in the genimage config to be included in the boot
partition (in the "files" list).

Without a custom install dir I need to either move the files around in
$BINARIES_DIR, or generate a relatively complex genimage config with a
"file" entry for each DTBO to map it to the right path. The former is
pretty simple, but might break anything that expects the DTBOs in the
original location. There probably isn't anything that does for now
because there have been no DTBOs installed by the kernel previously, but
I can't know how future proof that'll be.

That's why I wrote the option would make it *easier* to create the
structure required by RPi firmware, it's not a necessity. If you choose
not to add it I'll probably choose the "move files around in post image
script" option and fix it if it breaks. :-)

Best regards,
Fiona
Gaël PORTAY Sept. 2, 2024, 8:52 p.m. UTC | #6
All, thank you for your interest in bringing the support for dtbo!

On Mon Sep 2, 2024 at 4:32 PM CEST, Fiona Klute via buildroot wrote:
> > -LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))
> > +LINUX_CUSTOM_DTS_PATH = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH))
> > +LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
> > +LINUX_DTSO_NAMES += $(basename $(filter %.dtso,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
> >
> > -LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME))
> > +LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME)) $(addsuffix .dtbo,$(LINUX_DTSO_NAMES))
>
> This looks like the DTBOs will be installed to $BINARIES_DIR along with
> the DTBs. At least on RPi platforms it'd be preferable to be able to put
> them in an overlays/ directory, to make it easier to create the
> structure expected by the firmware in a genimage config without
> templating. I don't know how common this is across other platforms that
> use DT overlays.
>

IIRC, I have seen platforms that put the dtb and dtbo at the same place.

I strongly think the Pi is the one that put the dtbo in the subdirectory
overlays/.

> Would it be practical to add an option to install DTBOs in a
> (configurable) subdirectory?
>

Well, I do not really like adding an option to set the target directory.

In my patch serie I have completly split the dtbo from the dtb; so you
can keep or not the "top" directory for dtb (broadcom) and for dtbo
(overlays).

I do not think it worth it, but it helps for the Pi.

In the case of the Pi, you set:

	# BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME is not set
	BR2_LINUX_KERNEL_DTBO_KEEP_DIRNAME=y

To install dtbos to $BINARIES_DIR/overlays and dtb to $BINARIES_DIR.

	https://patchwork.ozlabs.org/project/buildroot/patch/20240902203533.3961108-2-gael.portay@rtone.fr/

I have no strong opinion about your work (more simple) and mine (more
duplication).

> Either way thank you for working on this!
>

Yes thank you (again).

> Best regards,
> Fiona
>

Kind Regards,
Gaël
Fiona Klute Sept. 3, 2024, 9:49 a.m. UTC | #7
Am 02.09.24 um 22:52 schrieb Gaël PORTAY:
> All, thank you for your interest in bringing the support for dtbo!
>
> On Mon Sep 2, 2024 at 4:32 PM CEST, Fiona Klute via buildroot wrote:
>>> -LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))
>>> +LINUX_CUSTOM_DTS_PATH = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH))
>>> +LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
>>> +LINUX_DTSO_NAMES += $(basename $(filter %.dtso,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
>>>
>>> -LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME))
>>> +LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME)) $(addsuffix .dtbo,$(LINUX_DTSO_NAMES))
>>
>> This looks like the DTBOs will be installed to $BINARIES_DIR along with
>> the DTBs. At least on RPi platforms it'd be preferable to be able to put
>> them in an overlays/ directory, to make it easier to create the
>> structure expected by the firmware in a genimage config without
>> templating. I don't know how common this is across other platforms that
>> use DT overlays.
>>
>
> IIRC, I have seen platforms that put the dtb and dtbo at the same place.
>
> I strongly think the Pi is the one that put the dtbo in the subdirectory
> overlays/.
>
>> Would it be practical to add an option to install DTBOs in a
>> (configurable) subdirectory?
>>
>
> Well, I do not really like adding an option to set the target directory.
>
> In my patch serie I have completly split the dtbo from the dtb; so you
> can keep or not the "top" directory for dtb (broadcom) and for dtbo
> (overlays).
>
> I do not think it worth it, but it helps for the Pi.
>
> In the case of the Pi, you set:
>
> 	# BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME is not set
> 	BR2_LINUX_KERNEL_DTBO_KEEP_DIRNAME=y
>
> To install dtbos to $BINARIES_DIR/overlays and dtb to $BINARIES_DIR.

This is for in-tree DTBOs (which is definitely a good thing to
support!), my question was about out-of-tree ones. To explain my
perspective: I currently have a package in an external tree that uses
host-dtc to compile custom DTSOs and install them to
$BINARIES_DIR/overlays, and it'd be nice to replace that with generic
infrastructure for overlays.

With Michael's patch that should mostly be possible already, I'd just
have to shuffle the DTBOs around in a post-build/post-image script to
put them where the firmware needs them, hence my question about a
configurable target dir. If that's considered too niche for generic
infrastructure, fair enough. :-)

Best regards,
Fiona

> 	https://patchwork.ozlabs.org/project/buildroot/patch/20240902203533.3961108-2-gael.portay@rtone.fr/
>
> I have no strong opinion about your work (more simple) and mine (more
> duplication).
>
>> Either way thank you for working on this!
>>
>
> Yes thank you (again).
>
>> Best regards,
>> Fiona
>>
>
> Kind Regards,
> Gaël
diff mbox series

Patch

diff --git a/linux/Config.in b/linux/Config.in
index 429a7eabef..e2432dadd0 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -417,12 +417,20 @@  config BR2_LINUX_KERNEL_INTREE_DTS_NAME
 	  the trailing .dts. You can provide a list of
 	  dts files to build, separated by spaces.
 
+config BR2_LINUX_KERNEL_INTREE_DTSO_NAMES
+	string "In-tree Device Tree Overlay file names"
+	help
+	  Names of in-tree device tree overlay, without the trailing
+	  .dtso which should be built and installed into the target
+	  system, separated by spaces.
+
 config BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
 	string "Out-of-tree Device Tree Source file paths"
 	help
-	  Paths to out-of-tree Device Tree Source (.dts) and Device Tree
-	  Source Include (.dtsi) files, separated by spaces. These files
-	  will be copied to the kernel sources and the .dts files will
+	  Paths to out-of-tree Device Tree Source (.dts), Device Tree
+	  Source Include (.dtsi) and Device Tree Overlay Source (.dtso)
+	  files, separated by spaces. These files will be copied to the
+	  kernel sources and the .dts files will
 	  be compiled from there.
 
 config BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME
diff --git a/linux/linux.mk b/linux/linux.mk
index 16d9f19470..a850353718 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -193,14 +193,17 @@  endif
 LINUX_VERSION_PROBED = `MAKEFLAGS='$(filter-out w,$(MAKEFLAGS))' $(BR2_MAKE) $(LINUX_MAKE_FLAGS) -C $(LINUX_DIR) --no-print-directory -s kernelrelease 2>/dev/null`
 
 LINUX_DTS_NAME += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTS_NAME))
+LINUX_DTSO_NAMES += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTSO_NAMES))
 
 # We keep only the .dts files, so that the user can specify both .dts
 # and .dtsi files in BR2_LINUX_KERNEL_CUSTOM_DTS_PATH. Both will be
 # copied to arch/<arch>/boot/dts, but only the .dts files will
 # actually be generated as .dtb.
-LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))
+LINUX_CUSTOM_DTS_PATH = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH))
+LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
+LINUX_DTSO_NAMES += $(basename $(filter %.dtso,$(notdir $(LINUX_CUSTOM_DTS_PATH))))
 
-LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME))
+LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME)) $(addsuffix .dtbo,$(LINUX_DTSO_NAMES))
 
 ifeq ($(BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM),y)
 LINUX_IMAGE_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_IMAGE_NAME))