[PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[Vincent Jardin]

A board whose DTS is not in U-Boot does not have a clean way to build it.

Today the build systems copy the sources into the tree and follow its
layout: Buildroot has copied BR2_TARGET_UBOOT_CUSTOM_DTS_PATH into
arch/<arch>/dts since 2017 [1][2], and had to learn
dts/upstream/src/<arch>/<vendor> for OF_UPSTREAM boards this September [3];
Yocto layers copy their .dts into arch/<arch>/dts and sed a dtb-y line
into its Makefile [4], copy their -u-boot.dtsi there [5], or tell the user
to patch the dts into the U-Boot source [6].

This series adds a way to build it from a directory outside the tree:

    make EXT_DTS_DIR=/path/to/dts DEVICE_TREE=myboard

The benefits for the build systems:

- Buildroot: BR2_TARGET_UBOOT_CUSTOM_DTS_PATH could become a make option,
  EXT_DTS_DIR=<dir> in UBOOT_MAKE_OPTS, for every U-Boot layout at once,
  without the copy, the sed, or the question of where the -u-boot.dtsi
  goes: next to the .dts. A U-Boot upgrade no longer moves the files.

- Yocto: a BSP layer adds EXTRA_OEMAKE += "EXT_DTS_DIR=${UNPACKDIR}/dts"
  and keeps its device trees in the layer, versioned with the board, not
  with the U-Boot recipe; a UBOOT_CONFIG with several configurations
  passes its DEVICE_TREE per configuration as before.

- A bring-up, or a board whose device tree is maintained with the
  kernel's, keeps one device tree repository for both; nothing is copied
  into U-Boot until the board goes upstream.

Patch 1 makes "make DEVICE_TREE=<name>" build that device tree in the
directories built through scripts/Makefile.dts, which listed Kconfig's
only (the VisionFive 2 report [7]). Patch 2 looks for <name>-u-boot.dtsi
next to the .dts before arch/<arch>/dts. Patch 3 adds EXT_DTS_DIR.

It was tested on main at 2515b39e3f1 using:

- imx8mp_evk (OF_UPSTREAM, SPL, binman): with its .dts copied out of the
  tree, the external build gives dt.dtb, u-boot.dtb, u-boot.itb,
  spl/u-boot-spl.bin and flash.bin identical to the in-tree build,
  in the <vendor>/ layout. A *-u-boot.dtsi next to the source is taken
  first. Touching the source rebuilds, nothing else does.

[1] https://lists.buildroot.org/pipermail/buildroot/2017-April/553477.html
[2] https://gitlab.com/buildroot.org/buildroot/-/blob/master/boot/uboot/uboot.mk
[3] https://lists.buildroot.org/pipermail/buildroot/2026-September/809302.html
[4] https://github.com/karo-electronics/meta-karo/blob/85984e583a110855586938454964a259a323054f/recipes-bsp/u-boot/u-boot-karo.inc
[5] https://github.com/toradex/meta-toradex-tezi/blob/b53871a3df70e8a1d960523d9a4f186e2e1e2bd1/recipes-bsp/u-boot/u-boot-toradex-tezi.inc
[6] https://github.com/Xilinx/meta-xilinx/blob/f55a2890a9fdca73e14253d2383823eff513ba9b/meta-xilinx-core/recipes-bsp/u-boot/u-boot-xlnx.inc
[7] https://lore.kernel.org/u-boot/034a4ae4-b579-42b0-b6b0-3a204737156f@proton.me/


Vincent Jardin (3):
  scripts: Makefile.dts: build the device tree with DEVICE_TREE= too
  scripts: Makefile.lib: add check of -u-boot.dtsi in the device tree
    source
  dts: build the device tree from a directory outside the tree,
    EXT_DTS_DIR

 .gitignore                         |  1 +
 Makefile                           |  9 ++++++-
 doc/develop/devicetree/control.rst | 42 +++++++++++++++++++++++++++---
 dts/Makefile                       | 20 ++++++++++++--
 scripts/Makefile.build             | 11 +++++++-
 scripts/Makefile.dts               | 12 ++++++++-
 scripts/Makefile.lib               | 14 +++++++---
 7 files changed, 98 insertions(+), 11 deletions(-)

---
base-commit: 2515b39e3f1ca1ea341f80b6ad3cbd747341263f
branch: for-upstream/ext-dts-dir

-- 
2.43.0

[PATCH v1 1/3] scripts: Makefile.dts: build the device tree with DEVICE_TREE= too

[Vincent Jardin]

The directories built based on scripts/Makefile.dts,
dts/upstream/src/<arch> and its vendor directories, list the device trees
of Kconfig only:
CONFIG_DEFAULT_DEVICE_TREE, CONFIG_OF_LIST and CONFIG_SPL_OF_LIST.

If "make DEVICE_TREE=<name>" selects another one in dts/Makefile, nothing
builds it, it stops with:

  Device Tree Source (dts/upstream/src/arm64/freescale/<name>.dtb) is not
  correctly specified.

The arch/<arch>/dts directories are not affected: their dtb-y lists are
explicit and DEVICE_TREE picks one of them.

Signed-off-by: Vincent Jardin <vjardin@free.fr>
---

 scripts/Makefile.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts
index 3871a4ad412..fd9ff420585 100644
--- a/scripts/Makefile.dts
+++ b/scripts/Makefile.dts
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 
-dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
+dtb-y += $(patsubst %,%.dtb,$(sort $(DEVICE_TREE) \
+	$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))))
 dtb-y += $(patsubst %,%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST)))
 
 ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
