| Message ID | 20240902112735.728574-1-michael@walle.cc |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] linux: add support for device tree overlays | expand |
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 >
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))
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
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
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
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
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
On Mon, Sep 02, 2024 at 05:07:20PM +0200, Michael Walle via buildroot wrote: > > > Either way: > > Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com> > > Thanks! Thomas, Any chance of getting this patch picked up? Kind regards, Niklas
On Mon, Sep 02, 2024 at 02:38:50PM +0200, Niklas Cassel wrote: > 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> > > --- Hello Michael, Considering that this patch supports both in-tree and out-of-tree device tree overlays. I just saw this: https://lore.kernel.org/buildroot/CAFOYHZDQmMRuK76TpOSAOFPdqAb4gpw=LNKfmpu=sqAD1EMhFg@mail.gmail.com/T/#u https://lore.kernel.org/all/CAK7LNAR4h6NZ+D0BK+q4VQBeHWpjzRBQFQ9ovBrftM=6dHRcUg@mail.gmail.com/ It appears that it will no longer work to copy out-of-tree source files into the kernel directory (which this patch does). Does perhaps this patch need a V3 that drops support for out-of-tree device tree overlays? Kind regards, Niklas
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))
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(-)