-- 
2.43.0

[PATCH v1 2/3] scripts: Makefile.lib: add check of -u-boot.dtsi in the device tree source

[Vincent Jardin]

The U-Boot extensions of a device tree, <name>-u-boot.dtsi, are looked up
only in arch/$(ARCH)/dts.

Let's try <name>-u-boot.dtsi in the directory of the .dts first, then the
usual candidates of arch/$(ARCH)/dts.

Signed-off-by: Vincent Jardin <vjardin@free.fr>
---

 doc/develop/devicetree/control.rst | 4 ++--
 scripts/Makefile.lib               | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index 7d6117d5c4b..5c1b46b94ab 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -203,8 +203,8 @@ constraints are even more extreme and the devicetree is shrunk to remove
 unwanted nodes, or even turned into C code to avoid access overhead.
 
 U-Boot automatically looks for and includes a file with updates to the standard
-devicetree for your board, searching for them in `arch/<arch>/dts/` in this
-order::
+devicetree for your board, searching first for `<orig_filename>-u-boot.dtsi`
+in the devicetree source, then in `arch/<arch>/dts/` in this order::
 
    <orig_filename>-u-boot.dtsi
    <CONFIG_SYS_SOC>-u-boot.dtsi
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 7cdfacd3ae5..e3b49148b7c 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -223,13 +223,15 @@ ld_flags       = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
 # Try these files in order to find the U-Boot-specific .dtsi include file
 u_boot_dtsi_loc = $(srctree)/arch/$(ARCH)/dts/
 
-u_boot_dtsi_options = $(strip $(wildcard $(u_boot_dtsi_loc)$(basename $(notdir $<))-u-boot.dtsi) \
+u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
+	$(wildcard $(u_boot_dtsi_loc)$(basename $(notdir $<))-u-boot.dtsi) \
 	$(wildcard $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
 	$(wildcard $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
 	$(wildcard $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
 	$(wildcard $(u_boot_dtsi_loc)u-boot.dtsi))
 
 u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \
+	$(dir $<)$(basename $(notdir $<))-u-boot.dtsi \
 	$(u_boot_dtsi_loc)$(basename $(notdir $<))-u-boot.dtsi \
 	$(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
 	$(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
-- 
2.43.0

[PATCH v1 3/3] dts: build the device tree from a directory outside the tree, EXT_DTS_DIR

[Vincent Jardin]

A board whose device tree is not in U-Boot folders has to be copied in:

- Buildroot copies the .dts of BR2_TARGET_UBOOT_CUSTOM_DTS_PATH into
arch/<arch>/dts, it adds/patches a dtb-y line with sed, it copies
into dts/upstream/src/<arch>/<vendor>

- A Yocto layer does about the same in its do_configure. Each copy depends
on the layout of the release it targets, and the -u-boot.dtsi has to go to
yet another place. EXT_DTB takes a .dtb compiled elsewhere, without the
include paths, the -u-boot.dtsi and the DEVICE_TREE_INCLUDES of the
U-Boot build.

Let's add EXT_DTS_DIR=<dir>:
the .dts of DEVICE_TREE, OF_LIST, SPL_OF_LIST and OF_OVERLAY_LIST
which are compiled from that directory instead of dt_dir.
It can use scripts/Makefile.dts as dts/upstream is, with the same automatic
.dtsi handling and the same include paths, where the directory stands in
for dt_dir: an OF_UPSTREAM board which keeps its <vendor>/ subdirectory
finds the SoC files of dts/upstream before the older copies of
arch/<arch>/dts, as in the tree.

The directory is only read: the .dtb files are generated into dts/external
of the build tree, based on dt_dir, so dt.dtb, u-boot.img, fit-dtb.blob
and binman use them from there.

A Makefile or Kbuild in the directory is used if present, to add DTC_FLAGS
or dtb-y entries, if not scripts/Makefile.dts is used.

Signed-off-by: Vincent Jardin <vjardin@free.fr>

---

 .gitignore                         |  1 +
 Makefile                           |  9 ++++++-
 doc/develop/devicetree/control.rst | 38 +++++++++++++++++++++++++++++-
 dts/Makefile                       | 20 ++++++++++++++--
 scripts/Makefile.build             | 11 ++++++++-
 scripts/Makefile.dts               |  9 +++++++
 scripts/Makefile.lib               | 10 ++++++--
 7 files changed, 91 insertions(+), 7 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0e09715cc60..f03baaba3ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -19,6 +19,7 @@
 *.dtb.clean.dts
 *.dtb.diff
 *.dtb.full.dts
+/dts/external/
 *.elf
 *.exe
 *.fit
diff --git a/Makefile b/Makefile
index 292d1e07356..1a66143545d 100644
--- a/Makefile
+++ b/Makefile
@@ -834,6 +834,13 @@ else
 dt_dir := arch/$(ARCH)/dts
 endif
 
+ifneq ($(EXT_DTS_DIR),)
+dt_src_dir := $(abspath $(EXT_DTS_DIR))
+dt_dir := dts/external
+else
+dt_src_dir := $(dt_dir)
+endif
+
 include $(srctree)/arch/$(ARCH)/Makefile
 endif
 endif
@@ -1468,7 +1475,7 @@ fit-dtb.blob.gz: fit-dtb.blob
 fit-dtb.blob.lzo: fit-dtb.blob
 	@lzop -f9 $< > $@
 
-of_list_srcs := $(patsubst %,$(dt_dir)/%.dts,$(subst ",,$(CONFIG_OF_LIST)))
+of_list_srcs := $(patsubst %,$(dt_src_dir)/%.dts,$(subst ",,$(CONFIG_OF_LIST)))
 fit-dtb.blob: dts/dt.dtb $(of_list_srcs) FORCE
 	$(call if_changed,mkimage)
 ifneq ($(SOURCE_DATE_EPOCH),)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index 5c1b46b94ab..877973b487f 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -152,7 +152,8 @@ EXT_DTB=<filename> to 'make', as in::
    make EXT_DTB=boot/am335x-boneblack-pubkey.dtb
 
 Then U-Boot will copy that file to u-boot.dtb, put it in the .img file
-if used, and u-boot-dtb.bin.
+if used, and u-boot-dtb.bin. To compile the devicetree from files
+outside the tree instead, see :ref:`extdtsdir`.
 
 If you wish to put the fdt at a different address in memory, you can
 define the "fdtcontroladdr" environment variable. This is the hex
@@ -232,6 +233,41 @@ outside the U-Boot repository. You can use `DEVICE_TREE_INCLUDES` Kconfig
 option to specify a list of .dtsi files that will also be included when
 building .dtb files.
 
+.. _extdtsdir:
+
+Devicetree sources outside the tree
+-----------------------------------
+
+A board may keep its devicetree sources outside U-Boot: in a board support
+layer of Yocto or Buildroot, or in a repository shared with the kernel during
+a bring-up. Point the build at that directory with `EXT_DTS_DIR`::
+
+   make EXT_DTS_DIR=/path/to/dts DEVICE_TREE=myboard
+
+The `.dts` files of `DEVICE_TREE`, `OF_LIST`, `SPL_OF_LIST` and
+`OF_OVERLAY_LIST` are then compiled from that directory instead of
+`arch/<arch>/dts` or `dts/upstream/src/<arch>`, with the same include paths,
+so they may include the SoC files of either, and with the same automatic
+`*-u-boot.dtsi` and `DEVICE_TREE_INCLUDES` handling. A `<name>-u-boot.dtsi`
+next to the source is used first (see :ref:`dttweaks`). The names are
+relative to the directory, as they are to `dts/upstream/src/<arch>` for
+`OF_UPSTREAM` boards: keep the `<vendor>/` subdirectory, the sources then
+find the SoC files of `dts/upstream/src/<arch>/<vendor>` before the older
+copies of `arch/<arch>/dts`, as they do in the tree. Every name of those lists
+comes from the directory: a missing one stops the build with a message, so
+trim `OF_LIST` to what the directory provides.
+
+The directory is only read: the `.dtb` files are written to `dts/external` in
+the build tree, and the rest of the build, binman included, takes them from
+there. This directory does not need a Makefile: `scripts/Makefile.dts` builds
+it, with the directory-wide `DTC_FLAGS` of the directory it stands in for, so
+the `.dtb` comes out as it does from the tree. If it has a Makefile or a Kbuild
+file of its own, that one is used instead: it should include
+`scripts/Makefile.dts`, as `dts/upstream/src/arm64/Makefile` does, and may add
+`DTC_FLAGS` or `dtb-y` entries.
+The path is taken as given, so for an `O=` build pass an absolute one.
+`EXT_DTB` remains the way to use a devicetree compiled elsewhere.
+
 Scripts embedded in control DTB
 -------------------------------
 
diff --git a/dts/Makefile b/dts/Makefile
index befc6de1805..2793e0dcde3 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -24,6 +24,22 @@ else
 dt_dir := arch/$(ARCH)/dts
 endif
 
+# EXT_DTS_DIR=<dir>: compile the device tree sources of that directory, outside
+# the tree, instead of those of dt_dir: the .dtb files land in dts/external of
+# the build tree.
+ifneq ($(EXT_DTS_DIR),)
+dt_src_dir := $(abspath $(EXT_DTS_DIR))
+# built by a Makefile or Kbuild of its own if it has one, else by
+# scripts/Makefile.dts
+ext_dts_mk := $(firstword $(wildcard $(dt_src_dir)/Kbuild $(dt_src_dir)/Makefile) \
+		$(srctree)/scripts/Makefile.dts)
+ext_dts_flags := $(shell MAKEFLAGS= $(MAKE) -s -rR --include-dir=$(srctree) \
+		-f $(srctree)/scripts/Makefile.build obj=$(dt_dir) __dtc_flags)
+ext_dts_args := src=$(dt_src_dir) kbuild-file=$(ext_dts_mk) \
+		ext_dts_shadow=$(srctree)/$(dt_dir) ext_dts_flags="$(ext_dts_flags)"
+dt_dir := dts/external
+endif
+
 ifneq ($(CONFIG_OF_UPSTREAM_INCLUDE_LOCAL_FALLBACK_DTBOS),)
 local_dtbos := local-dtbos
 else
@@ -61,7 +77,7 @@ $(DTB): arch-dtbs $(local_dtbos)
 
 PHONY += arch-dtbs
 arch-dtbs:
-	$(Q)$(MAKE) $(build)=$(dt_dir) dtbs
+	$(Q)$(MAKE) $(build)=$(dt_dir) $(ext_dts_args) dtbs
 
 ifneq ($(CONFIG_OF_UPSTREAM_INCLUDE_LOCAL_FALLBACK_DTBOS),)
 PHONY += local-dtbos
@@ -86,7 +102,7 @@ dtbs: $(obj)/dt.dtb
 spl_dtbs: $(obj)/dt-$(SPL_NAME).dtb
 	@:
 
-clean-files := dt.dtb.S
+clean-files := dt.dtb.S external
 
 # Let clean descend into dts directories
 subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts	\
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 73b6769ab90..8b0bef91cf2 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -4,6 +4,9 @@
 # ==========================================================================
 
 # Modified for U-Boot
+ifeq ($(origin src),command line)
+prefix := .
+else
 prefix := vpl
 src := $(patsubst $(prefix)/%,%,$(obj))
 ifeq ($(obj),$(src))
@@ -17,6 +20,7 @@ prefix := .
 endif
 endif
 endif
+endif
 
 PHONY := __build
 __build:
@@ -57,7 +61,8 @@ include scripts/Makefile.compiler
 
 # The filename Kbuild has precedence over Makefile
 kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src))
-include $(or $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Makefile)
+kbuild-file := $(or $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Makefile)
+include $(kbuild-file)
 
 # Added for U-Boot
 asflags-y  += $(PLATFORM_CPPFLAGS)
@@ -499,6 +504,10 @@ $(subdir-ym):
 	need-builtin=$(if $(filter $@/built-in.a, $(subdir-builtin)),1) \
 	need-modorder=$(if $(filter $@/modules.order, $(subdir-modorder)),1)
 
+PHONY += __dtc_flags
+__dtc_flags:
+	@echo $(DTC_FLAGS)
+
 # Add FORCE to the prequisites of a target to force it to be always rebuilt.
 # ---------------------------------------------------------------------------
 
diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts
index fd9ff420585..bcf89b3b3a0 100644
--- a/scripts/Makefile.dts
+++ b/scripts/Makefile.dts
@@ -17,6 +17,15 @@ dtb-y += $(subst $(dt_dir)/,,$(dtb-vendor_dts))
 
 endif
 
+ifneq ($(ext_dts_shadow),)
+ext_dts_missing := $(strip $(foreach f,$(dtb-y),$(if $(wildcard \
+	$(src)/$(patsubst %.dtb,%.dts,$(patsubst %.dtbo,%.dtso,$(f)))),,$(f))))
+ifneq ($(ext_dts_missing),)
+$(error EXT_DTS_DIR: $(src) has no source for $(strip $(ext_dts_missing)); the device \
+	trees of DEVICE_TREE, OF_LIST, SPL_OF_LIST and OF_OVERLAY_LIST all come from it)
+endif
+endif
+
 ifneq ($(CONFIG_SYS_DTC_PAD_BYTES),0)
 DTC_FLAGS += -p $(CONFIG_SYS_DTC_PAD_BYTES)
 endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index e3b49148b7c..1910e08f30c 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -256,9 +256,15 @@ upstream_dtsi_include = $(addprefix -I, $(srctree)/dts/upstream/src/ \
 	$(if (CONFIG_ARM64), \
 		 $(sort $(dir $(wildcard $(srctree)/dts/upstream/src/arm64/*/*))) \
 		 $(sort $(dir $(wildcard $(srctree)/dts/upstream/src/arm64/*/*/*)))))
+ext_dts_flags_extra = $(filter-out $(DTC_FLAGS),$(ext_dts_flags))
+ext_dts_shadow_include = $(if $(ext_dts_shadow),\
+	-I$(ext_dts_shadow)/$(dir $(patsubst $(obj)/%,%,$@)) \
+	-I$(ext_dts_shadow)/$(dir $(subst $(quote),,$(CONFIG_DEFAULT_DEVICE_TREE))))
+
 dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc                    \
 		 $(UBOOTINCLUDE)                                         \
 		 -I$(dir $<)                                             \
+		 $(ext_dts_shadow_include)                               \
 		 -I$(u_boot_dtsi_loc)                                     \
 		 -I$(srctree)/arch/$(ARCH)/dts/include                   \
 		 -I$(srctree)/include                                    \
@@ -443,7 +449,7 @@ cmd_dtc_diff = \
 		-i $(dir $<) $(DTC_FLAGS) $(dtn-tmp) || \
 		(echo "Check $(shell pwd)/$< for errors" && false); \
 	$(DTC) -s -O dts -o $@.full.dts -b 0 \
-		-i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) $(dtc-tmp) || \
+		-i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) $(ext_dts_flags_extra) $(dtc-tmp) || \
 		(echo "Check $(shell pwd)/$(pre-tmp) for errors" && false); \
 	sed -i '/\<phandle\> = <0x[0-9a-f]\+>;/ d' $@.clean.dts; \
 	sed -i '/\<phandle\> = <0x[0-9a-f]\+>;/ d' $@.full.dts; \
@@ -464,7 +470,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
 	  echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
 	$(HOSTCC) -E @$(dtc-flags-tmp) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \
 	$(DTC) -O dtb -o $@ -b 0 \
-		-i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \
+		-i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) $(ext_dts_flags_extra) \
 		-d $(depfile).dtc.tmp $(dtc-tmp) || \
 		(echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \
 		; \
-- 
2.43.0

Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[Marek Vasut]

On 11/8/26 4:50 PM, Vincent Jardin wrote:
> A board whose DTS is not in U-Boot does not have a clean way to build it.
> 
> Today the build systems copy the sources into the tree and follow its
> layout: Buildroot has copied BR2_TARGET_UBOOT_CUSTOM_DTS_PATH into
> arch/<arch>/dts since 2017 [1][2], and had to learn
> dts/upstream/src/<arch>/<vendor> for OF_UPSTREAM boards this September [3];
> Yocto layers copy their .dts into arch/<arch>/dts and sed a dtb-y line
> into its Makefile [4], copy their -u-boot.dtsi there [5], or tell the user
> to patch the dts into the U-Boot source [6].
> 
> This series adds a way to build it from a directory outside the tree:
> 
>      make EXT_DTS_DIR=/path/to/dts DEVICE_TREE=myboard
> 
> The benefits for the build systems:
> 
> - Buildroot: BR2_TARGET_UBOOT_CUSTOM_DTS_PATH could become a make option,
>    EXT_DTS_DIR=<dir> in UBOOT_MAKE_OPTS, for every U-Boot layout at once,
>    without the copy, the sed, or the question of where the -u-boot.dtsi
>    goes: next to the .dts. A U-Boot upgrade no longer moves the files.
> 
> - Yocto: a BSP layer adds EXTRA_OEMAKE += "EXT_DTS_DIR=${UNPACKDIR}/dts"
>    and keeps its device trees in the layer, versioned with the board, not
>    with the U-Boot recipe; a UBOOT_CONFIG with several configurations
>    passes its DEVICE_TREE per configuration as before.
> 
> - A bring-up, or a board whose device tree is maintained with the
>    kernel's, keeps one device tree repository for both; nothing is copied
>    into U-Boot until the board goes upstream.
> 
> Patch 1 makes "make DEVICE_TREE=<name>" build that device tree in the
> directories built through scripts/Makefile.dts, which listed Kconfig's
> only (the VisionFive 2 report [7]). Patch 2 looks for <name>-u-boot.dtsi
> next to the .dts before arch/<arch>/dts. Patch 3 adds EXT_DTS_DIR.
> 
> It was tested on main at 2515b39e3f1 using:
> 
> - imx8mp_evk (OF_UPSTREAM, SPL, binman): with its .dts copied out of the
>    tree, the external build gives dt.dtb, u-boot.dtb, u-boot.itb,
>    spl/u-boot-spl.bin and flash.bin identical to the in-tree build,
>    in the <vendor>/ layout. A *-u-boot.dtsi next to the source is taken
>    first. Touching the source rebuilds, nothing else does.
Upstream your hardware support and you won't need external DTs.

Also, regarding 3/3 , directories (not folders).

Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[Vincent Jardin]

Hi,

> Upstream your hardware support and you won't need external DTs.

Even upstream, how does it solve the Yocto's and Buildroot's related
issues ? Both did try to workaround despite they are all upstream.

thank you,
  Vincent

Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[Marek Vasut]

On 11/8/26 6:49 PM, Vincent Jardin wrote:
> Hi,
> 
>> Upstream your hardware support and you won't need external DTs.
> 
> Even upstream, how does it solve the Yocto's and Buildroot's related
> issues ? Both did try to workaround despite they are all upstream.
Could you apply a patch which contains the custom DT instead ?
(using SRC_URI:append = " file://0001-your-dt.patch" or similar)

What is the use case of custom DT injection like this ?

Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[Vincent Jardin]

Hi,

> > > Upstream your hardware support and you won't need external DTs.
> > 
> > Even upstream, how does it solve the Yocto's and Buildroot's related
> > issues ? Both did try to workaround despite they are all upstream.
> Could you apply a patch which contains the custom DT instead ?
> (using SRC_URI:append = " file://0001-your-dt.patch" or similar)

the patch has to be redone, again and again. That is what Buildroot went
through: see [1] or [3]

For Yocto see [4][5][6]

Both do hand copy ! config/git management is not convenient neither.

> 
> What is the use case of custom DT injection like this ?

For example,

 - Bring-up. The board needs U-Boot to boot before its device tree is
   anywhere near upstream, and the .dts changes several times a day.
   Pointing the build at the directory beats a patch per iteration !

 - Linux sync. A DT that is upstream in Linux but not yet in U-Boot.
   dts/upstream follows a kernel release, so a board whose .dts landed
   in the kernel waits for the next sync.

 - Board variants. A carrier or a memory variant of a supported board,
   like the VisionFive 2 8GiB report [7], needs its own DTB but is not
   something U-Boot wants a defconfig for. The variant .dts lives with
   the product and builds against the SoC .dtsi of the U-Boot release.

How to handle those cases + Buildroot and Yocto without such proposal
for uboot ?

best regards,
  Vincent

Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[Marek Vasut]

On 11/8/26 9:50 PM, Vincent Jardin wrote:

Hi,

>>>> Upstream your hardware support and you won't need external DTs.
>>>
>>> Even upstream, how does it solve the Yocto's and Buildroot's related
>>> issues ? Both did try to workaround despite they are all upstream.
>> Could you apply a patch which contains the custom DT instead ?
>> (using SRC_URI:append = " file://0001-your-dt.patch" or similar)
> 
> the patch has to be redone, again and again. That is what Buildroot went
> through: see [1] or [3]
> 
> For Yocto see [4][5][6]
> 
> Both do hand copy ! config/git management is not convenient neither.
> 
>>
>> What is the use case of custom DT injection like this ?
> 
> For example,
> 
>   - Bring-up. The board needs U-Boot to boot before its device tree is
>     anywhere near upstream, and the .dts changes several times a day.
>     Pointing the build at the directory beats a patch per iteration !

Why not compile U-Boot by hand outside of any build system during board 
bring up ? That is even more efficient .

>   - Linux sync. A DT that is upstream in Linux but not yet in U-Boot.
>     dts/upstream follows a kernel release, so a board whose .dts landed
>     in the kernel waits for the next sync.

You can still place such a DT in arch/*/dts and cherry-pick patches from 
Linux until the next round of dts/upstream sync.

>   - Board variants. A carrier or a memory variant of a supported board,
>     like the VisionFive 2 8GiB report [7], needs its own DTB but is not
>     something U-Boot wants a defconfig for. The variant .dts lives with
>     the product and builds against the SoC .dtsi of the U-Boot release.

Can the DRAM size be auto-detected by U-Boot based on e.g. some resistor 
straps ? If so, U-Boot also patches its own memory layout into the DT 
passed to Linux, so boards with DRAM size options can be handled by one 
DT. See dram_init_banksize().

> How to handle those cases + Buildroot and Yocto without such proposal
> for uboot ?
Please see above.

Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[E Shattow]

Hi Vincent,

On 11/8/26 12:50, Vincent Jardin wrote:
> Hi,
> 
>>>> Upstream your hardware support and you won't need external DTs.
>>>
>>> Even upstream, how does it solve the Yocto's and Buildroot's related
>>> issues ? Both did try to workaround despite they are all upstream.
>> Could you apply a patch which contains the custom DT instead ?
>> (using SRC_URI:append = " file://0001-your-dt.patch" or similar)
> 
> the patch has to be redone, again and again. That is what Buildroot went
> through: see [1] or [3]
> 
> For Yocto see [4][5][6]
> 
> Both do hand copy ! config/git management is not convenient neither.
> 
>>
>> What is the use case of custom DT injection like this ?
> 
> For example,
> 
>  - Bring-up. The board needs U-Boot to boot before its device tree is
>    anywhere near upstream, and the .dts changes several times a day.
>    Pointing the build at the directory beats a patch per iteration !
> 
>  - Linux sync. A DT that is upstream in Linux but not yet in U-Boot.
>    dts/upstream follows a kernel release, so a board whose .dts landed
>    in the kernel waits for the next sync.
> 
>  - Board variants. A carrier or a memory variant of a supported board,
>    like the VisionFive 2 8GiB report [7], needs its own DTB but is not
>    something U-Boot wants a defconfig for. The variant .dts lives with
>    the product and builds against the SoC .dtsi of the U-Boot release.
> 
> How to handle those cases + Buildroot and Yocto without such proposal
> for uboot ?
> 
> best regards,
>   Vincent

I've mentioned previously on list and in IRC discussion this topic of
dts source tree names being hard-coded. It would be very useful to have
LINUX_SOURCE_TREE=/path/to/source/tree/linux.git and a Kconfig option
activated to pass to the build for local development substituting
in-place of the 'dts' sub-tree. This is RFC do-not-merge territory and
to prevent abuse no patch users of code depending on this Kconfig option
should be accepted to merge.

I think that it is too fragile to make support for an external DTS tree
as a supported dependency of in-tree boards. There is a concern that
vendors would normalize this and make the situation even more
fragmented, contrary to the intent of having Linux as the device tree
upstream in-tree as a 'dts' sub-tree.

There are two overall topics here though:

1. Everywhere, all over, it is assumed "dts/upstream/src" literal is the
devicetree-rebasing tree location. The hard coded use of paths in U-Boot
build system is technical debt for when we would want to extend this
substituting an alternative location of the 'dts' git subtree.

2. devicetree-rebasing subtree does not share the same directory layout
structure as Linux kernel source tree, and the need for substituting
this with Linux source tree locally is not possible to provide for at
the moment;  temporary hacks to remove and replace the subtree directory
with symlink to local linux source tree are not sufficient due to the
differences in directory layout and missing or conflicting header files
referenced by dts and dtsi inputs.

The motivation to resolve [1] is moot if, as has been confirmed
previously, 'dts' directory name is the permanent location of
devicetree-rebasing sub tree in U-Boot source tree.

However, [2] depends on [1], and this touches a lot of code to abstract
the devicetree-rebasing subtree handling.

I'd like to see this realized but is it worth the effort?

-E

Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[Vincent Jardin]

Hi,

Le 08/11/26 16:58, E Shattow a écrit :
> Hi Vincent,
> 
> There is a concern that vendors would normalize this and make the
> situation even more fragmented, contrary to the intent of having
> Linux as the device tree upstream in-tree as a 'dts' sub-tree.

I do not want that neither: the DTS of a board SHALL be upstream
in Linux and in u-boot -> "upstream first"

What I (we, I feel I am not alone) want is only to smooth the local
bring-up, the months before the board is upstream, when the .dts
changes several times a day and the build is the Yocto or Buildroot
image of an internal team and its CI.

Compiling u-boot outside of any build system does not help there,
and the copies into arch/<arch>/dts that the layers do today [4][5][6]
are a fragmentation.

So the question could be how to make EXT_DTS_DIR usable for a bring-up and
useless as a permanent home.

For v2, I can explore more upstream "guards" for U-Boot like the one that
already applies to CONFIG_OF_EMBED, which "crept into use":

 - it stays a make variable, like EXT_DTB and DEVICE_TREE: no defconfig
   can set it, no board can depend on it

 - a stderr banner as CONFIG_OF_EMBED whenever it is set: the
   device tree comes from outside the tree, not for boards in mainline
   I mean, https://git.u-boot-project.org/u-boot/u-boot/-/blob/master/Makefile#L1404

 - maybe, an error when a name of the list also exists in dts/upstream or
   arch/<arch>/dts: the directory can add a device tree, never shadow an
   upstream one -> I do not like it because it avoids improving/preparing
   a new DTS before sending. Maybe having an experimental flag.

 - control.rst: a third option in the Configuration section, next to
   arch/<arch>/dts and update-subtree.sh pick, for a board that is not
   in the tree: a board sent upstream must come with its .dts

 - others ?

The SoC .dtsi are still taken from dts/upstream, only the board file
would come from outside, as it does with EXT_DTB today (that was the answer
for the VisionFive 2 question last April [7], with a precompiled blob
because DEVICE_TREE= cannot build a file outside the tree).

best regards,
  Vincent

Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

On Mon, Nov 09, 2026 at 06:21:32PM +0100, Vincent Jardin wrote:
> Hi,
> 
> Le 08/11/26 16:58, E Shattow a écrit :
> > Hi Vincent,
> > 
> > There is a concern that vendors would normalize this and make the
> > situation even more fragmented, contrary to the intent of having
> > Linux as the device tree upstream in-tree as a 'dts' sub-tree.
> 
> I do not want that neither: the DTS of a board SHALL be upstream
> in Linux and in u-boot -> "upstream first"
> 
> What I (we, I feel I am not alone) want is only to smooth the local
> bring-up, the months before the board is upstream, when the .dts
> changes several times a day and the build is the Yocto or Buildroot
> image of an internal team and its CI.
> 
> Compiling u-boot outside of any build system does not help there,
> and the copies into arch/<arch>/dts that the layers do today [4][5][6]
> are a fragmentation.
> 
> So the question could be how to make EXT_DTS_DIR usable for a bring-up and
> useless as a permanent home.
> 
> For v2, I can explore more upstream "guards" for U-Boot like the one that
> already applies to CONFIG_OF_EMBED, which "crept into use":
> 
>  - it stays a make variable, like EXT_DTB and DEVICE_TREE: no defconfig
>    can set it, no board can depend on it
> 
>  - a stderr banner as CONFIG_OF_EMBED whenever it is set: the
>    device tree comes from outside the tree, not for boards in mainline
>    I mean, https://git.u-boot-project.org/u-boot/u-boot/-/blob/master/Makefile#L1404
> 
>  - maybe, an error when a name of the list also exists in dts/upstream or
>    arch/<arch>/dts: the directory can add a device tree, never shadow an
>    upstream one -> I do not like it because it avoids improving/preparing
>    a new DTS before sending. Maybe having an experimental flag.
> 
>  - control.rst: a third option in the Configuration section, next to
>    arch/<arch>/dts and update-subtree.sh pick, for a board that is not
>    in the tree: a board sent upstream must come with its .dts
> 
>  - others ?
> 
> The SoC .dtsi are still taken from dts/upstream, only the board file
> would come from outside, as it does with EXT_DTB today (that was the answer
> for the VisionFive 2 question last April [7], with a precompiled blob
> because DEVICE_TREE= cannot build a file outside the tree).

It's a fine line to walk. Vendors who are trying to do the right thing
should be encouraged and so not walk in to "walls" that block progress.
Vendors that don't care about doing the right thing will just patch over
whatever check we add. Probably that first option is enough, it can be
set in metadata that builds U-Boot as needed.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[Vincent Jardin]

Le 09/11/26 20:13, Tom Rini a écrit :
> It's a fine line to walk. Vendors who are trying to do the right thing
> should be encouraged and so not walk in to "walls" that block progress.
> Vendors that don't care about doing the right thing will just patch over
> whatever check we add. Probably that first option is enough, it can be
> set in metadata that builds U-Boot as needed.

big thanks.

I did post a v2 with some cosmetics: control.rst
It states the option for a board that is not in the tree yet, and states that a
board sent upstream shall still come with its devicetree source:

  https://lore.kernel.org/u-boot/20261110075256.1800130-1-vjardin@free.fr/

best regards,
  Vincent