[PATCH v3 0/8] An effort to bring DT bindings compliance within U-Boot
Changes in v3: -------------- - Patch #4: Minor commit message update - Patch #5: Replace CONFIG_* with Kconfig options - Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead. - Patch #1, #3, #6 and #8: Picked up review tags
Changes in v2: -------------- - Patch #1: excluded gitab CI config check and added commit description. - Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/ - Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ - Patch #5: s/U-boot/U-Boot/ - Patch #6 and #7: Picked up review tags
Prerequisite ------------
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-Boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
Background ----------
This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-Boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained.
However, Linux kernel DT maintainers proposed [2] for U-Boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel.
In order to maintain devicetree files sync, U-Boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows:
$ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash
The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-Boot maintainers here [4]. Now we would like to reach out to wider U-Boot community to seek feedback.
[1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+... [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9j... [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... [4] https://github.com/u-boot/u-boot/pull/451
Changes -------
Traditionally, U-Boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via:
CONFIG_DEFAULT_DEVICE_TREE "<name>"
SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via:
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8.
Devicetree bindings schema checks ---------------------------------
With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-Boot to run devicetree bindings schema checks which will bring compliance to U-Boot core/drivers regarding usage of devicetree.
Dependencies ------------
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:
$ pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems:
$ apt install swig python3-dev
Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default).
Recommended is also to install yamllint (used by dtschema when present).
Running checks --------------
In order to perform validation of DTB files, use the ``dtbs_check`` target:
$ make dtbs_check
It is also possible to run checks with a subset of matching schema files by setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or patterns (partial match of a fixed string). Each file or pattern should be separated by ':'.
$ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml $ make dtbs_check DT_SCHEMA_FILES=/gpio/ $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml
Sumit Garg (8): CI: Exclude devicetree-rebasing subtree for CONFIG checks Makefile: Add support for DT bindings schema checks scripts/Makefile.lib: Statically define *-u-boot.dtsi files location dts: Add alternative location for upstream DTB builds doc: devicetree: Updates for devicetree-rebasing subtree MAINTAINERS: Add myself as devicetree-rebasing maintainer dts: meson-gxbb: Switch to using upstream DT dts: meson-gxbb: Drop redundant devicetree files
.azure-pipelines.yml | 3 +- .gitlab-ci.yml | 3 +- MAINTAINERS | 6 + Makefile | 20 +- arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 415 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 418 ------------ arch/arm/dts/meson-gxbb-p200.dts | 100 --- arch/arm/dts/meson-gxbb-p201.dts | 26 - arch/arm/dts/meson-gxbb-p20x.dtsi | 250 ------- arch/arm/dts/meson-gxbb-wetek-hub.dts | 58 -- arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 ---- arch/arm/dts/meson-gxbb-wetek.dtsi | 292 -------- arch/arm/dts/meson-gxbb.dtsi | 856 ------------------------ arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- doc/develop/devicetree/control.rst | 131 +++- dts/Kconfig | 11 + dts/Makefile | 17 +- dts/arch/arm64/Makefile | 14 + dts/arch/arm64/amlogic | 1 + scripts/Makefile.lib | 42 +- 29 files changed, 201 insertions(+), 2744 deletions(-) delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi delete mode 100644 arch/arm/dts/meson-gxbb.dtsi create mode 100644 dts/arch/arm64/Makefile create mode 120000 dts/arch/arm64/amlogic
Since devicetree-rebasing is an external repo with its own coding style, exclude it from Azure and gitlab CI CONFIG checks.
Reviewed-by: Tom Rini trini@konsulko.com Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v3: -------------- - Picked up review tag
Changes in v2: -------------- - Excluded gitab CI config check and added commit description.
.azure-pipelines.yml | 3 ++- .gitlab-ci.yml | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index d6f3fa423c6..f100c4493e6 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -65,7 +65,8 @@ stages: # have no matches. - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h - :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0 + :^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ && + exit 1 || exit 0
- job: docs displayName: 'Build documentation' diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index fee165198ae..96ca9f72bbc 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -161,7 +161,8 @@ check for new CONFIG symbols outside Kconfig: # have no matches. - git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h - :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0 + :^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ && + exit 1 || exit 0
# build documentation docs:
On Thu, 28 Dec 2023 at 13:58, Sumit Garg sumit.garg@linaro.org wrote:
Since devicetree-rebasing is an external repo with its own coding style, exclude it from Azure and gitlab CI CONFIG checks.
Reviewed-by: Tom Rini trini@konsulko.com Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Picked up review tag
Changes in v2:
- Excluded gitab CI config check and added commit description.
.azure-pipelines.yml | 3 ++- .gitlab-ci.yml | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index d6f3fa423c6..f100c4493e6 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -65,7 +65,8 @@ stages: # have no matches. - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
:^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
:^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&exit 1 || exit 0
- job: docs displayName: 'Build documentation'
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index fee165198ae..96ca9f72bbc 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -161,7 +161,8 @@ check for new CONFIG symbols outside Kconfig: # have no matches. - git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
:^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
:^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&exit 1 || exit 0# build documentation docs: -- 2.34.1
Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org
On Thu, Dec 28, 2023 at 12:03 PM Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 28 Dec 2023 at 13:58, Sumit Garg sumit.garg@linaro.org wrote:
Since devicetree-rebasing is an external repo with its own coding style, exclude it from Azure and gitlab CI CONFIG checks.
Reviewed-by: Tom Rini trini@konsulko.com Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Picked up review tag
Changes in v2:
- Excluded gitab CI config check and added commit description.
.azure-pipelines.yml | 3 ++- .gitlab-ci.yml | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
This adds the build infrastructure for checking DT binding schema documents and validating dtb files using the binding schema. Here we use devicetree-rebasing directory to provide the DT bindings.
Dependency: -----------
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip::
pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems::
apt install swig python3-dev
Testing: --------
Build dts files and check using DT binding schema: $ make dtbs_check
Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to use for validation. This makes it easier to find and fix errors generated by a specific schema.
Note, at this point dtbs_check is an optional build target as there are many warnings generated due to custom DT properties used by many platforms in u-boot. It is expected with these checks that compliance with DT bindings to take place. Once that's done it can be added to CI builds to remain compliant with DT bindings.
Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v3: -------------- - None
Changes in v2: -------------- - None
Makefile | 20 ++++++++++++++++++-- scripts/Makefile.lib | 17 +++++++++++++++-- 2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile index 750bbdb1b71..d8d168cd4c3 100644 --- a/Makefile +++ b/Makefile @@ -1158,12 +1158,28 @@ endif @# disabling OF_BOARD. $(call cmd,ofcheck,$(KCONFIG_CONFIG))
-PHONY += dtbs +PHONY += dtbs dtbs_check dtbs: dts/dt.dtb @: -dts/dt.dtb: u-boot +dts/dt.dtb: dtbs_prepare u-boot $(Q)$(MAKE) $(build)=dts dtbs
+dtbs_prepare: prepare3 + +ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),) +export CHECK_DTBS=y +endif + +ifneq ($(CHECK_DTBS),) +dtbs_prepare: dt_binding_check +endif + +dtbs_check: dt_binding_check dtbs + +DT_BINDING_DIR := devicetree-rebasing/Bindings +dt_binding_check: scripts_dtc + $(Q)$(MAKE) $(build)=$(DT_BINDING_DIR) $(DT_BINDING_DIR)/processed-schema.json + quiet_cmd_copy = COPY $@ cmd_copy = cp $< $@
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 16bbc277a9f..27b9437027c 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -356,8 +356,21 @@ endif
dtsi_include_list_deps = $(addprefix $(obj)/,$(subst $(quote),,$(dtsi_include_list)))
-$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE - $(call if_changed_dep,dtc) +ifneq ($(CHECK_DTBS),) +DT_CHECKER ?= dt-validate +DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m) +DT_BINDING_DIR := devicetree-rebasing/Bindings +DT_TMP_SCHEMA := $(objtree)/$(DT_BINDING_DIR)/processed-schema.json + +quiet_cmd_dtb = DTC_CHK $@ + cmd_dtb = $(cmd_dtc) ; $(DT_CHECKER) $(DT_CHECKER_FLAGS) -u $(srctree)/$(DT_BINDING_DIR) -p $(DT_TMP_SCHEMA) $@ || true +else +quiet_cmd_dtb = $(quiet_cmd_dtc) + cmd_dtb = $(cmd_dtc) +endif + +$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) $(DT_TMP_SCHEMA) FORCE + $(call if_changed_dep,dtb)
pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp) dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
This adds the build infrastructure for checking DT binding schema documents and validating dtb files using the binding schema. Here we use devicetree-rebasing directory to provide the DT bindings.
Dependency:
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip::
pip3 install dtschemaNote that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems::
apt install swig python3-devTesting:
Build dts files and check using DT binding schema: $ make dtbs_check
Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to use for validation. This makes it easier to find and fix errors generated by a specific schema.
Note, at this point dtbs_check is an optional build target as there are many warnings generated due to custom DT properties used by many platforms in u-boot. It is expected with these checks that compliance with DT bindings to take place. Once that's done it can be added to CI builds to remain compliant with DT bindings.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- None
Changes in v2:
- None
Makefile | 20 ++++++++++++++++++-- scripts/Makefile.lib | 17 +++++++++++++++-- 2 files changed, 33 insertions(+), 4 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org Tested-by: Simon Glass sjg@chromium.org
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v3: -------------- - Picked up review tags
Changes in v2: -------------- - s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/
scripts/Makefile.lib | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..09330421856 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -159,18 +159,20 @@ cpp_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE) \ 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_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \ - $(wildcard $(dir $<)$(subst $",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \ - $(wildcard $(dir $<)$(subst $",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \ - $(wildcard $(dir $<)$(subst $",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \ - $(wildcard $(dir $<)u-boot.dtsi)) +u_boot_dtsi_loc = $(srctree)/arch/$(ARCH)/dts/ + +u_boot_dtsi_options = $(strip $(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 \ - $(dir $<)$(subst $",,$(CONFIG_SYS_SOC))-u-boot.dtsi \ - $(dir $<)$(subst $",,$(CONFIG_SYS_CPU))-u-boot.dtsi \ - $(dir $<)$(subst $",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \ - $(dir $<)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 \ + $(u_boot_dtsi_loc)$(subst $",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \ + $(u_boot_dtsi_loc)u-boot.dtsi ... \ found: $(if $(u_boot_dtsi_options),"$(u_boot_dtsi_options)",nothing!))
# Uncomment for debugging @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \ + -I$(u_boot_dtsi_loc) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ -D__ASSEMBLY__ \ @@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \ - -i $(dir $<) $(DTC_FLAGS) \ + -i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) || \ (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \ ; \
Hi Sumit!
On December 28, 2023 thus sayeth Sumit Garg:
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
...
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..09330421856 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib
...
# Uncomment for debugging @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \
-I$(u_boot_dtsi_loc) \@@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \
One of the issues I see with having a separate OF_UPSTREAM and U-Boot dt directory is when we have U-Boot board files that use dtsi files in the OF_UPSTREAM folder.
For example our reference boards uses the primary bootloader's dtb (eg: k3-am62a7-r5-sk.dts) which #includes the k3-am62a7-sk.dts that will be found in the OF_UPSTREAM directory and modifies it to give it the perspective of the micro-controller it will be running on during boot.
What do you think if we have both paths included regardless if OF_UPSTREAM is selected or not? IDK if this will break anyone else
~Bryan
Hi Bryan,
On Sat, 6 Jan 2024 at 02:12, Bryan Brattlof bb@ti.com wrote:
Hi Sumit!
On December 28, 2023 thus sayeth Sumit Garg:
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
...
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..09330421856 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib
...
# Uncomment for debugging @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \
-I$(u_boot_dtsi_loc) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ -D__ASSEMBLY__ \@@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) || \ (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \ ; \One of the issues I see with having a separate OF_UPSTREAM and U-Boot dt directory is when we have U-Boot board files that use dtsi files in the OF_UPSTREAM folder.
For example our reference boards uses the primary bootloader's dtb (eg: k3-am62a7-r5-sk.dts) which #includes the k3-am62a7-sk.dts that will be found in the OF_UPSTREAM directory and modifies it to give it the perspective of the micro-controller it will be running on during boot.
Thanks for bringing this up. I have been playing with the idea to reuse DT includes from upstream.
What do you think if we have both paths included regardless if OF_UPSTREAM is selected or not? IDK if this will break anyone else
Sure, we should be able to do that if we maintain the correct order of include paths as per following patch [1]. If this works for you let me know and I will include it for v4.
[1]
commit 7fcebc044c69c57b43ff0e59f2d8c3713bc68b6c Author: Sumit Garg sumit.garg@linaro.org Date: Tue Jan 2 19:20:01 2024 +0530
Makefile: Allow upstream DT subtree to provide DT includes
Allow platforms to reuse DT headers and dtsi includes directly form upstream DT subtree which will be frequently synced with Linux kernel. This will further allow us to drop corresponding DT includes copy from U-Boot tree.
Also, since the DT includes from upstream DT subtree are done after DT includes from U-Boot tree, so it shouldn't cause any conflicts.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
diff --git a/Makefile b/Makefile index d8d168cd4c3..0160e827a29 100644 --- a/Makefile +++ b/Makefile @@ -834,7 +834,8 @@ UBOOTINCLUDE := \ -I$(srctree)/arch/arm/thumb1/include), \ -I$(srctree)/arch/arm/thumb1/include)) \ -I$(srctree)/arch/$(ARCH)/include \ - -include $(srctree)/include/linux/kconfig.h + -include $(srctree)/include/linux/kconfig.h \ + -I$(srctree)/devicetree-rebasing/include
NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 09330421856..30033092597 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -189,12 +189,17 @@ dtsi_include_list = $(strip $(u_boot_dtsi_options_debug) \ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES)
# Modified for U-Boot +upstream_dtsi_include = $(addprefix -I, $(srctree)/devicetree-rebasing/src/ \ + $(sort $(dir $(wildcard $(srctree)/devicetree-rebasing/src/$(ARCH)/*/*))) \ + $(if (CONFIG_ARM64), \ + $(sort $(dir $(wildcard $(srctree)/devicetree-rebasing/src/arm64/*/*))))) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \ -I$(u_boot_dtsi_loc) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ + $(upstream_dtsi_include) \ -D__ASSEMBLY__ \ -undef -D__DTS__
-Sumit
On January 8, 2024 thus sayeth Sumit Garg:
Hi Bryan,
On Sat, 6 Jan 2024 at 02:12, Bryan Brattlof bb@ti.com wrote:
Hi Sumit!
On December 28, 2023 thus sayeth Sumit Garg:
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
...
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..09330421856 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib
...
# Uncomment for debugging @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \
-I$(u_boot_dtsi_loc) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ -D__ASSEMBLY__ \@@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) || \ (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \ ; \One of the issues I see with having a separate OF_UPSTREAM and U-Boot dt directory is when we have U-Boot board files that use dtsi files in the OF_UPSTREAM folder.
For example our reference boards uses the primary bootloader's dtb (eg: k3-am62a7-r5-sk.dts) which #includes the k3-am62a7-sk.dts that will be found in the OF_UPSTREAM directory and modifies it to give it the perspective of the micro-controller it will be running on during boot.
Thanks for bringing this up. I have been playing with the idea to reuse DT includes from upstream.
What do you think if we have both paths included regardless if OF_UPSTREAM is selected or not? IDK if this will break anyone else
Sure, we should be able to do that if we maintain the correct order of include paths as per following patch [1]. If this works for you let me know and I will include it for v4.
This works beautifully.
I did have to hack around to get Makefile.spl working but this is headed in the right direction for me :)
Thank you ~Bryan
On Tue, 9 Jan 2024 at 07:24, Bryan Brattlof bb@ti.com wrote:
On January 8, 2024 thus sayeth Sumit Garg:
Hi Bryan,
On Sat, 6 Jan 2024 at 02:12, Bryan Brattlof bb@ti.com wrote:
Hi Sumit!
On December 28, 2023 thus sayeth Sumit Garg:
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
...
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..09330421856 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib
...
# Uncomment for debugging @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \
-I$(u_boot_dtsi_loc) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ -D__ASSEMBLY__ \@@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) || \ (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \ ; \One of the issues I see with having a separate OF_UPSTREAM and U-Boot dt directory is when we have U-Boot board files that use dtsi files in the OF_UPSTREAM folder.
For example our reference boards uses the primary bootloader's dtb (eg: k3-am62a7-r5-sk.dts) which #includes the k3-am62a7-sk.dts that will be found in the OF_UPSTREAM directory and modifies it to give it the perspective of the micro-controller it will be running on during boot.
Thanks for bringing this up. I have been playing with the idea to reuse DT includes from upstream.
What do you think if we have both paths included regardless if OF_UPSTREAM is selected or not? IDK if this will break anyone else
Sure, we should be able to do that if we maintain the correct order of include paths as per following patch [1]. If this works for you let me know and I will include it for v4.
This works beautifully.
I did have to hack around to get Makefile.spl working but this is headed in the right direction for me :)
Thanks for testing. I hope I can take that as a tested-by tag for this patch.
-Sumit
Thank you ~Bryan
On January 9, 2024 thus sayeth Sumit Garg:
On Tue, 9 Jan 2024 at 07:24, Bryan Brattlof bb@ti.com wrote:
On January 8, 2024 thus sayeth Sumit Garg:
Hi Bryan,
On Sat, 6 Jan 2024 at 02:12, Bryan Brattlof bb@ti.com wrote:
Hi Sumit!
On December 28, 2023 thus sayeth Sumit Garg:
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
...
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..09330421856 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib
...
# Uncomment for debugging @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \
-I$(u_boot_dtsi_loc) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ -D__ASSEMBLY__ \@@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) || \ (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \ ; \One of the issues I see with having a separate OF_UPSTREAM and U-Boot dt directory is when we have U-Boot board files that use dtsi files in the OF_UPSTREAM folder.
For example our reference boards uses the primary bootloader's dtb (eg: k3-am62a7-r5-sk.dts) which #includes the k3-am62a7-sk.dts that will be found in the OF_UPSTREAM directory and modifies it to give it the perspective of the micro-controller it will be running on during boot.
Thanks for bringing this up. I have been playing with the idea to reuse DT includes from upstream.
What do you think if we have both paths included regardless if OF_UPSTREAM is selected or not? IDK if this will break anyone else
Sure, we should be able to do that if we maintain the correct order of include paths as per following patch [1]. If this works for you let me know and I will include it for v4.
This works beautifully.
I did have to hack around to get Makefile.spl working but this is headed in the right direction for me :)
Thanks for testing. I hope I can take that as a tested-by tag for this patch.
Absolutely
Tested-by: Bryan Brattlof bb@ti.com
~Bryan
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v3: -------------- - Minor commit message update
Changes in v2: -------------- - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM + bool "Enable use of devicetree imported from Linux kernel release" + help + Traditionally, U-Boot platforms used to have their custom devicetree + files or copy devicetree files from Linux kernel which are hard to + maintain and can usually get out-of-sync from Linux kernel. This + option enables platforms to migrate to devicetree-rebasing repo where + a regular sync will be maintained every major Linux kernel release + cycle. However, platforms can still have some custom u-boot specific + bits maintained as part of *-u-boot.dtsi files. + choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..68daaf45ec7 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),) DEVICE_TREE := unset endif
+ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +dt_dir := dts/arch/arm64 +else +dt_dir := dts/arch/$(ARCH) +endif +else +dt_dir := arch/$(ARCH)/dts +endif + ifneq ($(EXT_DTB),) DTB := $(EXT_DTB) else -DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb +DTB := $(dt_dir)/$(DEVICE_TREE).dtb endif
$(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE @@ -41,7 +51,7 @@ $(DTB): arch-dtbs
PHONY += arch-dtbs arch-dtbs: - $(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs + $(Q)$(MAKE) $(build)=$(dt_dir) dtbs
ifeq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o @@ -65,4 +75,5 @@ clean-files := dt.dtb.S # Let clean descend into dts directories subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts \ ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts \ - ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts + ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts \ + ./arch/arm64 ./arch/$(ARCH) diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile new file mode 100644 index 00000000000..16e9fea622d --- /dev/null +++ b/dts/arch/arm64/Makefile @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0+ + +include $(srctree)/scripts/Makefile.dts + +targets += $(dtb-y) + +# Add any required device tree compiler flags here +DTC_FLAGS += -a 0x8 + +PHONY += dtbs +dtbs: $(addprefix $(obj)/, $(dtb-y)) + @: + +clean-files := */*.dtb */*.dtbo */*_HS
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Minor commit message update
Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-Boot platforms used to have their custom devicetreefiles or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.
My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel release
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..68daaf45ec7 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),) DEVICE_TREE := unset endif
+ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +dt_dir := dts/arch/arm64 +else +dt_dir := dts/arch/$(ARCH) +endif +else +dt_dir := arch/$(ARCH)/dts +endif
ifneq ($(EXT_DTB),) DTB := $(EXT_DTB) else -DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb +DTB := $(dt_dir)/$(DEVICE_TREE).dtb endif
$(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE @@ -41,7 +51,7 @@ $(DTB): arch-dtbs
PHONY += arch-dtbs arch-dtbs:
$(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs
$(Q)$(MAKE) $(build)=$(dt_dir) dtbsifeq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o @@ -65,4 +75,5 @@ clean-files := dt.dtb.S # Let clean descend into dts directories subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts \ ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts \
../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts
../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts \./arch/arm64 ./arch/$(ARCH)diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile new file mode 100644 index 00000000000..16e9fea622d --- /dev/null +++ b/dts/arch/arm64/Makefile @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/scripts/Makefile.dts
+targets += $(dtb-y)
+# Add any required device tree compiler flags here +DTC_FLAGS += -a 0x8
+PHONY += dtbs +dtbs: $(addprefix $(obj)/, $(dtb-y))
@:+clean-files := */*.dtb */*.dtbo */*_HS
What is _HS for?
-- 2.34.1
Regards, Simon
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Minor commit message update
Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-Boot platforms used to have their custom devicetreefiles or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel release
I think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile new file mode 100644 index 00000000000..16e9fea622d --- /dev/null +++ b/dts/arch/arm64/Makefile @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/scripts/Makefile.dts
+targets += $(dtb-y)
+# Add any required device tree compiler flags here +DTC_FLAGS += -a 0x8
+PHONY += dtbs +dtbs: $(addprefix $(obj)/, $(dtb-y))
@:+clean-files := */*.dtb */*.dtbo */*_HS
What is _HS for?
Should we even need the clean-files part here? I think this is fixed with: https://patchwork.ozlabs.org/project/uboot/patch/20231226154619.5071-9-maxim...
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Minor commit message update
Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-Boot platforms used to have their custom devicetreefiles or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel releaseI think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
Using odroid-c2 with -next I see:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb meson-sm1-bananapi-m2-pro.dtb meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb meson-sm1-bananapi-m5.dtb meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb meson-sm1-khadas-vim3l.dtb meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb meson-sm1-odroid-c4.dtb meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb meson-sm1-odroid-hc4.dtb meson-g12b-odroid-go-ultra.dtb meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb $ With this series (sort of, since I am really not sure how to cherry-pick the commits from the PR) I see nothing:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ $
This shows some of the files:
$ find /tmp/b/odroid-c2/ -name "*.dtb" /tmp/b/odroid-c2/dts/dt.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb /tmp/b/odroid-c2/u-boot.dtb
but where are the rest? Also, is it possible to put the output .dtb files into the same directory? Otherwise we may have some pain with binman.
[..]
Regards, Simon
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Minor commit message update
Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-Boot platforms used to have their custom devicetreefiles or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel releaseI think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
Using odroid-c2 with -next I see:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb meson-sm1-bananapi-m2-pro.dtb meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb meson-sm1-bananapi-m5.dtb meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb meson-sm1-khadas-vim3l.dtb meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb meson-sm1-odroid-c4.dtb meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb meson-sm1-odroid-hc4.dtb meson-g12b-odroid-go-ultra.dtb meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb $ With this series (sort of, since I am really not sure how to cherry-pick the commits from the PR) I see nothing:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ $
This shows some of the files:
$ find /tmp/b/odroid-c2/ -name "*.dtb" /tmp/b/odroid-c2/dts/dt.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb /tmp/b/odroid-c2/u-boot.dtb
but where are the rest? Also, is it possible to put the output .dtb files into the same directory? Otherwise we may have some pain with binman.
What do you mean by same directory? But maybe also, what's an example of a board you think might end up having problems? Converting that in a follow-up series is likely a good idea, to highlight and address these issues sooner rather than later.
Hi Tom,
On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Minor commit message update
Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-Boot platforms used to have their custom devicetreefiles or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel releaseI think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
Using odroid-c2 with -next I see:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb meson-sm1-bananapi-m2-pro.dtb meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb meson-sm1-bananapi-m5.dtb meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb meson-sm1-khadas-vim3l.dtb meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb meson-sm1-odroid-c4.dtb meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb meson-sm1-odroid-hc4.dtb meson-g12b-odroid-go-ultra.dtb meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb $ With this series (sort of, since I am really not sure how to cherry-pick the commits from the PR) I see nothing:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ $
This shows some of the files:
$ find /tmp/b/odroid-c2/ -name "*.dtb" /tmp/b/odroid-c2/dts/dt.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb /tmp/b/odroid-c2/u-boot.dtb
but where are the rest? Also, is it possible to put the output .dtb files into the same directory? Otherwise we may have some pain with binman.
What do you mean by same directory? But maybe also, what's an example of a board you think might end up having problems? Converting that in a follow-up series is likely a good idea, to highlight and address these issues sooner rather than later.#
Today the .dtb files go into arch/arm/dts - so it would be easier if this series could do the same.
The problem I have described above applied to meson, so I believe it is clear enough with that. I wasn't able to get rk3399 going, but I am sure it would have the same problem.
The fundamental question is (I believe) whether to:
1. Build only a single DT for a board 2. Build all DTs for the SoC the board uses
This series seems to head towards (1), which worries me. We are currently mostly at (2).
Regards, Simon
On Thu, Dec 28, 2023 at 07:48:06PM +0000, Simon Glass wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Minor commit message update
Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-Boot platforms used to have their custom devicetreefiles or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel releaseI think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
Using odroid-c2 with -next I see:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb meson-sm1-bananapi-m2-pro.dtb meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb meson-sm1-bananapi-m5.dtb meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb meson-sm1-khadas-vim3l.dtb meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb meson-sm1-odroid-c4.dtb meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb meson-sm1-odroid-hc4.dtb meson-g12b-odroid-go-ultra.dtb meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb $ With this series (sort of, since I am really not sure how to cherry-pick the commits from the PR) I see nothing:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ $
This shows some of the files:
$ find /tmp/b/odroid-c2/ -name "*.dtb" /tmp/b/odroid-c2/dts/dt.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb /tmp/b/odroid-c2/u-boot.dtb
but where are the rest? Also, is it possible to put the output .dtb files into the same directory? Otherwise we may have some pain with binman.
What do you mean by same directory? But maybe also, what's an example of a board you think might end up having problems? Converting that in a follow-up series is likely a good idea, to highlight and address these issues sooner rather than later.#
Today the .dtb files go into arch/arm/dts - so it would be easier if this series could do the same.
But that's just an artifact of not having vendor directories. I don't really think we can sanely put the new object files in there, that's not what anyone is going to expect.
The problem I have described above applied to meson, so I believe it is clear enough with that. I wasn't able to get rk3399 going, but I am sure it would have the same problem.
I don't think meson has the problem I was asking about, which is what problem binman will have, because the series to make binman replace the vendor tools didn't complete? That's what I'm getting at, for which platform is binman going to have a problem today, so that we can look at what to do about it and evaluate solutions with an example in hand.
The fundamental question is (I believe) whether to:
- Build only a single DT for a board
- Build all DTs for the SoC the board uses
This series seems to head towards (1), which worries me. We are currently mostly at (2).
It's explicitly at (1) with the notion we'll deal with (2) down the road once there's a use case for it. Possibly once someone updates exynos platforms, based on what you had said previously?
On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Minor commit message update
Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-Boot platforms used to have their custom devicetreefiles or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel releaseI think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
Using odroid-c2 with -next I see:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb meson-sm1-bananapi-m2-pro.dtb meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb meson-sm1-bananapi-m5.dtb meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb meson-sm1-khadas-vim3l.dtb meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb meson-sm1-odroid-c4.dtb meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb meson-sm1-odroid-hc4.dtb meson-g12b-odroid-go-ultra.dtb meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb $ With this series (sort of, since I am really not sure how to cherry-pick the commits from the PR) I see nothing:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ $
This shows some of the files:
$ find /tmp/b/odroid-c2/ -name "*.dtb" /tmp/b/odroid-c2/dts/dt.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb /tmp/b/odroid-c2/u-boot.dtb
but where are the rest? Also, is it possible to put the output .dtb files into the same directory? Otherwise we may have some pain with binman.
What do you mean by same directory? But maybe also, what's an example of a board you think might end up having problems? Converting that in a follow-up series is likely a good idea, to highlight and address these issues sooner rather than later.#
Today the .dtb files go into arch/arm/dts - so it would be easier if this series could do the same.
The kbuild infrastructure keeps the dtb alongside dts files which is the preferred way too as otherwise it would be complicated to locate DT files for the users. Also, we have to move towards Linux DT directory structure and thereby the tools like binman have to be adjusted. I will do that when I get to migrating SoCs supporting binman.
The problem I have described above applied to meson, so I believe it is clear enough with that. I wasn't able to get rk3399 going, but I am sure it would have the same problem.
The fundamental question is (I believe) whether to:
- Build only a single DT for a board
- Build all DTs for the SoC the board uses
This series seems to head towards (1),
v2 of this series had the Makefile rules [1] for meson gxbb SoC but..
[1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-su...
which worries me. We are currently mostly at (2).
..after discussion with Tom, the Makefile rules are already coming via Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having redundant rules in Makefile doesn't add any value, so I took them off in v3.
However, I am very much in favour of having a generalized U-Boot image. This might become true in some cases like U-Boot acts as a second stage bootloader for a particular SoC which is a unified image where the prior stage passes the DT to it. The Qcom effort in this direction can be an example here. I am not sure at this point how we can enable different U-Boot features since there are many board specific bits needed currently not covered by DT.
The other common method is to embed board DT in U-Boot image especially where U-Boot acts as a first stage bootloader. Once that's done I don't see how we can call that a generic U-Boot image.
BTW, as Tom said we can very well add those Makefile rules later on a use case basis if a particular SoC requires a truly generic U-Boot image and the rules don't come via Kconfig options.
-Sumit
Regards, Simon
Hi Sumit,
On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote:
On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > Allow platform owners to mirror devicetree files from devitree-rebasing > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > directory. Also add a new Makefile for arm64. > > This will help easy migration for platforms which currently are compliant > with upstream Linux kernel devicetree files. > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > --- > > Changes in v3: > -------------- > - Minor commit message update > > Changes in v2: > -------------- > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > dts/Kconfig | 11 +++++++++++ > dts/Makefile | 17 ++++++++++++++--- > dts/arch/arm64/Makefile | 14 ++++++++++++++ > 3 files changed, 39 insertions(+), 3 deletions(-) > create mode 100644 dts/arch/arm64/Makefile > > diff --git a/dts/Kconfig b/dts/Kconfig > index 00c0aeff893..e58c1c6f2ab 100644 > --- a/dts/Kconfig > +++ b/dts/Kconfig > @@ -85,6 +85,17 @@ config OF_LIVE > enables a live tree which is available after relocation, > and can be adjusted as needed. > > +config OF_UPSTREAM > + bool "Enable use of devicetree imported from Linux kernel release" > + help > + Traditionally, U-Boot platforms used to have their custom devicetree > + files or copy devicetree files from Linux kernel which are hard to > + maintain and can usually get out-of-sync from Linux kernel. This > + option enables platforms to migrate to devicetree-rebasing repo where > + a regular sync will be maintained every major Linux kernel release > + cycle. However, platforms can still have some custom u-boot specific > + bits maintained as part of *-u-boot.dtsi files.
My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel releaseI think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
Using odroid-c2 with -next I see:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb meson-sm1-bananapi-m2-pro.dtb meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb meson-sm1-bananapi-m5.dtb meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb meson-sm1-khadas-vim3l.dtb meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb meson-sm1-odroid-c4.dtb meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb meson-sm1-odroid-hc4.dtb meson-g12b-odroid-go-ultra.dtb meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb $ With this series (sort of, since I am really not sure how to cherry-pick the commits from the PR) I see nothing:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ $
This shows some of the files:
$ find /tmp/b/odroid-c2/ -name "*.dtb" /tmp/b/odroid-c2/dts/dt.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb /tmp/b/odroid-c2/u-boot.dtb
but where are the rest? Also, is it possible to put the output .dtb files into the same directory? Otherwise we may have some pain with binman.
What do you mean by same directory? But maybe also, what's an example of a board you think might end up having problems? Converting that in a follow-up series is likely a good idea, to highlight and address these issues sooner rather than later.#
Today the .dtb files go into arch/arm/dts - so it would be easier if this series could do the same.
The kbuild infrastructure keeps the dtb alongside dts files which is the preferred way too as otherwise it would be complicated to locate DT files for the users. Also, we have to move towards Linux DT directory structure and thereby the tools like binman have to be adjusted. I will do that when I get to migrating SoCs supporting binman.
OK, I want to stop here and rethink this. This is the path taken so far, I believe:
1. We want to use devicetree files taken from Linux and devicetree-rebasing provides these 2. We want to use 'git subtree' to avoid needing a script to do the sync / create a commit 3. But this leaves us with a directory structure which doesn't match U-Boot (no script to fix it up) 4. So we deal with that by skipping the build rules and using CONFIG options to select what is built 5. So now we cannot build all the files for an SoC, just the ones that are in the CONFIG options 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't have this problem
So this is heading in the wrong direction. Nor is it clear that this would just be a temporary problem.
Possible options I see are:
a. Adjust U-Boot's dir structure to match Linux, first (but this might be painful?) b. Create a script to sync the files, so we can sync into a dir structure that matches U-Boot c. Add build rules to U-Boot's version of the devicetree-rebasing dir (this seems to be supported) d. Give up and just live with having boards (not SoCs) specify the devicetree files they want to build
I would like to do this series properly, maintaining the SoC-specific build rules, not removing what I see as an important feature. It should not be that difficult to figure out and I am happy to help with it.
The problem I have described above applied to meson, so I believe it is clear enough with that. I wasn't able to get rk3399 going, but I am sure it would have the same problem.
The fundamental question is (I believe) whether to:
- Build only a single DT for a board
- Build all DTs for the SoC the board uses
This series seems to head towards (1),
v2 of this series had the Makefile rules [1] for meson gxbb SoC but..
[1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-su...
which worries me. We are currently mostly at (2).
..after discussion with Tom, the Makefile rules are already coming via Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having redundant rules in Makefile doesn't add any value, so I took them off in v3.
Yes, I see that you did that.
This seems to be a fundamental point of disagreement. I would like all boards for an SoC to have mostly the same defconfig and just use a devicetree for differences, at least in U-Boot proper. That is what devicetree is for. In fact, I would like to see a lot more defaults in U-Boot, so that defconfig files are just a few lines like [2] and there is no board-specific C code not gated by a compatible string.
However, I am very much in favour of having a generalized U-Boot image. This might become true in some cases like U-Boot acts as a second stage bootloader for a particular SoC which is a unified image where the prior stage passes the DT to it. The Qcom effort in this direction can be an example here.
Not relevant to the topic at hand, perhaps, but Qualcomm uses a closed-source blob to jump to U-Boot and is certainly not an example we should emulate. But yes, passing a DT to U-Boot proper can be useful.
I am not sure at this point how we can enable different U-Boot features since there are many board specific bits needed currently not covered by DT.
I certainly see many examples of that, but the majority of features are covered. It was of course the same in Linux until someone put his foot down.
The other common method is to embed board DT in U-Boot image especially where U-Boot acts as a first stage bootloader. Once that's done I don't see how we can call that a generic U-Boot image.
If you mean OF_EMBED, then I don't think that is much used. It is just for using a JTAG debugger and these days, it is barely useful for that.
We do use fdtgrep to create a smaller FDT for SPL, though. In general, it will be harder to create a general SPL for an SoC. But it is also less beneficial, since SPL is small. Also, it is possible, as shown by rockchip.
BTW, as Tom said we can very well add those Makefile rules later on a use case basis if a particular SoC requires a truly generic U-Boot image and the rules don't come via Kconfig options.
We mostly have them already, so we should not remove them.
We are setting policy here. The policy should bias towards the generic, not to make that hard. There are over 900 arm64 devicetree files in Linux but only a few dozen SoCs and only one build. We should not have 900 arm64 U-Boots, only a few dozen and perhaps one day in the dim, distant future, if the tradeoffs make sense, one.
Regards, Simon
[2] https://patchwork.ozlabs.org/project/uboot/patch/20210619081645.42660-2-mtwg...
On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
Hi Sumit,
On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote:
On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > Hi Sumit, > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > directory. Also add a new Makefile for arm64. > > > > This will help easy migration for platforms which currently are compliant > > with upstream Linux kernel devicetree files. > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > --- > > > > Changes in v3: > > -------------- > > - Minor commit message update > > > > Changes in v2: > > -------------- > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > dts/Kconfig | 11 +++++++++++ > > dts/Makefile | 17 ++++++++++++++--- > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > 3 files changed, 39 insertions(+), 3 deletions(-) > > create mode 100644 dts/arch/arm64/Makefile > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > index 00c0aeff893..e58c1c6f2ab 100644 > > --- a/dts/Kconfig > > +++ b/dts/Kconfig > > @@ -85,6 +85,17 @@ config OF_LIVE > > enables a live tree which is available after relocation, > > and can be adjusted as needed. > > > > +config OF_UPSTREAM > > + bool "Enable use of devicetree imported from Linux kernel release" > > + help > > + Traditionally, U-Boot platforms used to have their custom devicetree > > + files or copy devicetree files from Linux kernel which are hard to > > + maintain and can usually get out-of-sync from Linux kernel. This > > + option enables platforms to migrate to devicetree-rebasing repo where > > + a regular sync will be maintained every major Linux kernel release > > + cycle. However, platforms can still have some custom u-boot specific > > + bits maintained as part of *-u-boot.dtsi files. > > My only other suggestion here is to mention that this should be set in > Kconfig, for the SoC as a whole. So I believe that means that it > should be hidden, with no string for the 'bool': > > bool # Enable use of devicetree imported from Linux kernel release
I think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
> Also, this doesn't seem to work for me. Before this series I get these > files when building firefly-rk3399: > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > rk3399-evb.dtb rk3399-leez-p710.dtb > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > rk3399-rock-4c-plus.dtb > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > Afterwards I get this: > > make[3]: *** No rule to make target > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > So I set this manually for that one board: > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > and get: > > make[3]: *** No rule to make target > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > I am not sure how to fix this, nor how this can be made to build all > the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
Using odroid-c2 with -next I see:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb meson-sm1-bananapi-m2-pro.dtb meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb meson-sm1-bananapi-m5.dtb meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb meson-sm1-khadas-vim3l.dtb meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb meson-sm1-odroid-c4.dtb meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb meson-sm1-odroid-hc4.dtb meson-g12b-odroid-go-ultra.dtb meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb $ With this series (sort of, since I am really not sure how to cherry-pick the commits from the PR) I see nothing:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ $
This shows some of the files:
$ find /tmp/b/odroid-c2/ -name "*.dtb" /tmp/b/odroid-c2/dts/dt.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb /tmp/b/odroid-c2/u-boot.dtb
but where are the rest? Also, is it possible to put the output .dtb files into the same directory? Otherwise we may have some pain with binman.
What do you mean by same directory? But maybe also, what's an example of a board you think might end up having problems? Converting that in a follow-up series is likely a good idea, to highlight and address these issues sooner rather than later.#
Today the .dtb files go into arch/arm/dts - so it would be easier if this series could do the same.
The kbuild infrastructure keeps the dtb alongside dts files which is the preferred way too as otherwise it would be complicated to locate DT files for the users. Also, we have to move towards Linux DT directory structure and thereby the tools like binman have to be adjusted. I will do that when I get to migrating SoCs supporting binman.
OK, I want to stop here and rethink this. This is the path taken so far, I believe:
- We want to use devicetree files taken from Linux and
devicetree-rebasing provides these
Yes.
- We want to use 'git subtree' to avoid needing a script to do the
sync / create a commit
No. We want to use 'git subtree' to avoid having to use git submodules.
- But this leaves us with a directory structure which doesn't match
U-Boot (no script to fix it up)
No. We intentionally abandon arch/*/dts because it's so full of out of date files and never fully re-synced, only re-synced ad-hoc.
- So we deal with that by skipping the build rules and using CONFIG
options to select what is built 5. So now we cannot build all the files for an SoC, just the ones that are in the CONFIG options 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't have this problem
No. devicetree-rebasing skips the Makefiles because they're part of the kernel. We couldn't re-use them ourselves because we don't have the same CONFIG names the kernel does. And Sumit has not replicated the logic we have under arch/*/dts/Makefile today because I've asked him not to, and we'll figure out what subsets of that logic make sense to add back in as a second step not a first step.
So this is heading in the wrong direction. Nor is it clear that this would just be a temporary problem.
A previous iteration of this series built all of the dtb files for the SoC that Sumit has migrated with this series, but then dropped it.
[snip]
I would like to do this series properly, maintaining the SoC-specific build rules, not removing what I see as an important feature. It should not be that difficult to figure out and I am happy to help with it.
The problem is that the rest of us do not understand the use case you're describing where a dtb file that would be useful in a build is not already in the list to build. The only one of those use cases I understand thus far is the exynos4 (iirc) case you mentioned previously where yes, really, one defconfig + appending board.dtb is fine, or fine enough. It's not that far off of the SPL_LOAD_FIT case, but there we know what to build already.
And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is how I see the use case you talk about being solved, if a full U-Boot is generic enough for N boards, SPL_LOAD_FIT does the right thing (in this non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't knnow how many modern SoCs can take a literal concatenated DTB and even in those cases I don't get why that's the win we want now? 1 build to N binaries?
But even then, I don't object to adding those rules to the Makefiles. If it works it works. I object to adding them when they don't work.
The fundamental question is (I believe) whether to:
- Build only a single DT for a board
- Build all DTs for the SoC the board uses
This series seems to head towards (1),
v2 of this series had the Makefile rules [1] for meson gxbb SoC but..
[1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-su...
which worries me. We are currently mostly at (2).
..after discussion with Tom, the Makefile rules are already coming via Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having redundant rules in Makefile doesn't add any value, so I took them off in v3.
Yes, I see that you did that.
This seems to be a fundamental point of disagreement. I would like all boards for an SoC to have mostly the same defconfig and just use a devicetree for differences, at least in U-Boot proper. That is what devicetree is for. In fact, I would like to see a lot more defaults in U-Boot, so that defconfig files are just a few lines like [2] and there is no board-specific C code not gated by a compatible string.
That's a nice goal to aim for. Sumit's work doesn't stop that being aimed for, and by making it easy to keep our device trees modern, it makes that easier, not harder.
Heck, it's something I've been working with the TI folks with for a few years now, and this work will make things easier for them because the dts files will get synced back, for all of the chips, sooner rather than later, and we can push towards getting rid of most of the -u-boot.dtsi work, and deal with the hard question of "where do r5 dts files go?". But that will not get rid of board/siemens/iot2050/ because that's what a custom hardware design needs and wants. Not "just pass the new DTB". This is another of the valid use cases that we need to keep in mind and design around, the explicit and intentional starting point of "don't just run the EVM binary for custom hardware design production".
However, I am very much in favour of having a generalized U-Boot image. This might become true in some cases like U-Boot acts as a second stage bootloader for a particular SoC which is a unified image where the prior stage passes the DT to it. The Qcom effort in this direction can be an example here.
Not relevant to the topic at hand, perhaps, but Qualcomm uses a closed-source blob to jump to U-Boot and is certainly not an example we should emulate. But yes, passing a DT to U-Boot proper can be useful.
It's a very valid use case we need to continue to support. And to save Mark from having to repeat himself, again, it's intentionally and not changing, how the Apple M1/M2/etc platforms boot. I'm pretty sure the fact that one can use U-Boot this way is part of how engineers get proof of concept work done to show that if they had U-Boot available then they could also support X/Y/Z easier. And maybe they'll be able to longer term push internally to use bloblist to pass things along.
Heck, trying to not go too far off on a tangent, maybe the m1n1 loader can implement both conventions, as both Linux Kernel[0] and Bloblist[1] use x0 for device tree, but bloblist has x1 non-zero and Linux does not, so both could be present here? Or is there some incompatibility I don't see on quick skimming?
Date: Sun, 31 Dec 2023 15:39:53 -0500 From: Tom Rini trini@konsulko.com
On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
Hi Sumit,
On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote:
On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote: > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > > Hi Sumit, > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > directory. Also add a new Makefile for arm64. > > > > > > This will help easy migration for platforms which currently are compliant > > > with upstream Linux kernel devicetree files. > > > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > > --- > > > > > > Changes in v3: > > > -------------- > > > - Minor commit message update > > > > > > Changes in v2: > > > -------------- > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > dts/Kconfig | 11 +++++++++++ > > > dts/Makefile | 17 ++++++++++++++--- > > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > --- a/dts/Kconfig > > > +++ b/dts/Kconfig > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > enables a live tree which is available after relocation, > > > and can be adjusted as needed. > > > > > > +config OF_UPSTREAM > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > + help > > > + Traditionally, U-Boot platforms used to have their custom devicetree > > > + files or copy devicetree files from Linux kernel which are hard to > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > + option enables platforms to migrate to devicetree-rebasing repo where > > > + a regular sync will be maintained every major Linux kernel release > > > + cycle. However, platforms can still have some custom u-boot specific > > > + bits maintained as part of *-u-boot.dtsi files. > > > > My only other suggestion here is to mention that this should be set in > > Kconfig, for the SoC as a whole. So I believe that means that it > > should be hidden, with no string for the 'bool': > > > > bool # Enable use of devicetree imported from Linux kernel release > > I think we can just keep prompting for it now, to make the transition > easier, before this option just goes away in time, hopefully. > > > Also, this doesn't seem to work for me. Before this series I get these > > files when building firefly-rk3399: > > > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > > rk3399-evb.dtb rk3399-leez-p710.dtb > > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > > rk3399-rock-4c-plus.dtb > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > Afterwards I get this: > > > > make[3]: *** No rule to make target > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > So I set this manually for that one board: > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > and get: > > > > make[3]: *** No rule to make target > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > I am not sure how to fix this, nor how this can be made to build all > > the DTs for rk3399, as it does today. > > Looking at the patch for amlogic boards, you need to make the link to > devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
Using odroid-c2 with -next I see:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb meson-sm1-bananapi-m2-pro.dtb meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb meson-sm1-bananapi-m5.dtb meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb meson-sm1-khadas-vim3l.dtb meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb meson-sm1-odroid-c4.dtb meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb meson-sm1-odroid-hc4.dtb meson-g12b-odroid-go-ultra.dtb meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb $ With this series (sort of, since I am really not sure how to cherry-pick the commits from the PR) I see nothing:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ $
This shows some of the files:
$ find /tmp/b/odroid-c2/ -name "*.dtb" /tmp/b/odroid-c2/dts/dt.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb /tmp/b/odroid-c2/u-boot.dtb
but where are the rest? Also, is it possible to put the output .dtb files into the same directory? Otherwise we may have some pain with binman.
What do you mean by same directory? But maybe also, what's an example of a board you think might end up having problems? Converting that in a follow-up series is likely a good idea, to highlight and address these issues sooner rather than later.#
Today the .dtb files go into arch/arm/dts - so it would be easier if this series could do the same.
The kbuild infrastructure keeps the dtb alongside dts files which is the preferred way too as otherwise it would be complicated to locate DT files for the users. Also, we have to move towards Linux DT directory structure and thereby the tools like binman have to be adjusted. I will do that when I get to migrating SoCs supporting binman.
OK, I want to stop here and rethink this. This is the path taken so far, I believe:
- We want to use devicetree files taken from Linux and
devicetree-rebasing provides these
Yes.
- We want to use 'git subtree' to avoid needing a script to do the
sync / create a commit
No. We want to use 'git subtree' to avoid having to use git submodules.
- But this leaves us with a directory structure which doesn't match
U-Boot (no script to fix it up)
No. We intentionally abandon arch/*/dts because it's so full of out of date files and never fully re-synced, only re-synced ad-hoc.
- So we deal with that by skipping the build rules and using CONFIG
options to select what is built 5. So now we cannot build all the files for an SoC, just the ones that are in the CONFIG options 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't have this problem
No. devicetree-rebasing skips the Makefiles because they're part of the kernel. We couldn't re-use them ourselves because we don't have the same CONFIG names the kernel does. And Sumit has not replicated the logic we have under arch/*/dts/Makefile today because I've asked him not to, and we'll figure out what subsets of that logic make sense to add back in as a second step not a first step.
So this is heading in the wrong direction. Nor is it clear that this would just be a temporary problem.
A previous iteration of this series built all of the dtb files for the SoC that Sumit has migrated with this series, but then dropped it.
[snip]
I would like to do this series properly, maintaining the SoC-specific build rules, not removing what I see as an important feature. It should not be that difficult to figure out and I am happy to help with it.
The problem is that the rest of us do not understand the use case you're describing where a dtb file that would be useful in a build is not already in the list to build. The only one of those use cases I understand thus far is the exynos4 (iirc) case you mentioned previously where yes, really, one defconfig + appending board.dtb is fine, or fine enough. It's not that far off of the SPL_LOAD_FIT case, but there we know what to build already.
And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is how I see the use case you talk about being solved, if a full U-Boot is generic enough for N boards, SPL_LOAD_FIT does the right thing (in this non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't knnow how many modern SoCs can take a literal concatenated DTB and even in those cases I don't get why that's the win we want now? 1 build to N binaries?
But even then, I don't object to adding those rules to the Makefiles. If it works it works. I object to adding them when they don't work.
The fundamental question is (I believe) whether to:
- Build only a single DT for a board
- Build all DTs for the SoC the board uses
This series seems to head towards (1),
v2 of this series had the Makefile rules [1] for meson gxbb SoC but..
[1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-su...
which worries me. We are currently mostly at (2).
..after discussion with Tom, the Makefile rules are already coming via Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having redundant rules in Makefile doesn't add any value, so I took them off in v3.
Yes, I see that you did that.
This seems to be a fundamental point of disagreement. I would like all boards for an SoC to have mostly the same defconfig and just use a devicetree for differences, at least in U-Boot proper. That is what devicetree is for. In fact, I would like to see a lot more defaults in U-Boot, so that defconfig files are just a few lines like [2] and there is no board-specific C code not gated by a compatible string.
That's a nice goal to aim for. Sumit's work doesn't stop that being aimed for, and by making it easy to keep our device trees modern, it makes that easier, not harder.
Heck, it's something I've been working with the TI folks with for a few years now, and this work will make things easier for them because the dts files will get synced back, for all of the chips, sooner rather than later, and we can push towards getting rid of most of the -u-boot.dtsi work, and deal with the hard question of "where do r5 dts files go?". But that will not get rid of board/siemens/iot2050/ because that's what a custom hardware design needs and wants. Not "just pass the new DTB". This is another of the valid use cases that we need to keep in mind and design around, the explicit and intentional starting point of "don't just run the EVM binary for custom hardware design production".
However, I am very much in favour of having a generalized U-Boot image. This might become true in some cases like U-Boot acts as a second stage bootloader for a particular SoC which is a unified image where the prior stage passes the DT to it. The Qcom effort in this direction can be an example here.
Not relevant to the topic at hand, perhaps, but Qualcomm uses a closed-source blob to jump to U-Boot and is certainly not an example we should emulate. But yes, passing a DT to U-Boot proper can be useful.
It's a very valid use case we need to continue to support. And to save Mark from having to repeat himself, again, it's intentionally and not changing, how the Apple M1/M2/etc platforms boot. I'm pretty sure the fact that one can use U-Boot this way is part of how engineers get proof of concept work done to show that if they had U-Boot available then they could also support X/Y/Z easier. And maybe they'll be able to longer term push internally to use bloblist to pass things along.
Heck, trying to not go too far off on a tangent, maybe the m1n1 loader can implement both conventions, as both Linux Kernel[0] and Bloblist[1] use x0 for device tree, but bloblist has x1 non-zero and Linux does not, so both could be present here? Or is there some incompatibility I don't see on quick skimming?
Right. Some time ago I suggested Simon to lobby the Linux kernel folks to change the arm64 Linux kernel entry convention to state that x1 can be non-zero in which case it points at a bloblist. If that happened I'd probably do the work to make m1n1 pass a bloblist. And it would probably make the folks who want to directly boot a Linux kernel from TF-A (without going through U-Boot) happy as well.
Cheers,
Mark
Hi Mark, Tom,
On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Sun, 31 Dec 2023 15:39:53 -0500 From: Tom Rini trini@konsulko.com
On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
Hi Sumit,
On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote:
On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote: > Hi Tom, Sumit, > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote: > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > > > Hi Sumit, > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > > directory. Also add a new Makefile for arm64. > > > > > > > > This will help easy migration for platforms which currently are compliant > > > > with upstream Linux kernel devicetree files. > > > > > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > > > --- > > > > > > > > Changes in v3: > > > > -------------- > > > > - Minor commit message update > > > > > > > > Changes in v2: > > > > -------------- > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > dts/Kconfig | 11 +++++++++++ > > > > dts/Makefile | 17 ++++++++++++++--- > > > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > --- a/dts/Kconfig > > > > +++ b/dts/Kconfig > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > enables a live tree which is available after relocation, > > > > and can be adjusted as needed. > > > > > > > > +config OF_UPSTREAM > > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > > + help > > > > + Traditionally, U-Boot platforms used to have their custom devicetree > > > > + files or copy devicetree files from Linux kernel which are hard to > > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > > + option enables platforms to migrate to devicetree-rebasing repo where > > > > + a regular sync will be maintained every major Linux kernel release > > > > + cycle. However, platforms can still have some custom u-boot specific > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > My only other suggestion here is to mention that this should be set in > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > should be hidden, with no string for the 'bool': > > > > > > bool # Enable use of devicetree imported from Linux kernel release > > > > I think we can just keep prompting for it now, to make the transition > > easier, before this option just goes away in time, hopefully. > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > files when building firefly-rk3399: > > > > > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > > > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > > > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > > > rk3399-rock-4c-plus.dtb > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > > > Afterwards I get this: > > > > > > make[3]: *** No rule to make target > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > So I set this manually for that one board: > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > and get: > > > > > > make[3]: *** No rule to make target > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > the DTs for rk3399, as it does today. > > > > Looking at the patch for amlogic boards, you need to make the link to > > devicetree-rebasing inside dts/... > > OK, let me give up on rk3399 for now...that doesn't seem to work even > with the link. > > Using odroid-c2 with -next I see: > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb > meson-gxl-s905x-libretech-cc.dtb > meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb > meson-gxl-s905x-libretech-cc-v2.dtb > meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb > meson-gxl-s905x-p212.dtb > meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb > meson-gxm-gt1-ultimate.dtb > meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb > meson-gxm-khadas-vim2.dtb > meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb > meson-gxm-s912-libretech-pc.dtb > meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb > meson-gxm-wetek-core2.dtb > meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb > meson-sm1-bananapi-m2-pro.dtb > meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb > meson-sm1-bananapi-m5.dtb > meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb > meson-sm1-khadas-vim3l.dtb > meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb > meson-sm1-odroid-c4.dtb > meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb > meson-sm1-odroid-hc4.dtb > meson-g12b-odroid-go-ultra.dtb > meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb > meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb > $ > With this series (sort of, since I am really not sure how to > cherry-pick the commits from the PR) I see nothing: > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > $ > > This shows some of the files: > > $ find /tmp/b/odroid-c2/ -name "*.dtb" > /tmp/b/odroid-c2/dts/dt.dtb > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb > /tmp/b/odroid-c2/u-boot.dtb > > but where are the rest? Also, is it possible to put the output .dtb > files into the same directory? Otherwise we may have some pain with > binman.
What do you mean by same directory? But maybe also, what's an example of a board you think might end up having problems? Converting that in a follow-up series is likely a good idea, to highlight and address these issues sooner rather than later.#
Today the .dtb files go into arch/arm/dts - so it would be easier if this series could do the same.
The kbuild infrastructure keeps the dtb alongside dts files which is the preferred way too as otherwise it would be complicated to locate DT files for the users. Also, we have to move towards Linux DT directory structure and thereby the tools like binman have to be adjusted. I will do that when I get to migrating SoCs supporting binman.
OK, I want to stop here and rethink this. This is the path taken so far, I believe:
- We want to use devicetree files taken from Linux and
devicetree-rebasing provides these
Yes.
- We want to use 'git subtree' to avoid needing a script to do the
sync / create a commit
No. We want to use 'git subtree' to avoid having to use git submodules.
Well that is what I understood from Sumit, when I asked about a script. I imagine a 100-line Python script could do the same as:
git subtree pull --prefix devicetree-rebasing git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git <release-tag> --squash
and it could also put the files in the right place for U-Boot.
- But this leaves us with a directory structure which doesn't match
U-Boot (no script to fix it up)
No. We intentionally abandon arch/*/dts because it's so full of out of date files and never fully re-synced, only re-synced ad-hoc.
I mean that the dir structure doesn't match. I am not worried about keeping arch/*/dts but I want the same structure somewhere else, e.g. dtr/arch/*/dts
- So we deal with that by skipping the build rules and using CONFIG
options to select what is built 5. So now we cannot build all the files for an SoC, just the ones that are in the CONFIG options 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't have this problem
No. devicetree-rebasing skips the Makefiles because they're part of the kernel. We couldn't re-use them ourselves because we don't have the same CONFIG names the kernel does. And Sumit has not replicated the logic we have under arch/*/dts/Makefile today because I've asked him not to, and we'll figure out what subsets of that logic make sense to add back in as a second step not a first step.
Again, you are missing my point. I am not suggesting using Linux's build rules, just explaining why Linux doesn't have the problem we would be creating here.
So this is heading in the wrong direction. Nor is it clear that this would just be a temporary problem.
A previous iteration of this series built all of the dtb files for the SoC that Sumit has migrated with this series, but then dropped it.
Oh.
[snip]
I would like to do this series properly, maintaining the SoC-specific build rules, not removing what I see as an important feature. It should not be that difficult to figure out and I am happy to help with it.
The problem is that the rest of us do not understand the use case you're describing where a dtb file that would be useful in a build is not already in the list to build. The only one of those use cases I understand thus far is the exynos4 (iirc) case you mentioned previously where yes, really, one defconfig + appending board.dtb is fine, or fine enough. It's not that far off of the SPL_LOAD_FIT case, but there we know what to build already.
Perhaps the problem is that the rest of you think of the build as all happening in U-Boot, similar to the proposed 'make image.fit' that I am trying to add to Linux.
But packaging can be (and often is) a separate step from building. Linux has no packaging mechanism today...it just builds everything (including all DTs) and stops.
We should be able to pick up whatever .dtb files we want and use them in an image.
And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is how I see the use case you talk about being solved, if a full U-Boot is generic enough for N boards, SPL_LOAD_FIT does the right thing (in this non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't knnow how many modern SoCs can take a literal concatenated DTB and even in those cases I don't get why that's the win we want now? 1 build to N binaries?
Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL to use the correct DT as well, so the DT will need to be determined in TPL, perhaps.
But anyway, this works OK with rk3399, for example. We need to support this use case.
Also, it is pretty easy. We just need to stick with the dir structure we have today and copy our existing Makefiles into that dir. Or change to the kernel dir structure and use that. Or do one, then the other.
But even then, I don't object to adding those rules to the Makefiles. If it works it works. I object to adding them when they don't work.
What do you mean by 'work'? With this series as is, it simply isn't possible to add Makefile rules, as they are ignored. Am I missing something?
The fundamental question is (I believe) whether to:
- Build only a single DT for a board
- Build all DTs for the SoC the board uses
This series seems to head towards (1),
v2 of this series had the Makefile rules [1] for meson gxbb SoC but..
[1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-su...
which worries me. We are currently mostly at (2).
..after discussion with Tom, the Makefile rules are already coming via Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having redundant rules in Makefile doesn't add any value, so I took them off in v3.
Yes, I see that you did that.
This seems to be a fundamental point of disagreement. I would like all boards for an SoC to have mostly the same defconfig and just use a devicetree for differences, at least in U-Boot proper. That is what devicetree is for. In fact, I would like to see a lot more defaults in U-Boot, so that defconfig files are just a few lines like [2] and there is no board-specific C code not gated by a compatible string.
That's a nice goal to aim for. Sumit's work doesn't stop that being aimed for, and by making it easy to keep our device trees modern, it makes that easier, not harder.
Heck, it's something I've been working with the TI folks with for a few years now, and this work will make things easier for them because the dts files will get synced back, for all of the chips, sooner rather than later, and we can push towards getting rid of most of the -u-boot.dtsi work, and deal with the hard question of "where do r5 dts files go?". But that will not get rid of board/siemens/iot2050/ because that's what a custom hardware design needs and wants. Not "just pass the new DTB". This is another of the valid use cases that we need to keep in mind and design around, the explicit and intentional starting point of "don't just run the EVM binary for custom hardware design production".
OK.
However, I am very much in favour of having a generalized U-Boot image. This might become true in some cases like U-Boot acts as a second stage bootloader for a particular SoC which is a unified image where the prior stage passes the DT to it. The Qcom effort in this direction can be an example here.
Not relevant to the topic at hand, perhaps, but Qualcomm uses a closed-source blob to jump to U-Boot and is certainly not an example we should emulate. But yes, passing a DT to U-Boot proper can be useful.
It's a very valid use case we need to continue to support. And to save Mark from having to repeat himself, again, it's intentionally and not changing, how the Apple M1/M2/etc platforms boot. I'm pretty sure the fact that one can use U-Boot this way is part of how engineers get proof of concept work done to show that if they had U-Boot available then they could also support X/Y/Z easier. And maybe they'll be able to longer term push internally to use bloblist to pass things along.
Heck, trying to not go too far off on a tangent, maybe the m1n1 loader can implement both conventions, as both Linux Kernel[0] and Bloblist[1] use x0 for device tree, but bloblist has x1 non-zero and Linux does not, so both could be present here? Or is there some incompatibility I don't see on quick skimming?
Right. Some time ago I suggested Simon to lobby the Linux kernel folks to change the arm64 Linux kernel entry convention to state that x1 can be non-zero in which case it points at a bloblist. If that happened I'd probably do the work to make m1n1 pass a bloblist. And it would probably make the folks who want to directly boot a Linux kernel from TF-A (without going through U-Boot) happy as well.
I got a lot of push-back on that. Perhaps there might be some willingness if it is explained that Linux doesn't need to understand the bloblist, just tolerate it being there. There are probably other people who will be more successful at pushing for kernel changes.
As you know, the handoff protocol is designed such that you don't need to decode the bloblist to find the devicetree. BTW I would like to put the ACPI/SMBIOS tables in the bloblist as well (with EFI we would provide pointers into the bloblist for Linux to use)
Regards, Simon
On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
Hi Mark, Tom,
On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Sun, 31 Dec 2023 15:39:53 -0500 From: Tom Rini trini@konsulko.com
On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
Hi Sumit,
On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote:
On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote: > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote: > > Hi Tom, Sumit, > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote: > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > > > > Hi Sumit, > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > This will help easy migration for platforms which currently are compliant > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > > > > --- > > > > > > > > > > Changes in v3: > > > > > -------------- > > > > > - Minor commit message update > > > > > > > > > > Changes in v2: > > > > > -------------- > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > dts/Kconfig | 11 +++++++++++ > > > > > dts/Makefile | 17 ++++++++++++++--- > > > > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > --- a/dts/Kconfig > > > > > +++ b/dts/Kconfig > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > enables a live tree which is available after relocation, > > > > > and can be adjusted as needed. > > > > > > > > > > +config OF_UPSTREAM > > > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > > > + help > > > > > + Traditionally, U-Boot platforms used to have their custom devicetree > > > > > + files or copy devicetree files from Linux kernel which are hard to > > > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > > > + option enables platforms to migrate to devicetree-rebasing repo where > > > > > + a regular sync will be maintained every major Linux kernel release > > > > > + cycle. However, platforms can still have some custom u-boot specific > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > My only other suggestion here is to mention that this should be set in > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > should be hidden, with no string for the 'bool': > > > > > > > > bool # Enable use of devicetree imported from Linux kernel release > > > > > > I think we can just keep prompting for it now, to make the transition > > > easier, before this option just goes away in time, hopefully. > > > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > > files when building firefly-rk3399: > > > > > > > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > > > > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > > > > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > > > > rk3399-rock-4c-plus.dtb > > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > > > > > Afterwards I get this: > > > > > > > > make[3]: *** No rule to make target > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > So I set this manually for that one board: > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > > > and get: > > > > > > > > make[3]: *** No rule to make target > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > > the DTs for rk3399, as it does today. > > > > > > Looking at the patch for amlogic boards, you need to make the link to > > > devicetree-rebasing inside dts/... > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even > > with the link. > > > > Using odroid-c2 with -next I see: > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb > > meson-gxl-s905x-libretech-cc.dtb > > meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb > > meson-gxl-s905x-libretech-cc-v2.dtb > > meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb > > meson-gxl-s905x-p212.dtb > > meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb > > meson-gxm-gt1-ultimate.dtb > > meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb > > meson-gxm-khadas-vim2.dtb > > meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb > > meson-gxm-s912-libretech-pc.dtb > > meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb > > meson-gxm-wetek-core2.dtb > > meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb > > meson-sm1-bananapi-m2-pro.dtb > > meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb > > meson-sm1-bananapi-m5.dtb > > meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb > > meson-sm1-khadas-vim3l.dtb > > meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb > > meson-sm1-odroid-c4.dtb > > meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb > > meson-sm1-odroid-hc4.dtb > > meson-g12b-odroid-go-ultra.dtb > > meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb > > meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb > > $ > > With this series (sort of, since I am really not sure how to > > cherry-pick the commits from the PR) I see nothing: > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > $ > > > > This shows some of the files: > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb" > > /tmp/b/odroid-c2/dts/dt.dtb > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb > > /tmp/b/odroid-c2/u-boot.dtb > > > > but where are the rest? Also, is it possible to put the output .dtb > > files into the same directory? Otherwise we may have some pain with > > binman. > > What do you mean by same directory? But maybe also, what's an example of > a board you think might end up having problems? Converting that in a > follow-up series is likely a good idea, to highlight and address these > issues sooner rather than later.#
Today the .dtb files go into arch/arm/dts - so it would be easier if this series could do the same.
The kbuild infrastructure keeps the dtb alongside dts files which is the preferred way too as otherwise it would be complicated to locate DT files for the users. Also, we have to move towards Linux DT directory structure and thereby the tools like binman have to be adjusted. I will do that when I get to migrating SoCs supporting binman.
OK, I want to stop here and rethink this. This is the path taken so far, I believe:
- We want to use devicetree files taken from Linux and
devicetree-rebasing provides these
Yes.
- We want to use 'git subtree' to avoid needing a script to do the
sync / create a commit
No. We want to use 'git subtree' to avoid having to use git submodules.
Well that is what I understood from Sumit, when I asked about a script. I imagine a 100-line Python script could do the same as:
git subtree pull --prefix devicetree-rebasing git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git <release-tag> --squash
and it could also put the files in the right place for U-Boot.
I've been saying in various places for years that I want to move away from arch/*/dts being where we have the "just a copy" dts files and have them somewhere else so they are easier to manage and differentiate our changes / additions. So arch/*/dts cannot be some hard-coded "right" path.
- But this leaves us with a directory structure which doesn't match
U-Boot (no script to fix it up)
No. We intentionally abandon arch/*/dts because it's so full of out of date files and never fully re-synced, only re-synced ad-hoc.
I mean that the dir structure doesn't match. I am not worried about keeping arch/*/dts but I want the same structure somewhere else, e.g. dtr/arch/*/dts
And what I want here is to match the same structure everyone that's not U-Boot uses. For better or worse no one else seems to have gone with "treat aarch64 as just another ARM", and then the vendor directory structure only makes that more obviously a mismatch. We need to follow what everyone else uses, and developers familiar with other projects will expect to see.
- So we deal with that by skipping the build rules and using CONFIG
options to select what is built 5. So now we cannot build all the files for an SoC, just the ones that are in the CONFIG options 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't have this problem
No. devicetree-rebasing skips the Makefiles because they're part of the kernel. We couldn't re-use them ourselves because we don't have the same CONFIG names the kernel does. And Sumit has not replicated the logic we have under arch/*/dts/Makefile today because I've asked him not to, and we'll figure out what subsets of that logic make sense to add back in as a second step not a first step.
Again, you are missing my point. I am not suggesting using Linux's build rules, just explaining why Linux doesn't have the problem we would be creating here.
So this is heading in the wrong direction. Nor is it clear that this would just be a temporary problem.
A previous iteration of this series built all of the dtb files for the SoC that Sumit has migrated with this series, but then dropped it.
Oh.
[snip]
I would like to do this series properly, maintaining the SoC-specific build rules, not removing what I see as an important feature. It should not be that difficult to figure out and I am happy to help with it.
The problem is that the rest of us do not understand the use case you're describing where a dtb file that would be useful in a build is not already in the list to build. The only one of those use cases I understand thus far is the exynos4 (iirc) case you mentioned previously where yes, really, one defconfig + appending board.dtb is fine, or fine enough. It's not that far off of the SPL_LOAD_FIT case, but there we know what to build already.
Perhaps the problem is that the rest of you think of the build as all happening in U-Boot, similar to the proposed 'make image.fit' that I am trying to add to Linux.
But packaging can be (and often is) a separate step from building. Linux has no packaging mechanism today...it just builds everything (including all DTs) and stops.
We should be able to pick up whatever .dtb files we want and use them in an image.
And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is how I see the use case you talk about being solved, if a full U-Boot is generic enough for N boards, SPL_LOAD_FIT does the right thing (in this non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't knnow how many modern SoCs can take a literal concatenated DTB and even in those cases I don't get why that's the win we want now? 1 build to N binaries?
Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL to use the correct DT as well, so the DT will need to be determined in TPL, perhaps.
I mean, SPL_LOAD_FIT still can handle this case, with a call to the function to re-parse the tree, when needed. I thought we did this today even, but perhaps I'm confusing my options here.
But anyway, this works OK with rk3399, for example. We need to support this use case.
Also, it is pretty easy. We just need to stick with the dir structure we have today and copy our existing Makefiles into that dir. Or change to the kernel dir structure and use that. Or do one, then the other.
I'm sorry, I don't understand what directory structure has to do with "build more dtbs". For the cases where it makes sense to, yes, we can build more dtbs, based on the SoC. I'm setting aside entirely the discussion on what SoCs that works for, for another thread.
Perhaps an issue here is that much like the kernel "install" target, we need an "install" target too, so that whatever dtbs we build can be more easily found for external packaging, but whatever tooling it is that wants it? And perhaps this is part of the problem, tooling that expects to pull things out of the object directory rather than an "installed" directory?
But even then, I don't object to adding those rules to the Makefiles. If it works it works. I object to adding them when they don't work.
What do you mean by 'work'? With this series as is, it simply isn't possible to add Makefile rules, as they are ignored. Am I missing something?
Yes, I think you're missing something. Perhaps you need to publish a WIP tree somewhere so someone can see what you're doing as it sounds like you're not able to add another SoC of any type on top of Sumit's tree and have it work.
Hi Tom,
On Mon, Jan 1, 2024 at 4:35 PM Tom Rini trini@konsulko.com wrote:
On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
Hi Mark, Tom,
On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Sun, 31 Dec 2023 15:39:53 -0500 From: Tom Rini trini@konsulko.com
On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
Hi Sumit,
On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote:
On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote: > > Hi Tom, > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote: > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote: > > > Hi Tom, Sumit, > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote: > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > > > > > Hi Sumit, > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant > > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > > > > > --- > > > > > > > > > > > > Changes in v3: > > > > > > -------------- > > > > > > - Minor commit message update > > > > > > > > > > > > Changes in v2: > > > > > > -------------- > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > > > dts/Kconfig | 11 +++++++++++ > > > > > > dts/Makefile | 17 ++++++++++++++--- > > > > > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > > --- a/dts/Kconfig > > > > > > +++ b/dts/Kconfig > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > > enables a live tree which is available after relocation, > > > > > > and can be adjusted as needed. > > > > > > > > > > > > +config OF_UPSTREAM > > > > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > > > > + help > > > > > > + Traditionally, U-Boot platforms used to have their custom devicetree > > > > > > + files or copy devicetree files from Linux kernel which are hard to > > > > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > > > > + option enables platforms to migrate to devicetree-rebasing repo where > > > > > > + a regular sync will be maintained every major Linux kernel release > > > > > > + cycle. However, platforms can still have some custom u-boot specific > > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > > > My only other suggestion here is to mention that this should be set in > > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > > should be hidden, with no string for the 'bool': > > > > > > > > > > bool # Enable use of devicetree imported from Linux kernel release > > > > > > > > I think we can just keep prompting for it now, to make the transition > > > > easier, before this option just goes away in time, hopefully. > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > > > files when building firefly-rk3399: > > > > > > > > > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > > > > > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > > > > > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > > > > > rk3399-rock-4c-plus.dtb > > > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > > > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > > > > > > > Afterwards I get this: > > > > > > > > > > make[3]: *** No rule to make target > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > So I set this manually for that one board: > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > > > > > and get: > > > > > > > > > > make[3]: *** No rule to make target > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > > > the DTs for rk3399, as it does today. > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to > > > > devicetree-rebasing inside dts/... > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even > > > with the link. > > > > > > Using odroid-c2 with -next I see: > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb > > > meson-gxl-s905x-libretech-cc.dtb > > > meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb > > > meson-gxl-s905x-libretech-cc-v2.dtb > > > meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb > > > meson-gxl-s905x-p212.dtb > > > meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb > > > meson-gxm-gt1-ultimate.dtb > > > meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb > > > meson-gxm-khadas-vim2.dtb > > > meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb > > > meson-gxm-s912-libretech-pc.dtb > > > meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb > > > meson-gxm-wetek-core2.dtb > > > meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb > > > meson-sm1-bananapi-m2-pro.dtb > > > meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb > > > meson-sm1-bananapi-m5.dtb > > > meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb > > > meson-sm1-khadas-vim3l.dtb > > > meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb > > > meson-sm1-odroid-c4.dtb > > > meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb > > > meson-sm1-odroid-hc4.dtb > > > meson-g12b-odroid-go-ultra.dtb > > > meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb > > > meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb > > > $ > > > With this series (sort of, since I am really not sure how to > > > cherry-pick the commits from the PR) I see nothing: > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > $ > > > > > > This shows some of the files: > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb" > > > /tmp/b/odroid-c2/dts/dt.dtb > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb > > > /tmp/b/odroid-c2/u-boot.dtb > > > > > > but where are the rest? Also, is it possible to put the output .dtb > > > files into the same directory? Otherwise we may have some pain with > > > binman. > > > > What do you mean by same directory? But maybe also, what's an example of > > a board you think might end up having problems? Converting that in a > > follow-up series is likely a good idea, to highlight and address these > > issues sooner rather than later.# > > Today the .dtb files go into arch/arm/dts - so it would be easier if > this series could do the same.
The kbuild infrastructure keeps the dtb alongside dts files which is the preferred way too as otherwise it would be complicated to locate DT files for the users. Also, we have to move towards Linux DT directory structure and thereby the tools like binman have to be adjusted. I will do that when I get to migrating SoCs supporting binman.
OK, I want to stop here and rethink this. This is the path taken so far, I believe:
- We want to use devicetree files taken from Linux and
devicetree-rebasing provides these
Yes.
- We want to use 'git subtree' to avoid needing a script to do the
sync / create a commit
No. We want to use 'git subtree' to avoid having to use git submodules.
Well that is what I understood from Sumit, when I asked about a script. I imagine a 100-line Python script could do the same as:
git subtree pull --prefix devicetree-rebasing git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git <release-tag> --squash
and it could also put the files in the right place for U-Boot.
I've been saying in various places for years that I want to move away from arch/*/dts being where we have the "just a copy" dts files and have them somewhere else so they are easier to manage and differentiate our changes / additions. So arch/*/dts cannot be some hard-coded "right" path.
OK
- But this leaves us with a directory structure which doesn't match
U-Boot (no script to fix it up)
No. We intentionally abandon arch/*/dts because it's so full of out of date files and never fully re-synced, only re-synced ad-hoc.
I mean that the dir structure doesn't match. I am not worried about keeping arch/*/dts but I want the same structure somewhere else, e.g. dtr/arch/*/dts
And what I want here is to match the same structure everyone that's not U-Boot uses. For better or worse no one else seems to have gone with "treat aarch64 as just another ARM", and then the vendor directory structure only makes that more obviously a mismatch. We need to follow what everyone else uses, and developers familiar with other projects will expect to see.
So you are saying that U-Boot should move to what Linux uses. I agree that seems like the best approach, so let's do it.
- So we deal with that by skipping the build rules and using CONFIG
options to select what is built 5. So now we cannot build all the files for an SoC, just the ones that are in the CONFIG options 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't have this problem
No. devicetree-rebasing skips the Makefiles because they're part of the kernel. We couldn't re-use them ourselves because we don't have the same CONFIG names the kernel does. And Sumit has not replicated the logic we have under arch/*/dts/Makefile today because I've asked him not to, and we'll figure out what subsets of that logic make sense to add back in as a second step not a first step.
Again, you are missing my point. I am not suggesting using Linux's build rules, just explaining why Linux doesn't have the problem we would be creating here.
So this is heading in the wrong direction. Nor is it clear that this would just be a temporary problem.
A previous iteration of this series built all of the dtb files for the SoC that Sumit has migrated with this series, but then dropped it.
Oh.
[snip]
I would like to do this series properly, maintaining the SoC-specific build rules, not removing what I see as an important feature. It should not be that difficult to figure out and I am happy to help with it.
The problem is that the rest of us do not understand the use case you're describing where a dtb file that would be useful in a build is not already in the list to build. The only one of those use cases I understand thus far is the exynos4 (iirc) case you mentioned previously where yes, really, one defconfig + appending board.dtb is fine, or fine enough. It's not that far off of the SPL_LOAD_FIT case, but there we know what to build already.
Perhaps the problem is that the rest of you think of the build as all happening in U-Boot, similar to the proposed 'make image.fit' that I am trying to add to Linux.
But packaging can be (and often is) a separate step from building. Linux has no packaging mechanism today...it just builds everything (including all DTs) and stops.
We should be able to pick up whatever .dtb files we want and use them in an image.
And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is how I see the use case you talk about being solved, if a full U-Boot is generic enough for N boards, SPL_LOAD_FIT does the right thing (in this non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't knnow how many modern SoCs can take a literal concatenated DTB and even in those cases I don't get why that's the win we want now? 1 build to N binaries?
Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL to use the correct DT as well, so the DT will need to be determined in TPL, perhaps.
I mean, SPL_LOAD_FIT still can handle this case, with a call to the function to re-parse the tree, when needed. I thought we did this today even, but perhaps I'm confusing my options here.
But anyway, this works OK with rk3399, for example. We need to support this use case.
Also, it is pretty easy. We just need to stick with the dir structure we have today and copy our existing Makefiles into that dir. Or change to the kernel dir structure and use that. Or do one, then the other.
I'm sorry, I don't understand what directory structure has to do with "build more dtbs". For the cases where it makes sense to, yes, we can build more dtbs, based on the SoC. I'm setting aside entirely the discussion on what SoCs that works for, for another thread.
Well you said above that we should switch to the kernel dir structure, so I believe that issue is resolved.
'build more dtbs' means build all the DTBs for an SoC, not just a selection that a particular board vendor decided on.
Perhaps an issue here is that much like the kernel "install" target, we need an "install" target too, so that whatever dtbs we build can be more easily found for external packaging, but whatever tooling it is that wants it? And perhaps this is part of the problem, tooling that expects to pull things out of the object directory rather than an "installed" directory?
This is where binman comes in. It can run as part of U-Boot build, to build a few default firmware images. Then it can be run *later*, outside the U-Boot build, with an augmented or more targeted image definition, with mostly the same input files, to pull together images for specific uses. As you say, the input files need to be in a defined location, which they are today, for the most part.
So even if a particular board only uses one DT, all the DTs for that SoC are built and so can be used in that final-packaging step. Without that build, there is no way to get the required .dtb files, other than building every board one by one and then pulling out the .dtb files or something weird like that.
Note that this works independently of whether OF_LIST is used, etc.
But even then, I don't object to adding those rules to the Makefiles. If it works it works. I object to adding them when they don't work.
What do you mean by 'work'? With this series as is, it simply isn't possible to add Makefile rules, as they are ignored. Am I missing something?
Yes, I think you're missing something. Perhaps you need to publish a WIP tree somewhere so someone can see what you're doing as it sounds like you're not able to add another SoC of any type on top of Sumit's tree and have it work.
The current -next source builds dtb files based on the SoC, for the most part. I sent a series to clean that up a bit[1], but it is mostly there.
From the above it seems like the plan could be:
1. Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust Makefiles accordingly 2. Choose a directory target for devicetree-rebasing. I see that 'barebox' uses 'dts' which seems better to me than 'devicetree-rebasing/src/'. Actually barebox even seems to have scripts for handling all of this [2]?? 3. Adjust the build system to use the dts/ directory for .dts files when OF_UPSTREAM is enabled
Then it will be easy. People can enable OF_UPSTREAM for an SoC (without changing DEFAULT_DEVICE_TREE) and will get the same behaviour as now, just with upstream .dts files. All the .dts files for an SoC are built, as now, just as Linux does. We can continue cleaning up the DT build rules as time permits.
Regards, Simon
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=388154 [2] https://git.pengutronix.de/cgit/barebox/tree/dts
On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
Hi Tom,
On Mon, Jan 1, 2024 at 4:35 PM Tom Rini trini@konsulko.com wrote:
On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
Hi Mark, Tom,
On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Sun, 31 Dec 2023 15:39:53 -0500 From: Tom Rini trini@konsulko.com
On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
Hi Sumit,
On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote: > > On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote: > > > > Hi Tom, > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote: > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote: > > > > Hi Tom, Sumit, > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote: > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > > > > > > Hi Sumit, > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant > > > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > > > > > > --- > > > > > > > > > > > > > > Changes in v3: > > > > > > > -------------- > > > > > > > - Minor commit message update > > > > > > > > > > > > > > Changes in v2: > > > > > > > -------------- > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > > > > > dts/Kconfig | 11 +++++++++++ > > > > > > > dts/Makefile | 17 ++++++++++++++--- > > > > > > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > > > --- a/dts/Kconfig > > > > > > > +++ b/dts/Kconfig > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > > > enables a live tree which is available after relocation, > > > > > > > and can be adjusted as needed. > > > > > > > > > > > > > > +config OF_UPSTREAM > > > > > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > > > > > + help > > > > > > > + Traditionally, U-Boot platforms used to have their custom devicetree > > > > > > > + files or copy devicetree files from Linux kernel which are hard to > > > > > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > > > > > + option enables platforms to migrate to devicetree-rebasing repo where > > > > > > > + a regular sync will be maintained every major Linux kernel release > > > > > > > + cycle. However, platforms can still have some custom u-boot specific > > > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > > > > > My only other suggestion here is to mention that this should be set in > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > > > should be hidden, with no string for the 'bool': > > > > > > > > > > > > bool # Enable use of devicetree imported from Linux kernel release > > > > > > > > > > I think we can just keep prompting for it now, to make the transition > > > > > easier, before this option just goes away in time, hopefully. > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > > > > files when building firefly-rk3399: > > > > > > > > > > > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > > > > > > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > > > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > > > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > > > > > > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > > > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > > > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > > > > > > rk3399-rock-4c-plus.dtb > > > > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > > > > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > > > > > > > > > Afterwards I get this: > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > So I set this manually for that one board: > > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > > > > > > > and get: > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > > > > the DTs for rk3399, as it does today. > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to > > > > > devicetree-rebasing inside dts/... > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even > > > > with the link. > > > > > > > > Using odroid-c2 with -next I see: > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb > > > > meson-gxl-s905x-libretech-cc.dtb > > > > meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb > > > > meson-gxl-s905x-libretech-cc-v2.dtb > > > > meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb > > > > meson-gxl-s905x-p212.dtb > > > > meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb > > > > meson-gxm-gt1-ultimate.dtb > > > > meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb > > > > meson-gxm-khadas-vim2.dtb > > > > meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb > > > > meson-gxm-s912-libretech-pc.dtb > > > > meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb > > > > meson-gxm-wetek-core2.dtb > > > > meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb > > > > meson-sm1-bananapi-m2-pro.dtb > > > > meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb > > > > meson-sm1-bananapi-m5.dtb > > > > meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb > > > > meson-sm1-khadas-vim3l.dtb > > > > meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb > > > > meson-sm1-odroid-c4.dtb > > > > meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb > > > > meson-sm1-odroid-hc4.dtb > > > > meson-g12b-odroid-go-ultra.dtb > > > > meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb > > > > meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb > > > > $ > > > > With this series (sort of, since I am really not sure how to > > > > cherry-pick the commits from the PR) I see nothing: > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > $ > > > > > > > > This shows some of the files: > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb" > > > > /tmp/b/odroid-c2/dts/dt.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb > > > > /tmp/b/odroid-c2/u-boot.dtb > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb > > > > files into the same directory? Otherwise we may have some pain with > > > > binman. > > > > > > What do you mean by same directory? But maybe also, what's an example of > > > a board you think might end up having problems? Converting that in a > > > follow-up series is likely a good idea, to highlight and address these > > > issues sooner rather than later.# > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if > > this series could do the same. > > The kbuild infrastructure keeps the dtb alongside dts files which is > the preferred way too as otherwise it would be complicated to locate > DT files for the users. Also, we have to move towards Linux DT > directory structure and thereby the tools like binman have to be > adjusted. I will do that when I get to migrating SoCs supporting > binman.
OK, I want to stop here and rethink this. This is the path taken so far, I believe:
- We want to use devicetree files taken from Linux and
devicetree-rebasing provides these
Yes.
- We want to use 'git subtree' to avoid needing a script to do the
sync / create a commit
No. We want to use 'git subtree' to avoid having to use git submodules.
Well that is what I understood from Sumit, when I asked about a script. I imagine a 100-line Python script could do the same as:
git subtree pull --prefix devicetree-rebasing git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git <release-tag> --squash
and it could also put the files in the right place for U-Boot.
I've been saying in various places for years that I want to move away from arch/*/dts being where we have the "just a copy" dts files and have them somewhere else so they are easier to manage and differentiate our changes / additions. So arch/*/dts cannot be some hard-coded "right" path.
OK
- But this leaves us with a directory structure which doesn't match
U-Boot (no script to fix it up)
No. We intentionally abandon arch/*/dts because it's so full of out of date files and never fully re-synced, only re-synced ad-hoc.
I mean that the dir structure doesn't match. I am not worried about keeping arch/*/dts but I want the same structure somewhere else, e.g. dtr/arch/*/dts
And what I want here is to match the same structure everyone that's not U-Boot uses. For better or worse no one else seems to have gone with "treat aarch64 as just another ARM", and then the vendor directory structure only makes that more obviously a mismatch. We need to follow what everyone else uses, and developers familiar with other projects will expect to see.
So you are saying that U-Boot should move to what Linux uses. I agree that seems like the best approach, so let's do it.
- So we deal with that by skipping the build rules and using CONFIG
options to select what is built 5. So now we cannot build all the files for an SoC, just the ones that are in the CONFIG options 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't have this problem
No. devicetree-rebasing skips the Makefiles because they're part of the kernel. We couldn't re-use them ourselves because we don't have the same CONFIG names the kernel does. And Sumit has not replicated the logic we have under arch/*/dts/Makefile today because I've asked him not to, and we'll figure out what subsets of that logic make sense to add back in as a second step not a first step.
Again, you are missing my point. I am not suggesting using Linux's build rules, just explaining why Linux doesn't have the problem we would be creating here.
So this is heading in the wrong direction. Nor is it clear that this would just be a temporary problem.
A previous iteration of this series built all of the dtb files for the SoC that Sumit has migrated with this series, but then dropped it.
Oh.
[snip]
I would like to do this series properly, maintaining the SoC-specific build rules, not removing what I see as an important feature. It should not be that difficult to figure out and I am happy to help with it.
The problem is that the rest of us do not understand the use case you're describing where a dtb file that would be useful in a build is not already in the list to build. The only one of those use cases I understand thus far is the exynos4 (iirc) case you mentioned previously where yes, really, one defconfig + appending board.dtb is fine, or fine enough. It's not that far off of the SPL_LOAD_FIT case, but there we know what to build already.
Perhaps the problem is that the rest of you think of the build as all happening in U-Boot, similar to the proposed 'make image.fit' that I am trying to add to Linux.
But packaging can be (and often is) a separate step from building. Linux has no packaging mechanism today...it just builds everything (including all DTs) and stops.
We should be able to pick up whatever .dtb files we want and use them in an image.
And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is how I see the use case you talk about being solved, if a full U-Boot is generic enough for N boards, SPL_LOAD_FIT does the right thing (in this non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't knnow how many modern SoCs can take a literal concatenated DTB and even in those cases I don't get why that's the win we want now? 1 build to N binaries?
Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL to use the correct DT as well, so the DT will need to be determined in TPL, perhaps.
I mean, SPL_LOAD_FIT still can handle this case, with a call to the function to re-parse the tree, when needed. I thought we did this today even, but perhaps I'm confusing my options here.
But anyway, this works OK with rk3399, for example. We need to support this use case.
Also, it is pretty easy. We just need to stick with the dir structure we have today and copy our existing Makefiles into that dir. Or change to the kernel dir structure and use that. Or do one, then the other.
I'm sorry, I don't understand what directory structure has to do with "build more dtbs". For the cases where it makes sense to, yes, we can build more dtbs, based on the SoC. I'm setting aside entirely the discussion on what SoCs that works for, for another thread.
Well you said above that we should switch to the kernel dir structure, so I believe that issue is resolved.
'build more dtbs' means build all the DTBs for an SoC, not just a selection that a particular board vendor decided on.
Yes, what other dtbs to build is the sticking point, in a number of threads now.
Perhaps an issue here is that much like the kernel "install" target, we need an "install" target too, so that whatever dtbs we build can be more easily found for external packaging, but whatever tooling it is that wants it? And perhaps this is part of the problem, tooling that expects to pull things out of the object directory rather than an "installed" directory?
This is where binman comes in. It can run as part of U-Boot build, to build a few default firmware images. Then it can be run *later*, outside the U-Boot build, with an augmented or more targeted image definition, with mostly the same input files, to pull together images for specific uses. As you say, the input files need to be in a defined location, which they are today, for the most part.
So even if a particular board only uses one DT, all the DTs for that SoC are built and so can be used in that final-packaging step. Without that build, there is no way to get the required .dtb files, other than building every board one by one and then pulling out the .dtb files or something weird like that.
Note that this works independently of whether OF_LIST is used, etc.
How about this. When you introduce generic-rk3399_defconfig is when we can also have dts-$(CONFIG_ROCKCHIP_RK3399) list everything, and insist it be kept up to date. That to me feels like the right order to go in. And we can have all of the implementation details be hashed out elsewhere, not in the thread about fixing our nightmare about dts file resync.
But even then, I don't object to adding those rules to the Makefiles. If it works it works. I object to adding them when they don't work.
What do you mean by 'work'? With this series as is, it simply isn't possible to add Makefile rules, as they are ignored. Am I missing something?
Yes, I think you're missing something. Perhaps you need to publish a WIP tree somewhere so someone can see what you're doing as it sounds like you're not able to add another SoC of any type on top of Sumit's tree and have it work.
The current -next source builds dtb files based on the SoC, for the most part. I sent a series to clean that up a bit[1], but it is mostly there.
Yes, and that relied on Rasmus' series having been merged ages ago which fixed up a number of "people just copypasta'd something here, incorrectly". Keep that in mind as part of why I have objections here.
From the above it seems like the plan could be:
- Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
Makefiles accordingly
Since we're going to move everyone to being from the upstream kernel, that seems like unneeded churn.
- Choose a directory target for devicetree-rebasing. I see that
'barebox' uses 'dts' which seems better to me than 'devicetree-rebasing/src/'. Actually barebox even seems to have scripts for handling all of this [2]??
They've been doing this since longer than git subtree has existed I believe. I suspect that much like how Rob would like to move the in-kernel devicetree compiler sync from a script to git subtree, barebox will too.
- Adjust the build system to use the dts/ directory for .dts files
when OF_UPSTREAM is enabled
Then it will be easy. People can enable OF_UPSTREAM for an SoC (without changing DEFAULT_DEVICE_TREE) and will get the same behaviour as now, just with upstream .dts files. All the .dts files for an SoC are built, as now, just as Linux does. We can continue cleaning up the DT build rules as time permits.
Maybe the unasked / unanswered question here is, why don't we put the subtree in to dts/ ? Just because it would make us more likely to make changes rather than treat it as read only?
Hi Tom,
On Tue, Jan 2, 2024 at 8:10 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
Hi Tom,
On Mon, Jan 1, 2024 at 4:35 PM Tom Rini trini@konsulko.com wrote:
On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
Hi Mark, Tom,
On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Sun, 31 Dec 2023 15:39:53 -0500 From: Tom Rini trini@konsulko.com
On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote: > Hi Sumit, > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote: > > > > > > Hi Tom, > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote: > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote: > > > > > Hi Tom, Sumit, > > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote: > > > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > > > > > > > Hi Sumit, > > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant > > > > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > > > > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > > > > > > > --- > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > -------------- > > > > > > > > - Minor commit message update > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > -------------- > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > > > > > > > dts/Kconfig | 11 +++++++++++ > > > > > > > > dts/Makefile | 17 ++++++++++++++--- > > > > > > > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > > > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > > > > --- a/dts/Kconfig > > > > > > > > +++ b/dts/Kconfig > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > > > > enables a live tree which is available after relocation, > > > > > > > > and can be adjusted as needed. > > > > > > > > > > > > > > > > +config OF_UPSTREAM > > > > > > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > > > > > > + help > > > > > > > > + Traditionally, U-Boot platforms used to have their custom devicetree > > > > > > > > + files or copy devicetree files from Linux kernel which are hard to > > > > > > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > > > > > > + option enables platforms to migrate to devicetree-rebasing repo where > > > > > > > > + a regular sync will be maintained every major Linux kernel release > > > > > > > > + cycle. However, platforms can still have some custom u-boot specific > > > > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > > > > > > > My only other suggestion here is to mention that this should be set in > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > > > > should be hidden, with no string for the 'bool': > > > > > > > > > > > > > > bool # Enable use of devicetree imported from Linux kernel release > > > > > > > > > > > > I think we can just keep prompting for it now, to make the transition > > > > > > easier, before this option just goes away in time, hopefully. > > > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > > > > > files when building firefly-rk3399: > > > > > > > > > > > > > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > > > > > > > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > > > > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > > > > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > > > > > > > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > > > > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > > > > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > > > > > > > rk3399-rock-4c-plus.dtb > > > > > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > > > > > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > > > > > > > > > > > Afterwards I get this: > > > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > > > So I set this manually for that one board: > > > > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > > > > > > > > > and get: > > > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > > > > > the DTs for rk3399, as it does today. > > > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to > > > > > > devicetree-rebasing inside dts/... > > > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even > > > > > with the link. > > > > > > > > > > Using odroid-c2 with -next I see: > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > > meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb > > > > > meson-gxl-s905x-libretech-cc.dtb > > > > > meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb > > > > > meson-gxl-s905x-libretech-cc-v2.dtb > > > > > meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb > > > > > meson-gxl-s905x-p212.dtb > > > > > meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb > > > > > meson-gxm-gt1-ultimate.dtb > > > > > meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb > > > > > meson-gxm-khadas-vim2.dtb > > > > > meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb > > > > > meson-gxm-s912-libretech-pc.dtb > > > > > meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb > > > > > meson-gxm-wetek-core2.dtb > > > > > meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb > > > > > meson-sm1-bananapi-m2-pro.dtb > > > > > meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb > > > > > meson-sm1-bananapi-m5.dtb > > > > > meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb > > > > > meson-sm1-khadas-vim3l.dtb > > > > > meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb > > > > > meson-sm1-odroid-c4.dtb > > > > > meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb > > > > > meson-sm1-odroid-hc4.dtb > > > > > meson-g12b-odroid-go-ultra.dtb > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb > > > > > meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb > > > > > $ > > > > > With this series (sort of, since I am really not sure how to > > > > > cherry-pick the commits from the PR) I see nothing: > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > > $ > > > > > > > > > > This shows some of the files: > > > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb" > > > > > /tmp/b/odroid-c2/dts/dt.dtb > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb > > > > > /tmp/b/odroid-c2/u-boot.dtb > > > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb > > > > > files into the same directory? Otherwise we may have some pain with > > > > > binman. > > > > > > > > What do you mean by same directory? But maybe also, what's an example of > > > > a board you think might end up having problems? Converting that in a > > > > follow-up series is likely a good idea, to highlight and address these > > > > issues sooner rather than later.# > > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if > > > this series could do the same. > > > > The kbuild infrastructure keeps the dtb alongside dts files which is > > the preferred way too as otherwise it would be complicated to locate > > DT files for the users. Also, we have to move towards Linux DT > > directory structure and thereby the tools like binman have to be > > adjusted. I will do that when I get to migrating SoCs supporting > > binman. > > OK, I want to stop here and rethink this. This is the path taken so > far, I believe: > > 1. We want to use devicetree files taken from Linux and > devicetree-rebasing provides these
Yes.
> 2. We want to use 'git subtree' to avoid needing a script to do the > sync / create a commit
No. We want to use 'git subtree' to avoid having to use git submodules.
Well that is what I understood from Sumit, when I asked about a script. I imagine a 100-line Python script could do the same as:
git subtree pull --prefix devicetree-rebasing git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git <release-tag> --squash
and it could also put the files in the right place for U-Boot.
I've been saying in various places for years that I want to move away from arch/*/dts being where we have the "just a copy" dts files and have them somewhere else so they are easier to manage and differentiate our changes / additions. So arch/*/dts cannot be some hard-coded "right" path.
OK
> 3. But this leaves us with a directory structure which doesn't match > U-Boot (no script to fix it up)
No. We intentionally abandon arch/*/dts because it's so full of out of date files and never fully re-synced, only re-synced ad-hoc.
I mean that the dir structure doesn't match. I am not worried about keeping arch/*/dts but I want the same structure somewhere else, e.g. dtr/arch/*/dts
And what I want here is to match the same structure everyone that's not U-Boot uses. For better or worse no one else seems to have gone with "treat aarch64 as just another ARM", and then the vendor directory structure only makes that more obviously a mismatch. We need to follow what everyone else uses, and developers familiar with other projects will expect to see.
So you are saying that U-Boot should move to what Linux uses. I agree that seems like the best approach, so let's do it.
> 4. So we deal with that by skipping the build rules and using CONFIG > options to select what is built > 5. So now we cannot build all the files for an SoC, just the ones that > are in the CONFIG options > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't > have this problem
No. devicetree-rebasing skips the Makefiles because they're part of the kernel. We couldn't re-use them ourselves because we don't have the same CONFIG names the kernel does. And Sumit has not replicated the logic we have under arch/*/dts/Makefile today because I've asked him not to, and we'll figure out what subsets of that logic make sense to add back in as a second step not a first step.
Again, you are missing my point. I am not suggesting using Linux's build rules, just explaining why Linux doesn't have the problem we would be creating here.
> So this is heading in the wrong direction. Nor is it clear that this > would just be a temporary problem.
A previous iteration of this series built all of the dtb files for the SoC that Sumit has migrated with this series, but then dropped it.
Oh.
[snip] > I would like to do this series properly, maintaining the SoC-specific > build rules, not removing what I see as an important feature. It > should not be that difficult to figure out and I am happy to help with > it.
The problem is that the rest of us do not understand the use case you're describing where a dtb file that would be useful in a build is not already in the list to build. The only one of those use cases I understand thus far is the exynos4 (iirc) case you mentioned previously where yes, really, one defconfig + appending board.dtb is fine, or fine enough. It's not that far off of the SPL_LOAD_FIT case, but there we know what to build already.
Perhaps the problem is that the rest of you think of the build as all happening in U-Boot, similar to the proposed 'make image.fit' that I am trying to add to Linux.
But packaging can be (and often is) a separate step from building. Linux has no packaging mechanism today...it just builds everything (including all DTs) and stops.
We should be able to pick up whatever .dtb files we want and use them in an image.
And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is how I see the use case you talk about being solved, if a full U-Boot is generic enough for N boards, SPL_LOAD_FIT does the right thing (in this non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't knnow how many modern SoCs can take a literal concatenated DTB and even in those cases I don't get why that's the win we want now? 1 build to N binaries?
Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL to use the correct DT as well, so the DT will need to be determined in TPL, perhaps.
I mean, SPL_LOAD_FIT still can handle this case, with a call to the function to re-parse the tree, when needed. I thought we did this today even, but perhaps I'm confusing my options here.
But anyway, this works OK with rk3399, for example. We need to support this use case.
Also, it is pretty easy. We just need to stick with the dir structure we have today and copy our existing Makefiles into that dir. Or change to the kernel dir structure and use that. Or do one, then the other.
I'm sorry, I don't understand what directory structure has to do with "build more dtbs". For the cases where it makes sense to, yes, we can build more dtbs, based on the SoC. I'm setting aside entirely the discussion on what SoCs that works for, for another thread.
Well you said above that we should switch to the kernel dir structure, so I believe that issue is resolved.
'build more dtbs' means build all the DTBs for an SoC, not just a selection that a particular board vendor decided on.
Yes, what other dtbs to build is the sticking point, in a number of threads now.
All of the ones for the SoC.
Perhaps an issue here is that much like the kernel "install" target, we need an "install" target too, so that whatever dtbs we build can be more easily found for external packaging, but whatever tooling it is that wants it? And perhaps this is part of the problem, tooling that expects to pull things out of the object directory rather than an "installed" directory?
This is where binman comes in. It can run as part of U-Boot build, to build a few default firmware images. Then it can be run *later*, outside the U-Boot build, with an augmented or more targeted image definition, with mostly the same input files, to pull together images for specific uses. As you say, the input files need to be in a defined location, which they are today, for the most part.
So even if a particular board only uses one DT, all the DTs for that SoC are built and so can be used in that final-packaging step. Without that build, there is no way to get the required .dtb files, other than building every board one by one and then pulling out the .dtb files or something weird like that.
Note that this works independently of whether OF_LIST is used, etc.
How about this. When you introduce generic-rk3399_defconfig is when we can also have dts-$(CONFIG_ROCKCHIP_RK3399) list everything, and insist it be kept up to date. That to me feels like the right order to go in. And we can have all of the implementation details be hashed out elsewhere, not in the thread about fixing our nightmare about dts file resync.
So long as Sumit can put it back so we can use build rules, that's fine. But removing the build rules is the sticking point for me.
But even then, I don't object to adding those rules to the Makefiles. If it works it works. I object to adding them when they don't work.
What do you mean by 'work'? With this series as is, it simply isn't possible to add Makefile rules, as they are ignored. Am I missing something?
Yes, I think you're missing something. Perhaps you need to publish a WIP tree somewhere so someone can see what you're doing as it sounds like you're not able to add another SoC of any type on top of Sumit's tree and have it work.
The current -next source builds dtb files based on the SoC, for the most part. I sent a series to clean that up a bit[1], but it is mostly there.
Yes, and that relied on Rasmus' series having been merged ages ago which fixed up a number of "people just copypasta'd something here, incorrectly". Keep that in mind as part of why I have objections here.
OK.
From the above it seems like the plan could be:
- Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
Makefiles accordingly
Since we're going to move everyone to being from the upstream kernel, that seems like unneeded churn.
What is the timeline for that move?
We are talking about 1700 lines of Makefies and I already made a good start on part of it. So if we are going to be a few months with two different paths, fine, but this is going to drag on for a year, I would rather clean it up now and have a unified path for both sets of DTs.
- Choose a directory target for devicetree-rebasing. I see that
'barebox' uses 'dts' which seems better to me than 'devicetree-rebasing/src/'. Actually barebox even seems to have scripts for handling all of this [2]??
They've been doing this since longer than git subtree has existed I believe. I suspect that much like how Rob would like to move the in-kernel devicetree compiler sync from a script to git subtree, barebox will too.
Maybe, although the first barebox dts/ commit was 2014 and subtree is claimed to come out in 2012...but then devicetree-rebasing might be newer, which would explain why they have 'git filter-branch' stuff in the script.
I thought devicetree-rebasing came from Linux. Is it its own repo? So what is the DT upstream these days??
If subtree does what we want without making U-Boot look like Franekstein's monster, that's fine. But I don't mind having a script.
- Adjust the build system to use the dts/ directory for .dts files
when OF_UPSTREAM is enabled
Then it will be easy. People can enable OF_UPSTREAM for an SoC (without changing DEFAULT_DEVICE_TREE) and will get the same behaviour as now, just with upstream .dts files. All the .dts files for an SoC are built, as now, just as Linux does. We can continue cleaning up the DT build rules as time permits.
Maybe the unasked / unanswered question here is, why don't we put the subtree in to dts/ ? Just because it would make us more likely to make changes rather than treat it as read only?
It is an easy checkpatch check, if that is your only concern.
Regards, Simon
On Tue, Jan 02, 2024 at 04:54:15PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jan 2, 2024 at 8:10 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
Hi Tom,
On Mon, Jan 1, 2024 at 4:35 PM Tom Rini trini@konsulko.com wrote:
On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
Hi Mark, Tom,
On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis mark.kettenis@xs4all.nl wrote:
> Date: Sun, 31 Dec 2023 15:39:53 -0500 > From: Tom Rini trini@konsulko.com > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote: > > Hi Sumit, > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote: > > > > > > > > Hi Tom, > > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote: > > > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote: > > > > > > Hi Tom, Sumit, > > > > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote: > > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > > > > > > > > Hi Sumit, > > > > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > > > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant > > > > > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > > > > > > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > > > > > > > > --- > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > -------------- > > > > > > > > > - Minor commit message update > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > -------------- > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > > > > > > > > > dts/Kconfig | 11 +++++++++++ > > > > > > > > > dts/Makefile | 17 ++++++++++++++--- > > > > > > > > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > > > > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > > > > > --- a/dts/Kconfig > > > > > > > > > +++ b/dts/Kconfig > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > > > > > enables a live tree which is available after relocation, > > > > > > > > > and can be adjusted as needed. > > > > > > > > > > > > > > > > > > +config OF_UPSTREAM > > > > > > > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > > > > > > > + help > > > > > > > > > + Traditionally, U-Boot platforms used to have their custom devicetree > > > > > > > > > + files or copy devicetree files from Linux kernel which are hard to > > > > > > > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > > > > > > > + option enables platforms to migrate to devicetree-rebasing repo where > > > > > > > > > + a regular sync will be maintained every major Linux kernel release > > > > > > > > > + cycle. However, platforms can still have some custom u-boot specific > > > > > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > > > > > > > > > My only other suggestion here is to mention that this should be set in > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > > > > > should be hidden, with no string for the 'bool': > > > > > > > > > > > > > > > > bool # Enable use of devicetree imported from Linux kernel release > > > > > > > > > > > > > > I think we can just keep prompting for it now, to make the transition > > > > > > > easier, before this option just goes away in time, hopefully. > > > > > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > > > > > > files when building firefly-rk3399: > > > > > > > > > > > > > > > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > > > > > > > > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > > > > > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > > > > > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > > > > > > > > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > > > > > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > > > > > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > > > > > > > > rk3399-rock-4c-plus.dtb > > > > > > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > > > > > > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > > > > > > > > > > > > > Afterwards I get this: > > > > > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > > > > > So I set this manually for that one board: > > > > > > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > > > > > > > > > > > and get: > > > > > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > > > > > > the DTs for rk3399, as it does today. > > > > > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to > > > > > > > devicetree-rebasing inside dts/... > > > > > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even > > > > > > with the link. > > > > > > > > > > > > Using odroid-c2 with -next I see: > > > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > > > meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb > > > > > > meson-gxl-s905x-libretech-cc.dtb > > > > > > meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb > > > > > > meson-gxl-s905x-libretech-cc-v2.dtb > > > > > > meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb > > > > > > meson-gxl-s905x-p212.dtb > > > > > > meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb > > > > > > meson-gxm-gt1-ultimate.dtb > > > > > > meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb > > > > > > meson-gxm-khadas-vim2.dtb > > > > > > meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb > > > > > > meson-gxm-s912-libretech-pc.dtb > > > > > > meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb > > > > > > meson-gxm-wetek-core2.dtb > > > > > > meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb > > > > > > meson-sm1-bananapi-m2-pro.dtb > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb > > > > > > meson-sm1-bananapi-m5.dtb > > > > > > meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb > > > > > > meson-sm1-khadas-vim3l.dtb > > > > > > meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb > > > > > > meson-sm1-odroid-c4.dtb > > > > > > meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb > > > > > > meson-sm1-odroid-hc4.dtb > > > > > > meson-g12b-odroid-go-ultra.dtb > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb > > > > > > meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb > > > > > > $ > > > > > > With this series (sort of, since I am really not sure how to > > > > > > cherry-pick the commits from the PR) I see nothing: > > > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > > > $ > > > > > > > > > > > > This shows some of the files: > > > > > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb" > > > > > > /tmp/b/odroid-c2/dts/dt.dtb > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb > > > > > > /tmp/b/odroid-c2/u-boot.dtb > > > > > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb > > > > > > files into the same directory? Otherwise we may have some pain with > > > > > > binman. > > > > > > > > > > What do you mean by same directory? But maybe also, what's an example of > > > > > a board you think might end up having problems? Converting that in a > > > > > follow-up series is likely a good idea, to highlight and address these > > > > > issues sooner rather than later.# > > > > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if > > > > this series could do the same. > > > > > > The kbuild infrastructure keeps the dtb alongside dts files which is > > > the preferred way too as otherwise it would be complicated to locate > > > DT files for the users. Also, we have to move towards Linux DT > > > directory structure and thereby the tools like binman have to be > > > adjusted. I will do that when I get to migrating SoCs supporting > > > binman. > > > > OK, I want to stop here and rethink this. This is the path taken so > > far, I believe: > > > > 1. We want to use devicetree files taken from Linux and > > devicetree-rebasing provides these > > Yes. > > > 2. We want to use 'git subtree' to avoid needing a script to do the > > sync / create a commit > > No. We want to use 'git subtree' to avoid having to use git submodules.
Well that is what I understood from Sumit, when I asked about a script. I imagine a 100-line Python script could do the same as:
git subtree pull --prefix devicetree-rebasing git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git <release-tag> --squash
and it could also put the files in the right place for U-Boot.
I've been saying in various places for years that I want to move away from arch/*/dts being where we have the "just a copy" dts files and have them somewhere else so they are easier to manage and differentiate our changes / additions. So arch/*/dts cannot be some hard-coded "right" path.
OK
> > 3. But this leaves us with a directory structure which doesn't match > > U-Boot (no script to fix it up) > > No. We intentionally abandon arch/*/dts because it's so full of > out of date files and never fully re-synced, only re-synced ad-hoc.
I mean that the dir structure doesn't match. I am not worried about keeping arch/*/dts but I want the same structure somewhere else, e.g. dtr/arch/*/dts
And what I want here is to match the same structure everyone that's not U-Boot uses. For better or worse no one else seems to have gone with "treat aarch64 as just another ARM", and then the vendor directory structure only makes that more obviously a mismatch. We need to follow what everyone else uses, and developers familiar with other projects will expect to see.
So you are saying that U-Boot should move to what Linux uses. I agree that seems like the best approach, so let's do it.
> > 4. So we deal with that by skipping the build rules and using CONFIG > > options to select what is built > > 5. So now we cannot build all the files for an SoC, just the ones that > > are in the CONFIG options > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't > > have this problem > > No. devicetree-rebasing skips the Makefiles because they're part of the > kernel. We couldn't re-use them ourselves because we don't have the same > CONFIG names the kernel does. And Sumit has not replicated the logic we > have under arch/*/dts/Makefile today because I've asked him not to, and > we'll figure out what subsets of that logic make sense to add back in as > a second step not a first step.
Again, you are missing my point. I am not suggesting using Linux's build rules, just explaining why Linux doesn't have the problem we would be creating here.
> > So this is heading in the wrong direction. Nor is it clear that this > > would just be a temporary problem. > > A previous iteration of this series built all of the dtb files for the > SoC that Sumit has migrated with this series, but then dropped it.
Oh.
> > [snip] > > I would like to do this series properly, maintaining the SoC-specific > > build rules, not removing what I see as an important feature. It > > should not be that difficult to figure out and I am happy to help with > > it. > > The problem is that the rest of us do not understand the use case you're > describing where a dtb file that would be useful in a build is not > already in the list to build. The only one of those use cases I > understand thus far is the exynos4 (iirc) case you mentioned previously > where yes, really, one defconfig + appending board.dtb is fine, or fine > enough. It's not that far off of the SPL_LOAD_FIT case, but there we > know what to build already.
Perhaps the problem is that the rest of you think of the build as all happening in U-Boot, similar to the proposed 'make image.fit' that I am trying to add to Linux.
But packaging can be (and often is) a separate step from building. Linux has no packaging mechanism today...it just builds everything (including all DTs) and stops.
We should be able to pick up whatever .dtb files we want and use them in an image.
> And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is > how I see the use case you talk about being solved, if a full U-Boot is > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't > knnow how many modern SoCs can take a literal concatenated DTB and even > in those cases I don't get why that's the win we want now? 1 build to N > binaries?
Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL to use the correct DT as well, so the DT will need to be determined in TPL, perhaps.
I mean, SPL_LOAD_FIT still can handle this case, with a call to the function to re-parse the tree, when needed. I thought we did this today even, but perhaps I'm confusing my options here.
But anyway, this works OK with rk3399, for example. We need to support this use case.
Also, it is pretty easy. We just need to stick with the dir structure we have today and copy our existing Makefiles into that dir. Or change to the kernel dir structure and use that. Or do one, then the other.
I'm sorry, I don't understand what directory structure has to do with "build more dtbs". For the cases where it makes sense to, yes, we can build more dtbs, based on the SoC. I'm setting aside entirely the discussion on what SoCs that works for, for another thread.
Well you said above that we should switch to the kernel dir structure, so I believe that issue is resolved.
'build more dtbs' means build all the DTBs for an SoC, not just a selection that a particular board vendor decided on.
Yes, what other dtbs to build is the sticking point, in a number of threads now.
All of the ones for the SoC.
Yes, that's your position, and it's not anyone elses position.
Perhaps an issue here is that much like the kernel "install" target, we need an "install" target too, so that whatever dtbs we build can be more easily found for external packaging, but whatever tooling it is that wants it? And perhaps this is part of the problem, tooling that expects to pull things out of the object directory rather than an "installed" directory?
This is where binman comes in. It can run as part of U-Boot build, to build a few default firmware images. Then it can be run *later*, outside the U-Boot build, with an augmented or more targeted image definition, with mostly the same input files, to pull together images for specific uses. As you say, the input files need to be in a defined location, which they are today, for the most part.
So even if a particular board only uses one DT, all the DTs for that SoC are built and so can be used in that final-packaging step. Without that build, there is no way to get the required .dtb files, other than building every board one by one and then pulling out the .dtb files or something weird like that.
Note that this works independently of whether OF_LIST is used, etc.
How about this. When you introduce generic-rk3399_defconfig is when we can also have dts-$(CONFIG_ROCKCHIP_RK3399) list everything, and insist it be kept up to date. That to me feels like the right order to go in. And we can have all of the implementation details be hashed out elsewhere, not in the thread about fixing our nightmare about dts file resync.
So long as Sumit can put it back so we can use build rules, that's fine. But removing the build rules is the sticking point for me.
But it's not a sticking point for anyone else for the series. Because no one else gets the point you're trying to make.
> But even then, I don't object to adding those rules to the Makefiles. If > it works it works. I object to adding them when they don't work.
What do you mean by 'work'? With this series as is, it simply isn't possible to add Makefile rules, as they are ignored. Am I missing something?
Yes, I think you're missing something. Perhaps you need to publish a WIP tree somewhere so someone can see what you're doing as it sounds like you're not able to add another SoC of any type on top of Sumit's tree and have it work.
The current -next source builds dtb files based on the SoC, for the most part. I sent a series to clean that up a bit[1], but it is mostly there.
Yes, and that relied on Rasmus' series having been merged ages ago which fixed up a number of "people just copypasta'd something here, incorrectly". Keep that in mind as part of why I have objections here.
OK.
And since I think you're missing the point I was raising, because no one else has the "any dtb from the SoC with this binary", we'll just be getting back to re-introducing those kind of problems with what you're demanding.
From the above it seems like the plan could be:
- Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
Makefiles accordingly
Since we're going to move everyone to being from the upstream kernel, that seems like unneeded churn.
What is the timeline for that move?
It could probably, largely, be done in 2024, for the platforms that actively sync. For the ones that aren't behaving well right now? I don't know, it'll depend on when someone shows up being active about them again.
We are talking about 1700 lines of Makefies and I already made a good start on part of it. So if we are going to be a few months with two different paths, fine, but this is going to drag on for a year, I would rather clean it up now and have a unified path for both sets of DTs.
The sticking point for migration is going to be the testing of the platforms that are not well in sync at all.
- Choose a directory target for devicetree-rebasing. I see that
'barebox' uses 'dts' which seems better to me than 'devicetree-rebasing/src/'. Actually barebox even seems to have scripts for handling all of this [2]??
They've been doing this since longer than git subtree has existed I believe. I suspect that much like how Rob would like to move the in-kernel devicetree compiler sync from a script to git subtree, barebox will too.
Maybe, although the first barebox dts/ commit was 2014 and subtree is claimed to come out in 2012...but then devicetree-rebasing might be newer, which would explain why they have 'git filter-branch' stuff in the script.
Well, it was just a guess on my part. It took a while for subtree to catch on, and yes, it's taken a while for everything to reach the state it's in today, for dts sources outside of the linux kernel itself.
I thought devicetree-rebasing came from Linux. Is it its own repo? So what is the DT upstream these days??
I'll let Rob chime in again here if he likes. In short, devicetree-rebasing is the kernel dts files/bindings copied out and tagged, matching upstream kernel tags, and with assorted useful bits of git history available.
If subtree does what we want without making U-Boot look like Franekstein's monster, that's fine. But I don't mind having a script.
Yes, everyone else thus far seems fine with what we get via this series.
- Adjust the build system to use the dts/ directory for .dts files
when OF_UPSTREAM is enabled
Then it will be easy. People can enable OF_UPSTREAM for an SoC (without changing DEFAULT_DEVICE_TREE) and will get the same behaviour as now, just with upstream .dts files. All the .dts files for an SoC are built, as now, just as Linux does. We can continue cleaning up the DT build rules as time permits.
Maybe the unasked / unanswered question here is, why don't we put the subtree in to dts/ ? Just because it would make us more likely to make changes rather than treat it as read only?
It is an easy checkpatch check, if that is your only concern.
Yeah, checkpatch isn't great for catching and stopping things. I don't know how many other custodians check their PRs before I get to them. So if it's not a fatal CI thing, it's not going to always be caught before I see it, and I don't always catch "ERROR" things in checkpatch in a PR either. But it might still be more annoying than not to have subtree be shoved in to "dts". I'm hoping for some feedback from Sumit on this point since I think he's played around.
Hi Tom,
On Tue, Jan 2, 2024 at 5:41 PM Tom Rini trini@konsulko.com wrote:
On Tue, Jan 02, 2024 at 04:54:15PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jan 2, 2024 at 8:10 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
Hi Tom,
On Mon, Jan 1, 2024 at 4:35 PM Tom Rini trini@konsulko.com wrote:
On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
Hi Mark, Tom,
On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis mark.kettenis@xs4all.nl wrote: > > > Date: Sun, 31 Dec 2023 15:39:53 -0500 > > From: Tom Rini trini@konsulko.com > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote: > > > Hi Sumit, > > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote: > > > > > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote: > > > > > > > Hi Tom, Sumit, > > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote: > > > > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > > > > > > > > > Hi Sumit, > > > > > > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > > > > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > > > > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant > > > > > > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > -------------- > > > > > > > > > > - Minor commit message update > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > -------------- > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > > > > > > > > > > > dts/Kconfig | 11 +++++++++++ > > > > > > > > > > dts/Makefile | 17 ++++++++++++++--- > > > > > > > > > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > > > > > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > > > > > > --- a/dts/Kconfig > > > > > > > > > > +++ b/dts/Kconfig > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > > > > > > enables a live tree which is available after relocation, > > > > > > > > > > and can be adjusted as needed. > > > > > > > > > > > > > > > > > > > > +config OF_UPSTREAM > > > > > > > > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > > > > > > > > + help > > > > > > > > > > + Traditionally, U-Boot platforms used to have their custom devicetree > > > > > > > > > > + files or copy devicetree files from Linux kernel which are hard to > > > > > > > > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > > > > > > > > + option enables platforms to migrate to devicetree-rebasing repo where > > > > > > > > > > + a regular sync will be maintained every major Linux kernel release > > > > > > > > > > + cycle. However, platforms can still have some custom u-boot specific > > > > > > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > > > > > > > > > > > My only other suggestion here is to mention that this should be set in > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > > > > > > should be hidden, with no string for the 'bool': > > > > > > > > > > > > > > > > > > bool # Enable use of devicetree imported from Linux kernel release > > > > > > > > > > > > > > > > I think we can just keep prompting for it now, to make the transition > > > > > > > > easier, before this option just goes away in time, hopefully. > > > > > > > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > > > > > > > files when building firefly-rk3399: > > > > > > > > > > > > > > > > > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > > > > > > > > > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > > > > > > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > > > > > > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > > > > > > > > > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > > > > > > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > > > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > > > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > > > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > > > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > > > > > > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > > > > > > > > > rk3399-rock-4c-plus.dtb > > > > > > > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > > > > > > > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > > > > > > > > > > > > > > > Afterwards I get this: > > > > > > > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > > > > > > > So I set this manually for that one board: > > > > > > > > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > > > > > > > > > > > > > and get: > > > > > > > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > > > > > > > the DTs for rk3399, as it does today. > > > > > > > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to > > > > > > > > devicetree-rebasing inside dts/... > > > > > > > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even > > > > > > > with the link. > > > > > > > > > > > > > > Using odroid-c2 with -next I see: > > > > > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > > > > meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb > > > > > > > meson-gxl-s905x-libretech-cc.dtb > > > > > > > meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb > > > > > > > meson-gxl-s905x-libretech-cc-v2.dtb > > > > > > > meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb > > > > > > > meson-gxl-s905x-p212.dtb > > > > > > > meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb > > > > > > > meson-gxm-gt1-ultimate.dtb > > > > > > > meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb > > > > > > > meson-gxm-khadas-vim2.dtb > > > > > > > meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb > > > > > > > meson-gxm-s912-libretech-pc.dtb > > > > > > > meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb > > > > > > > meson-gxm-wetek-core2.dtb > > > > > > > meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb > > > > > > > meson-sm1-bananapi-m2-pro.dtb > > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb > > > > > > > meson-sm1-bananapi-m5.dtb > > > > > > > meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb > > > > > > > meson-sm1-khadas-vim3l.dtb > > > > > > > meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb > > > > > > > meson-sm1-odroid-c4.dtb > > > > > > > meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb > > > > > > > meson-sm1-odroid-hc4.dtb > > > > > > > meson-g12b-odroid-go-ultra.dtb > > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb > > > > > > > meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb > > > > > > > $ > > > > > > > With this series (sort of, since I am really not sure how to > > > > > > > cherry-pick the commits from the PR) I see nothing: > > > > > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > > > > $ > > > > > > > > > > > > > > This shows some of the files: > > > > > > > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb" > > > > > > > /tmp/b/odroid-c2/dts/dt.dtb > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb > > > > > > > /tmp/b/odroid-c2/u-boot.dtb > > > > > > > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb > > > > > > > files into the same directory? Otherwise we may have some pain with > > > > > > > binman. > > > > > > > > > > > > What do you mean by same directory? But maybe also, what's an example of > > > > > > a board you think might end up having problems? Converting that in a > > > > > > follow-up series is likely a good idea, to highlight and address these > > > > > > issues sooner rather than later.# > > > > > > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if > > > > > this series could do the same. > > > > > > > > The kbuild infrastructure keeps the dtb alongside dts files which is > > > > the preferred way too as otherwise it would be complicated to locate > > > > DT files for the users. Also, we have to move towards Linux DT > > > > directory structure and thereby the tools like binman have to be > > > > adjusted. I will do that when I get to migrating SoCs supporting > > > > binman. > > > > > > OK, I want to stop here and rethink this. This is the path taken so > > > far, I believe: > > > > > > 1. We want to use devicetree files taken from Linux and > > > devicetree-rebasing provides these > > > > Yes. > > > > > 2. We want to use 'git subtree' to avoid needing a script to do the > > > sync / create a commit > > > > No. We want to use 'git subtree' to avoid having to use git submodules.
Well that is what I understood from Sumit, when I asked about a script. I imagine a 100-line Python script could do the same as:
git subtree pull --prefix devicetree-rebasing git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git <release-tag> --squash
and it could also put the files in the right place for U-Boot.
I've been saying in various places for years that I want to move away from arch/*/dts being where we have the "just a copy" dts files and have them somewhere else so they are easier to manage and differentiate our changes / additions. So arch/*/dts cannot be some hard-coded "right" path.
OK
> > > 3. But this leaves us with a directory structure which doesn't match > > > U-Boot (no script to fix it up) > > > > No. We intentionally abandon arch/*/dts because it's so full of > > out of date files and never fully re-synced, only re-synced ad-hoc.
I mean that the dir structure doesn't match. I am not worried about keeping arch/*/dts but I want the same structure somewhere else, e.g. dtr/arch/*/dts
And what I want here is to match the same structure everyone that's not U-Boot uses. For better or worse no one else seems to have gone with "treat aarch64 as just another ARM", and then the vendor directory structure only makes that more obviously a mismatch. We need to follow what everyone else uses, and developers familiar with other projects will expect to see.
So you are saying that U-Boot should move to what Linux uses. I agree that seems like the best approach, so let's do it.
> > > 4. So we deal with that by skipping the build rules and using CONFIG > > > options to select what is built > > > 5. So now we cannot build all the files for an SoC, just the ones that > > > are in the CONFIG options > > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't > > > have this problem > > > > No. devicetree-rebasing skips the Makefiles because they're part of the > > kernel. We couldn't re-use them ourselves because we don't have the same > > CONFIG names the kernel does. And Sumit has not replicated the logic we > > have under arch/*/dts/Makefile today because I've asked him not to, and > > we'll figure out what subsets of that logic make sense to add back in as > > a second step not a first step.
Again, you are missing my point. I am not suggesting using Linux's build rules, just explaining why Linux doesn't have the problem we would be creating here.
> > > So this is heading in the wrong direction. Nor is it clear that this > > > would just be a temporary problem. > > > > A previous iteration of this series built all of the dtb files for the > > SoC that Sumit has migrated with this series, but then dropped it.
Oh.
> > > > [snip] > > > I would like to do this series properly, maintaining the SoC-specific > > > build rules, not removing what I see as an important feature. It > > > should not be that difficult to figure out and I am happy to help with > > > it. > > > > The problem is that the rest of us do not understand the use case you're > > describing where a dtb file that would be useful in a build is not > > already in the list to build. The only one of those use cases I > > understand thus far is the exynos4 (iirc) case you mentioned previously > > where yes, really, one defconfig + appending board.dtb is fine, or fine > > enough. It's not that far off of the SPL_LOAD_FIT case, but there we > > know what to build already.
Perhaps the problem is that the rest of you think of the build as all happening in U-Boot, similar to the proposed 'make image.fit' that I am trying to add to Linux.
But packaging can be (and often is) a separate step from building. Linux has no packaging mechanism today...it just builds everything (including all DTs) and stops.
We should be able to pick up whatever .dtb files we want and use them in an image.
> > And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is > > how I see the use case you talk about being solved, if a full U-Boot is > > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this > > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't > > knnow how many modern SoCs can take a literal concatenated DTB and even > > in those cases I don't get why that's the win we want now? 1 build to N > > binaries?
Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL to use the correct DT as well, so the DT will need to be determined in TPL, perhaps.
I mean, SPL_LOAD_FIT still can handle this case, with a call to the function to re-parse the tree, when needed. I thought we did this today even, but perhaps I'm confusing my options here.
But anyway, this works OK with rk3399, for example. We need to support this use case.
Also, it is pretty easy. We just need to stick with the dir structure we have today and copy our existing Makefiles into that dir. Or change to the kernel dir structure and use that. Or do one, then the other.
I'm sorry, I don't understand what directory structure has to do with "build more dtbs". For the cases where it makes sense to, yes, we can build more dtbs, based on the SoC. I'm setting aside entirely the discussion on what SoCs that works for, for another thread.
Well you said above that we should switch to the kernel dir structure, so I believe that issue is resolved.
'build more dtbs' means build all the DTBs for an SoC, not just a selection that a particular board vendor decided on.
Yes, what other dtbs to build is the sticking point, in a number of threads now.
All of the ones for the SoC.
Yes, that's your position, and it's not anyone elses position.
Indeed, I seem to be in a minority of one.
Perhaps an issue here is that much like the kernel "install" target, we need an "install" target too, so that whatever dtbs we build can be more easily found for external packaging, but whatever tooling it is that wants it? And perhaps this is part of the problem, tooling that expects to pull things out of the object directory rather than an "installed" directory?
This is where binman comes in. It can run as part of U-Boot build, to build a few default firmware images. Then it can be run *later*, outside the U-Boot build, with an augmented or more targeted image definition, with mostly the same input files, to pull together images for specific uses. As you say, the input files need to be in a defined location, which they are today, for the most part.
So even if a particular board only uses one DT, all the DTs for that SoC are built and so can be used in that final-packaging step. Without that build, there is no way to get the required .dtb files, other than building every board one by one and then pulling out the .dtb files or something weird like that.
Note that this works independently of whether OF_LIST is used, etc.
How about this. When you introduce generic-rk3399_defconfig is when we can also have dts-$(CONFIG_ROCKCHIP_RK3399) list everything, and insist it be kept up to date. That to me feels like the right order to go in. And we can have all of the implementation details be hashed out elsewhere, not in the thread about fixing our nightmare about dts file resync.
So long as Sumit can put it back so we can use build rules, that's fine. But removing the build rules is the sticking point for me.
But it's not a sticking point for anyone else for the series. Because no one else gets the point you're trying to make.
OK
> > But even then, I don't object to adding those rules to the Makefiles. If > > it works it works. I object to adding them when they don't work.
What do you mean by 'work'? With this series as is, it simply isn't possible to add Makefile rules, as they are ignored. Am I missing something?
Yes, I think you're missing something. Perhaps you need to publish a WIP tree somewhere so someone can see what you're doing as it sounds like you're not able to add another SoC of any type on top of Sumit's tree and have it work.
The current -next source builds dtb files based on the SoC, for the most part. I sent a series to clean that up a bit[1], but it is mostly there.
Yes, and that relied on Rasmus' series having been merged ages ago which fixed up a number of "people just copypasta'd something here, incorrectly". Keep that in mind as part of why I have objections here.
OK.
And since I think you're missing the point I was raising, because no one else has the "any dtb from the SoC with this binary", we'll just be getting back to re-introducing those kind of problems with what you're demanding.
From the above it seems like the plan could be:
- Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
Makefiles accordingly
Since we're going to move everyone to being from the upstream kernel, that seems like unneeded churn.
What is the timeline for that move?
It could probably, largely, be done in 2024, for the platforms that actively sync. For the ones that aren't behaving well right now? I don't know, it'll depend on when someone shows up being active about them again.
We are talking about 1700 lines of Makefies and I already made a good start on part of it. So if we are going to be a few months with two different paths, fine, but this is going to drag on for a year, I would rather clean it up now and have a unified path for both sets of DTs.
The sticking point for migration is going to be the testing of the platforms that are not well in sync at all.
- Choose a directory target for devicetree-rebasing. I see that
'barebox' uses 'dts' which seems better to me than 'devicetree-rebasing/src/'. Actually barebox even seems to have scripts for handling all of this [2]??
They've been doing this since longer than git subtree has existed I believe. I suspect that much like how Rob would like to move the in-kernel devicetree compiler sync from a script to git subtree, barebox will too.
Maybe, although the first barebox dts/ commit was 2014 and subtree is claimed to come out in 2012...but then devicetree-rebasing might be newer, which would explain why they have 'git filter-branch' stuff in the script.
Well, it was just a guess on my part. It took a while for subtree to catch on, and yes, it's taken a while for everything to reach the state it's in today, for dts sources outside of the linux kernel itself.
I thought devicetree-rebasing came from Linux. Is it its own repo? So what is the DT upstream these days??
I'll let Rob chime in again here if he likes. In short, devicetree-rebasing is the kernel dts files/bindings copied out and tagged, matching upstream kernel tags, and with assorted useful bits of git history available.
If subtree does what we want without making U-Boot look like Franekstein's monster, that's fine. But I don't mind having a script.
Yes, everyone else thus far seems fine with what we get via this series.
- Adjust the build system to use the dts/ directory for .dts files
when OF_UPSTREAM is enabled
Then it will be easy. People can enable OF_UPSTREAM for an SoC (without changing DEFAULT_DEVICE_TREE) and will get the same behaviour as now, just with upstream .dts files. All the .dts files for an SoC are built, as now, just as Linux does. We can continue cleaning up the DT build rules as time permits.
Maybe the unasked / unanswered question here is, why don't we put the subtree in to dts/ ? Just because it would make us more likely to make changes rather than treat it as read only?
It is an easy checkpatch check, if that is your only concern.
Yeah, checkpatch isn't great for catching and stopping things. I don't know how many other custodians check their PRs before I get to them. So if it's not a fatal CI thing, it's not going to always be caught before I see it, and I don't always catch "ERROR" things in checkpatch in a PR either. But it might still be more annoying than not to have subtree be shoved in to "dts". I'm hoping for some feedback from Sumit on this point since I think he's played around.
It seems to me that the base issue here (in various threads both now and in previous months) is whether U-Boot should control over the devicetree it uses, either through managing to get schema upstream, or by having its own local pieces. That question is relevant both at build time and at runtime.
Anway, I think I have said my piece. Please go ahead with whatever you think makes sense.
I would like to continue to clean up the existing Makefile rules though.
Regards, Simon
On Tue, 2 Jan 2024 at 19:36, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Mon, Jan 1, 2024 at 4:35 PM Tom Rini trini@konsulko.com wrote:
On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
Hi Mark, Tom,
On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Sun, 31 Dec 2023 15:39:53 -0500 From: Tom Rini trini@konsulko.com
On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
Hi Sumit,
On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg sumit.garg@linaro.org wrote: > > On Fri, 29 Dec 2023 at 01:18, Simon Glass sjg@chromium.org wrote: > > > > Hi Tom, > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote: > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote: > > > > Hi Tom, Sumit, > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote: > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote: > > > > > > Hi Sumit, > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote: > > > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant > > > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > > > > > Signed-off-by: Sumit Garg sumit.garg@linaro.org > > > > > > > --- > > > > > > > > > > > > > > Changes in v3: > > > > > > > -------------- > > > > > > > - Minor commit message update > > > > > > > > > > > > > > Changes in v2: > > > > > > > -------------- > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > > > > > dts/Kconfig | 11 +++++++++++ > > > > > > > dts/Makefile | 17 ++++++++++++++--- > > > > > > > dts/arch/arm64/Makefile | 14 ++++++++++++++ > > > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > > > --- a/dts/Kconfig > > > > > > > +++ b/dts/Kconfig > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > > > enables a live tree which is available after relocation, > > > > > > > and can be adjusted as needed. > > > > > > > > > > > > > > +config OF_UPSTREAM > > > > > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > > > > > + help > > > > > > > + Traditionally, U-Boot platforms used to have their custom devicetree > > > > > > > + files or copy devicetree files from Linux kernel which are hard to > > > > > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > > > > > + option enables platforms to migrate to devicetree-rebasing repo where > > > > > > > + a regular sync will be maintained every major Linux kernel release > > > > > > > + cycle. However, platforms can still have some custom u-boot specific > > > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > > > > > My only other suggestion here is to mention that this should be set in > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > > > should be hidden, with no string for the 'bool': > > > > > > > > > > > > bool # Enable use of devicetree imported from Linux kernel release > > > > > > > > > > I think we can just keep prompting for it now, to make the transition > > > > > easier, before this option just goes away in time, hopefully. > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > > > > files when building firefly-rk3399: > > > > > > > > > > > > rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb > > > > > > rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb > > > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > > > rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb > > > > > > rk3399-ficus.dtb rk3399-nanopc-t4.dtb > > > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > > > rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb > > > > > > rk3399-rock-4c-plus.dtb > > > > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb > > > > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > > > > > > > > > Afterwards I get this: > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > So I set this manually for that one board: > > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > > > > > > > and get: > > > > > > > > > > > > make[3]: *** No rule to make target > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > > > > the DTs for rk3399, as it does today. > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to > > > > > devicetree-rebasing inside dts/... > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even > > > > with the link. > > > > > > > > Using odroid-c2 with -next I see: > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb > > > > meson-gxl-s905x-libretech-cc.dtb > > > > meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb > > > > meson-gxl-s905x-libretech-cc-v2.dtb > > > > meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb > > > > meson-gxl-s905x-p212.dtb > > > > meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb > > > > meson-gxm-gt1-ultimate.dtb > > > > meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb > > > > meson-gxm-khadas-vim2.dtb > > > > meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb > > > > meson-gxm-s912-libretech-pc.dtb > > > > meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb > > > > meson-gxm-wetek-core2.dtb > > > > meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb > > > > meson-sm1-bananapi-m2-pro.dtb > > > > meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb > > > > meson-sm1-bananapi-m5.dtb > > > > meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb > > > > meson-sm1-khadas-vim3l.dtb > > > > meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb > > > > meson-sm1-odroid-c4.dtb > > > > meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb > > > > meson-sm1-odroid-hc4.dtb > > > > meson-g12b-odroid-go-ultra.dtb > > > > meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb > > > > meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb > > > > $ > > > > With this series (sort of, since I am really not sure how to > > > > cherry-pick the commits from the PR) I see nothing: > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > > > $ > > > > > > > > This shows some of the files: > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb" > > > > /tmp/b/odroid-c2/dts/dt.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb > > > > /tmp/b/odroid-c2/u-boot.dtb > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb > > > > files into the same directory? Otherwise we may have some pain with > > > > binman. > > > > > > What do you mean by same directory? But maybe also, what's an example of > > > a board you think might end up having problems? Converting that in a > > > follow-up series is likely a good idea, to highlight and address these > > > issues sooner rather than later.# > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if > > this series could do the same. > > The kbuild infrastructure keeps the dtb alongside dts files which is > the preferred way too as otherwise it would be complicated to locate > DT files for the users. Also, we have to move towards Linux DT > directory structure and thereby the tools like binman have to be > adjusted. I will do that when I get to migrating SoCs supporting > binman.
OK, I want to stop here and rethink this. This is the path taken so far, I believe:
- We want to use devicetree files taken from Linux and
devicetree-rebasing provides these
Yes.
- We want to use 'git subtree' to avoid needing a script to do the
sync / create a commit
No. We want to use 'git subtree' to avoid having to use git submodules.
Well that is what I understood from Sumit, when I asked about a script. I imagine a 100-line Python script could do the same as:
git subtree pull --prefix devicetree-rebasing git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git <release-tag> --squash
and it could also put the files in the right place for U-Boot.
I've been saying in various places for years that I want to move away from arch/*/dts being where we have the "just a copy" dts files and have them somewhere else so they are easier to manage and differentiate our changes / additions. So arch/*/dts cannot be some hard-coded "right" path.
OK
- But this leaves us with a directory structure which doesn't match
U-Boot (no script to fix it up)
No. We intentionally abandon arch/*/dts because it's so full of out of date files and never fully re-synced, only re-synced ad-hoc.
I mean that the dir structure doesn't match. I am not worried about keeping arch/*/dts but I want the same structure somewhere else, e.g. dtr/arch/*/dts
And what I want here is to match the same structure everyone that's not U-Boot uses. For better or worse no one else seems to have gone with "treat aarch64 as just another ARM", and then the vendor directory structure only makes that more obviously a mismatch. We need to follow what everyone else uses, and developers familiar with other projects will expect to see.
So you are saying that U-Boot should move to what Linux uses. I agree that seems like the best approach, so let's do it.
- So we deal with that by skipping the build rules and using CONFIG
options to select what is built 5. So now we cannot build all the files for an SoC, just the ones that are in the CONFIG options 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't have this problem
No. devicetree-rebasing skips the Makefiles because they're part of the kernel. We couldn't re-use them ourselves because we don't have the same CONFIG names the kernel does. And Sumit has not replicated the logic we have under arch/*/dts/Makefile today because I've asked him not to, and we'll figure out what subsets of that logic make sense to add back in as a second step not a first step.
Again, you are missing my point. I am not suggesting using Linux's build rules, just explaining why Linux doesn't have the problem we would be creating here.
So this is heading in the wrong direction. Nor is it clear that this would just be a temporary problem.
A previous iteration of this series built all of the dtb files for the SoC that Sumit has migrated with this series, but then dropped it.
Oh.
[snip]
I would like to do this series properly, maintaining the SoC-specific build rules, not removing what I see as an important feature. It should not be that difficult to figure out and I am happy to help with it.
The problem is that the rest of us do not understand the use case you're describing where a dtb file that would be useful in a build is not already in the list to build. The only one of those use cases I understand thus far is the exynos4 (iirc) case you mentioned previously where yes, really, one defconfig + appending board.dtb is fine, or fine enough. It's not that far off of the SPL_LOAD_FIT case, but there we know what to build already.
Perhaps the problem is that the rest of you think of the build as all happening in U-Boot, similar to the proposed 'make image.fit' that I am trying to add to Linux.
But packaging can be (and often is) a separate step from building. Linux has no packaging mechanism today...it just builds everything (including all DTs) and stops.
We should be able to pick up whatever .dtb files we want and use them in an image.
And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is how I see the use case you talk about being solved, if a full U-Boot is generic enough for N boards, SPL_LOAD_FIT does the right thing (in this non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't knnow how many modern SoCs can take a literal concatenated DTB and even in those cases I don't get why that's the win we want now? 1 build to N binaries?
Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL to use the correct DT as well, so the DT will need to be determined in TPL, perhaps.
I mean, SPL_LOAD_FIT still can handle this case, with a call to the function to re-parse the tree, when needed. I thought we did this today even, but perhaps I'm confusing my options here.
But anyway, this works OK with rk3399, for example. We need to support this use case.
Also, it is pretty easy. We just need to stick with the dir structure we have today and copy our existing Makefiles into that dir. Or change to the kernel dir structure and use that. Or do one, then the other.
I'm sorry, I don't understand what directory structure has to do with "build more dtbs". For the cases where it makes sense to, yes, we can build more dtbs, based on the SoC. I'm setting aside entirely the discussion on what SoCs that works for, for another thread.
Well you said above that we should switch to the kernel dir structure, so I believe that issue is resolved.
'build more dtbs' means build all the DTBs for an SoC, not just a selection that a particular board vendor decided on.
Perhaps an issue here is that much like the kernel "install" target, we need an "install" target too, so that whatever dtbs we build can be more easily found for external packaging, but whatever tooling it is that wants it? And perhaps this is part of the problem, tooling that expects to pull things out of the object directory rather than an "installed" directory?
This is where binman comes in. It can run as part of U-Boot build, to build a few default firmware images. Then it can be run *later*, outside the U-Boot build, with an augmented or more targeted image definition, with mostly the same input files, to pull together images for specific uses. As you say, the input files need to be in a defined location, which they are today, for the most part.
So even if a particular board only uses one DT, all the DTs for that SoC are built and so can be used in that final-packaging step. Without that build, there is no way to get the required .dtb files, other than building every board one by one and then pulling out the .dtb files or something weird like that.
Note that this works independently of whether OF_LIST is used, etc.
But even then, I don't object to adding those rules to the Makefiles. If it works it works. I object to adding them when they don't work.
What do you mean by 'work'? With this series as is, it simply isn't possible to add Makefile rules, as they are ignored. Am I missing something?
That's not correct. Just to demonstrate this I have gone a step further to switch all Amlogic SoCs to use DT rebasing tree here [1]. As I have said before, the Makefile rules were just dropped based on Tom's feedback. However, if they really serve the existing tools from a packaging perspective I am open to migrate them as demonstrated here [2]. As before it will build all the DTBs corresponding to all the Amlogic SoCs supported in U-Boot for a single board defconfig.
[1] https://github.com/b49020/u-boot/commits/dt_for_test/ [2] https://github.com/b49020/u-boot/commit/ca5525673cdcafd71b51b48fe33c076f97a2...
Yes, I think you're missing something. Perhaps you need to publish a WIP tree somewhere so someone can see what you're doing as it sounds like you're not able to add another SoC of any type on top of Sumit's tree and have it work.
The current -next source builds dtb files based on the SoC, for the most part. I sent a series to clean that up a bit[1], but it is mostly there.
From the above it seems like the plan could be:
- Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
Makefiles accordingly
As I said before it will be a redundant effort when you can just drop them in favour of dts/arch/arm64/<vendor>/.. We just have to maintain the *-u-boot.dtsi file in arch/*/dts/.
- Choose a directory target for devicetree-rebasing. I see that
'barebox' uses 'dts' which seems better to me than 'devicetree-rebasing/src/'.
Actually as part of this patch-set we try to reuse the U-Boot 'dts' directory (via dts/arch/arm64/<vendor> soft links) since it was already taken for U-Boot specific DT Makefile. However, I am open to renaming 'devicetree-rebasing' but to me that sounds more clear that we maintain a specific subtree within U-Boot.
Actually barebox even seems to have scripts for handling all of this [2]??
That script is just doing the same thing as the DTC import script. git subtree is just another standardized way to do it.
[1] https://www.barebox.org/doc/latest/devicetree/index.html#barebox-device-tree...
- Adjust the build system to use the dts/ directory for .dts files
when OF_UPSTREAM is enabled
Then it will be easy. People can enable OF_UPSTREAM for an SoC (without changing DEFAULT_DEVICE_TREE)
I am still not sure what we will gain via keeping DEFAULT_DEVICE_TREE the same. However, without a per vendor directory Makefile like: dts/arch/arm64/<vendor>/Makefile it won't be possible. But to do that we won't be able to softlink vendor directories from DT rebasing tree but rather have to softlink every board DTS file which is much more painful.
and will get the same behaviour as now, just with upstream .dts files. All the .dts files for an SoC are built, as now, just as Linux does. We can continue cleaning up the DT build rules as time permits.
I will reiterate here, we can decide to add Makefile rules on a case by case basis. If there is a need (from packaging perspective or a particular SoC supports a generic U-Boot image) then we should be able to add them. The cleanup would be automatically part of the process as we switch SoCs to OF_UPSTREAM.
-Sumit
Regards, Simon
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=388154 [2] https://git.pengutronix.de/cgit/barebox/tree/dts
On Tue, Jan 02, 2024 at 09:07:48PM +0530, Sumit Garg wrote:
On Tue, 2 Jan 2024 at 19:36, Simon Glass sjg@chromium.org wrote:
[snip]
- Choose a directory target for devicetree-rebasing. I see that
'barebox' uses 'dts' which seems better to me than 'devicetree-rebasing/src/'.
Actually as part of this patch-set we try to reuse the U-Boot 'dts' directory (via dts/arch/arm64/<vendor> soft links) since it was already taken for U-Boot specific DT Makefile. However, I am open to renaming 'devicetree-rebasing' but to me that sounds more clear that we maintain a specific subtree within U-Boot.
Looking at what little is in dts/ here today could we just use subtree and pop the contents under there, and basically ignore the project-provided Makefile? Or is that not really worth it?
Hi Tom,
On Tue, 2 Jan 2024 at 23:36, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 02, 2024 at 09:07:48PM +0530, Sumit Garg wrote:
On Tue, 2 Jan 2024 at 19:36, Simon Glass sjg@chromium.org wrote:
[snip]
- Choose a directory target for devicetree-rebasing. I see that
'barebox' uses 'dts' which seems better to me than 'devicetree-rebasing/src/'.
Actually as part of this patch-set we try to reuse the U-Boot 'dts' directory (via dts/arch/arm64/<vendor> soft links) since it was already taken for U-Boot specific DT Makefile. However, I am open to renaming 'devicetree-rebasing' but to me that sounds more clear that we maintain a specific subtree within U-Boot.
Looking at what little is in dts/ here today could we just use subtree and pop the contents under there, and basically ignore the project-provided Makefile? Or is that not really worth it?
If we really want to avoid soft links then I did try to add the subree with the prefix as dts/upstream here [1]. It works well with the downside that we will pollute the subtree source code with U-Boot specific Makefiles [2]. However, the subtree pull works fine still. If this sounds better to you and Simon then let me know I will use this approach for v4.
[1] https://github.com/b49020/u-boot/commits/use_dts_dir/ [2] https://github.com/b49020/u-boot/commit/90eabe614e77bc30a437e7d5559c1ac414ac...
-Sumit
-- Tom
On Wed, Jan 03, 2024 at 12:27:24PM +0530, Sumit Garg wrote:
Hi Tom,
On Tue, 2 Jan 2024 at 23:36, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 02, 2024 at 09:07:48PM +0530, Sumit Garg wrote:
On Tue, 2 Jan 2024 at 19:36, Simon Glass sjg@chromium.org wrote:
[snip]
- Choose a directory target for devicetree-rebasing. I see that
'barebox' uses 'dts' which seems better to me than 'devicetree-rebasing/src/'.
Actually as part of this patch-set we try to reuse the U-Boot 'dts' directory (via dts/arch/arm64/<vendor> soft links) since it was already taken for U-Boot specific DT Makefile. However, I am open to renaming 'devicetree-rebasing' but to me that sounds more clear that we maintain a specific subtree within U-Boot.
Looking at what little is in dts/ here today could we just use subtree and pop the contents under there, and basically ignore the project-provided Makefile? Or is that not really worth it?
If we really want to avoid soft links then I did try to add the subree with the prefix as dts/upstream here [1]. It works well with the downside that we will pollute the subtree source code with U-Boot specific Makefiles [2]. However, the subtree pull works fine still. If this sounds better to you and Simon then let me know I will use this approach for v4.
[1] https://github.com/b49020/u-boot/commits/use_dts_dir/ [2] https://github.com/b49020/u-boot/commit/90eabe614e77bc30a437e7d5559c1ac414ac...
I think the symlink stuff was part of what was making it more confusing to add new SoCs to OF_UPSTREAM so yes this looks good to me, and I appreciate the demo commit showing an update is still easy. Thanks!
On Tue, 2 Jan 2024 at 21:07, Sumit Garg sumit.garg@linaro.org wrote:
On Tue, 2 Jan 2024 at 19:36, Simon Glass sjg@chromium.org wrote:
<snip>
- Adjust the build system to use the dts/ directory for .dts files
when OF_UPSTREAM is enabled
Then it will be easy. People can enable OF_UPSTREAM for an SoC (without changing DEFAULT_DEVICE_TREE)
I am still not sure what we will gain via keeping DEFAULT_DEVICE_TREE the same. However, without a per vendor directory Makefile like: dts/arch/arm64/<vendor>/Makefile it won't be possible. But to do that we won't be able to softlink vendor directories from DT rebasing tree but rather have to softlink every board DTS file which is much more painful.
Even after this you have to tell <vendor> name via DEFAULT_DEVICE_TREE because the DTB path is constructed via:
DEVICE_TREE ?= $(CONFIG_DEFAULT_DEVICE_TREE:"%"=%) ifeq ($(DEVICE_TREE),) DEVICE_TREE := unset endif
ifeq ($(CONFIG_OF_UPSTREAM),y) ifeq ($(CONFIG_ARM64),y) dt_dir := dts/arch/arm64 else dt_dir := dts/arch/$(ARCH) endif else dt_dir := arch/$(ARCH)/dts endif
ifneq ($(EXT_DTB),) DTB := $(EXT_DTB) else DTB := $(dt_dir)/$(DEVICE_TREE).dtb endif
So with a move to Linux directory structure for dts directory, DEFAULT_DEVICE_TREE have to specify <vendor>/<name> as DT filename.
-Sumit
and will get the same behaviour as now, just with upstream .dts files. All the .dts files for an SoC are built, as now, just as Linux does. We can continue cleaning up the DT build rules as time permits.
I will reiterate here, we can decide to add Makefile rules on a case by case basis. If there is a need (from packaging perspective or a particular SoC supports a generic U-Boot image) then we should be able to add them. The cleanup would be automatically part of the process as we switch SoCs to OF_UPSTREAM.
-Sumit
Regards, Simon
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=388154 [2] https://git.pengutronix.de/cgit/barebox/tree/dts
[snip]
However, I am very much in favour of having a generalized U-Boot image. This might become true in some cases like U-Boot acts as a second stage bootloader for a particular SoC which is a unified image where the prior stage passes the DT to it. The Qcom effort in this direction can be an example here.
Not relevant to the topic at hand, perhaps, but Qualcomm uses a closed-source blob to jump to U-Boot and is certainly not an example we should emulate. But yes, passing a DT to U-Boot proper can be useful.
Just to chime in here, this limitation is true for production Qualcomm devices where all of the bootloader blobs are signed by the OEM (true for most phones). But for development platforms we can do better. I expect this is a topic we will keep on coming back to, so I'd like to just take the time to explain some of the technical details on Qualcomm platforms, as there is a lot more nuance than you might be aware of.
The modern Qualcomm boot chain is (roughly) PBL (bootrom) -> TZ/el3 -> sbl1 (secondary bootloader) -> hypervisor -> XBL_Core (UEFI impl) -> ABL (LinuxLoader.efi app) -> Linux
On production devices the best we can do is replace "Linux" with U-Boot, and if we're lucky then we can leverage features of ABL to simplify things like DTB selection (it supports picking from a bunch of concatenated DTBs, but we can just as easily implement some similar feature in U-Boot ourselves).
On a development board I have been successful in replacing the hypervisor with a stub and replacing XBL_Core with U-Boot - giving us EL2 and removing the entire proprietary UEFI stack. There is no reason that we can't go further than this.
The Qualcomm Chromebooks all run Coreboot, for sure on those it would be possible to use U-Boot much earlier (although there is still the proprietary XBL_Sec TZ blob).
The Dragonboard410c (and MSM8916 SoC overall) has been pretty much entirely ripped open thanks to Stephan Gerhold and the msm8916-mainline project. On these devices it is easily possible to run U-Boot as a first-stage bootloader (at least to the same extent one can on the more open ARM platforms, or even more open if you wish). Although the bootloader of choice for most of these devices is a home-grown fork of lk.
For new SoCs, with the number of Qualcomm devices out there, and communities like postmarketOS enabling support on so many of them... My hope is that we will quickly see phones being the most common Qualcomm devices supported by U-Boot. While it is indeed extremely unfortunate that we can't replace the bootloader entirely, using U-Boot as a fresh slate is still extremely liberating (EFI! Firmware updates! No need for distro hacks to update the kernel! Multi-boot! etc...). I wish we could focus more on how U-Boot will make supporting Linux on these devices SO SO much easier, and less on how broken the (usually impossible to modify) bootloader they shipped with is.
While almost all of the boot chain I explained above is proprietary, the ABL source code is publicly available (although most device vendors don't publish their modified production version, I suppose for fear of embarrassment). The statement "Qualcomm uses a closed-source blob to jump to U-Boot" is at the very least an oversimplification.
To be contrarian, here is an example of a phone vendor who do publish their ABL source code, here is the code that runs Linux (or U-Boot in our case).
https://github.com/SHIFTPHONES/android_bootable_bootloader_edk2/blob/sos-3.x...
My point is, there is a lot of nuance and complexity here, and we need to be careful about what exactly we're referring to.
Kind regards, Caleb
It's a very valid use case we need to continue to support. And to save Mark from having to repeat himself, again, it's intentionally and not changing, how the Apple M1/M2/etc platforms boot. I'm pretty sure the fact that one can use U-Boot this way is part of how engineers get proof of concept work done to show that if they had U-Boot available then they could also support X/Y/Z easier. And maybe they'll be able to longer term push internally to use bloblist to pass things along.
Heck, trying to not go too far off on a tangent, maybe the m1n1 loader can implement both conventions, as both Linux Kernel[0] and Bloblist[1] use x0 for device tree, but bloblist has x1 non-zero and Linux does not, so both could be present here? Or is there some incompatibility I don't see on quick skimming?
Right. Some time ago I suggested Simon to lobby the Linux kernel folks to change the arm64 Linux kernel entry convention to state that x1 can be non-zero in which case it points at a bloblist. If that happened I'd probably do the work to make m1n1 pass a bloblist. And it would probably make the folks who want to directly boot a Linux kernel from TF-A (without going through U-Boot) happy as well.
I got a lot of push-back on that. Perhaps there might be some willingness if it is explained that Linux doesn't need to understand the bloblist, just tolerate it being there. There are probably other people who will be more successful at pushing for kernel changes.
As you know, the handoff protocol is designed such that you don't need to decode the bloblist to find the devicetree. BTW I would like to put the ACPI/SMBIOS tables in the bloblist as well (with EFI we would provide pointers into the bloblist for Linux to use)
Regards, Simon
Hi Caleb,
On Tue, Jan 2, 2024 at 5:51 AM Caleb Connolly caleb.connolly@linaro.org wrote:
[snip]
However, I am very much in favour of having a generalized U-Boot image. This might become true in some cases like U-Boot acts as a second stage bootloader for a particular SoC which is a unified image where the prior stage passes the DT to it. The Qcom effort in this direction can be an example here.
Not relevant to the topic at hand, perhaps, but Qualcomm uses a closed-source blob to jump to U-Boot and is certainly not an example we should emulate. But yes, passing a DT to U-Boot proper can be useful.
Just to chime in here, this limitation is true for production Qualcomm devices where all of the bootloader blobs are signed by the OEM (true for most phones). But for development platforms we can do better. I expect this is a topic we will keep on coming back to, so I'd like to just take the time to explain some of the technical details on Qualcomm platforms, as there is a lot more nuance than you might be aware of.
The modern Qualcomm boot chain is (roughly) PBL (bootrom) -> TZ/el3 -> sbl1 (secondary bootloader) -> hypervisor -> XBL_Core (UEFI impl) -> ABL (LinuxLoader.efi app) -> Linux
On production devices the best we can do is replace "Linux" with U-Boot, and if we're lucky then we can leverage features of ABL to simplify things like DTB selection (it supports picking from a bunch of concatenated DTBs, but we can just as easily implement some similar feature in U-Boot ourselves).
On a development board I have been successful in replacing the hypervisor with a stub and replacing XBL_Core with U-Boot - giving us EL2 and removing the entire proprietary UEFI stack. There is no reason that we can't go further than this.
The Qualcomm Chromebooks all run Coreboot, for sure on those it would be possible to use U-Boot much earlier (although there is still the proprietary XBL_Sec TZ blob).
The Dragonboard410c (and MSM8916 SoC overall) has been pretty much entirely ripped open thanks to Stephan Gerhold and the msm8916-mainline project. On these devices it is easily possible to run U-Boot as a first-stage bootloader (at least to the same extent one can on the more open ARM platforms, or even more open if you wish). Although the bootloader of choice for most of these devices is a home-grown fork of lk.
For new SoCs, with the number of Qualcomm devices out there, and communities like postmarketOS enabling support on so many of them... My hope is that we will quickly see phones being the most common Qualcomm devices supported by U-Boot. While it is indeed extremely unfortunate that we can't replace the bootloader entirely, using U-Boot as a fresh slate is still extremely liberating (EFI! Firmware updates! No need for distro hacks to update the kernel! Multi-boot! etc...). I wish we could focus more on how U-Boot will make supporting Linux on these devices SO SO much easier, and less on how broken the (usually impossible to modify) bootloader they shipped with is.
While almost all of the boot chain I explained above is proprietary, the ABL source code is publicly available (although most device vendors don't publish their modified production version, I suppose for fear of embarrassment). The statement "Qualcomm uses a closed-source blob to jump to U-Boot" is at the very least an oversimplification.
To be contrarian, here is an example of a phone vendor who do publish their ABL source code, here is the code that runs Linux (or U-Boot in our case).
https://github.com/SHIFTPHONES/android_bootable_bootloader_edk2/blob/sos-3.x...
My point is, there is a lot of nuance and complexity here, and we need to be careful about what exactly we're referring to.
Thank you very much for the information, it is a great read. Yes my comment was wide of the mark and I am pleased to hear it.
BTW, I would very much like to see Linaro ensuring that new 96boards have open source firmware before they are released. Before release seems to be the only time that the vendor can devote time to it.
Regards, Simon
Hi Simon,
On Thu, 28 Dec 2023 at 20:39, Simon Glass sjg@chromium.org wrote:
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Minor commit message update
Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-Boot platforms used to have their custom devicetreefiles or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel releaseI think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
I went ahead to debug this rk3399 issue. It turned out to be a subtle Makefile dependency corner case that I missed in v3. Following change should fix the issue, I will incorporate it in v4. However, while switching rk3399 to upstream DT I noticed many gaps from upstream DT, one that occured to me was difference in clk id SCLK_DDRCLK (U-Boot) vs SCLK_DDRC (upstream DT).
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index bdc1da43e7a..9526eb073f1 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -358,7 +359,7 @@ ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE dtsi_include_list += $(capsule_esl_dtsi) endif
-dtsi_include_list_deps = $(addprefix $(obj)/,$(subst $(quote),,$(dtsi_include_list))) +dtsi_include_list_deps = $(addprefix $(u_boot_dtsi_loc)/,$(subst $(quote),,$(dtsi_include_list)))
ifneq ($(CHECK_DTBS),) DT_CHECKER ?= dt-validate
-Sumit
Encourage SoC/board maintainers to migrate to using devicetree-rebasing subtree and maintain a regular sync with Linux kernel devicetree files and bindings.
Along with that add documentation regarding how to run DT bindings schema checks.
Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v3: -------------- - Replace CONFIG_* with Kconfig options
Changes in v2: -------------- - s/U-boot/U-Boot/
doc/develop/devicetree/control.rst | 131 +++++++++++++++++++++-------- 1 file changed, 96 insertions(+), 35 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index cbb65c9b177..65180d33e8d 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -1,5 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0+ .. sectionauthor:: Copyright 2011 The Chromium OS Authors +.. Copyright 2023 Linaro Ltd.
Devicetree Control in U-Boot ============================ @@ -22,14 +23,13 @@ for three reasons: hierarchical format - It is fairly efficient to read incrementally
-The arch/<arch>/dts directories contains a Makefile for building the devicetree -blob and embedding it in the U-Boot image. This is useful since it allows -U-Boot to configure itself according to what it finds there. If you have -a number of similar boards with different peripherals, you can describe -the features of each board in the devicetree file, and have a single -generic source base. +The U-Boot Makefile infrastructure allows for building the devicetree blob +and embedding it in the U-Boot image. This is useful since it allows U-Boot +to configure itself according to what it finds there. If you have a number +of similar boards with different peripherals, you can describe the features +of each board in the devicetree file, and have a single generic source base.
-To enable this feature, add CONFIG_OF_CONTROL to your board config file. +To enable this feature, select `OF_CONTROL` via Kconfig.
What is a Flattened Devicetree? @@ -68,8 +68,21 @@ a binary file. U-Boot adds its own `fdtgrep` for creating subsets of the file. Where do I get a devicetree file for my board? ----------------------------------------------
-You may find that the Linux kernel has a suitable file. Look in the -kernel source in arch/<arch>/boot/dts. +Linux kernel Git repository has been the place where devicetree files along +with devicetree bindings are stored and maintained. There is devicetee-rebasing +(dtrepo_) which maintains a forked copy of devicetree files along with bindings +at every Linux kernel major release or intermideate release candidates. + +In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows:: + + git subtree pull --prefix devicetree-rebasing \ + git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ + <release-tag> --squash + +You may find that the `devicetee-rebasing/` sub-directory has a suitable +devicetree file for your board. Look in `devicetree-rebasing/src/<arch>/`.
If not you might find other boards with suitable files that you can modify to your needs. Look in the board directories for files with a @@ -81,34 +94,34 @@ Failing that, you could write one from scratch yourself! Configuration -------------
-Use:: +Traditionally, U-Boot placed copies of devicetree source files from Linux +kernel into `arch/<arch>/dts/<name>.dts` which can be selected via setting +"<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig.
- #define CONFIG_DEFAULT_DEVICE_TREE "<name>" +However, it has become combersome over time for each SoC/board maintainer to +keep devicetree files in sync with Linux kernel. Thereby, SoC/board maintainers +are encouraged to migrate to use mirrored copies from `devicetree-rebasing/` +into `dts/arch/<arch>/<vendor>`. To do that enable `OF_UPSTREAM` via Kconfig and +set up "<vendor>/<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig.
-to set the filename of the devicetree source. Then put your devicetree -file into:: +This should include your CPU or SOC's devicetree file. On top of that any U-Boot +specific tweaks (see: dttweaks_) can be made for your board.
- arch/<arch>/dts/<name>.dts - -This should include your CPU or SOC's devicetree file, placed in -`arch/<arch>/dts`, and then make any adjustments required using a u-boot-dtsi -file for your board. - -If CONFIG_OF_EMBED is defined, then it will be picked up and built into +If `OF_EMBED` is selected by Kconfig, then it will be picked up and built into the U-Boot image (including u-boot.bin). This is suitable for debugging and development only and is not recommended for production devices.
-If CONFIG_OF_SEPARATE is defined, then it will be built and placed in +If `OF_SEPARATE` is selected by Kconfig, then it will be built and placed in a u-boot.dtb file alongside u-boot-nodtb.bin with the combined result placed -in u-boot.bin so you can still just flash u-boot.bin onto your board. If you are -using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device -tree binary. +in u-boot.bin so you can still just flash u-boot.bin onto your board. If Kconfig +option `SPL_FRAMEWORK` is enabled, then u-boot.img will be built to include the +device tree binary.
-If CONFIG_OF_BOARD is defined, a board-specific routine will provide the +If `OF_BOARD` is selected by Kconfig, a board-specific routine will provide the devicetree at runtime, for example if an earlier bootloader stage creates it and passes it to U-Boot.
-If CONFIG_SANDBOX is defined, then it will be read from a file on +If `SANDBOX` is selected by Kconfig, then it will be read from a file on startup. Use the -d flag to U-Boot to specify the file to read, -D for the default and -T for the test devicetree, used to run sandbox unit tests.
@@ -142,7 +155,7 @@ Build: After the board configuration is done, fdt supported u-boot can be built in two ways:
-# build the default dts which is defined from CONFIG_DEFAULT_DEVICE_TREE:: +# build the default dts which is selected by DEFAULT_DEVICE_TREE Kconfig::
$ make
@@ -156,8 +169,9 @@ ways: Adding tweaks for U-Boot ------------------------
-It is strongly recommended that devicetree files in U-Boot are an exact copy of -those in Linux, so that it is easy to sync them up from time to time. +With devicetee-rebasing Git subtree, it is ensured that devicetree files in +U-Boot are an exact copy of those in Linux kernel via mirroring into +`dts/arch/<arch>/<vendor>`.
U-Boot is of course a very different project from Linux, e.g. it operates under much more restrictive memory and code-size constraints. Where Linux may use a @@ -170,8 +184,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 the same directory as the -main file, in this order:: +devicetree for your board, searching for them in `arch/<arch>/dts/` in this +order::
<orig_filename>-u-boot.dtsi <CONFIG_SYS_SOC>-u-boot.dtsi @@ -195,11 +209,57 @@ As mentioned above, the U-Boot build system automatically includes a `*-u-boot.dtsi` file, if found, containing U-Boot specific quirks. However, some data, such as the mentioned public keys, are not appropriate for upstream U-Boot but are better kept and maintained -outside the U-Boot repository. You can use CONFIG_DEVICE_TREE_INCLUDES -to specify a list of .dtsi files that will also be included when +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.
+Devicetree bindings schema checks +--------------------------------- + +With devicetee-rebasing Git subtree, the devicetree bindings are also regularly +synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This +allows U-Boot to run devicetree bindings schema checks which will bring +compliance to U-Boot core/drivers regarding usage of devicetree. + +Dependencies +~~~~~~~~~~~~ + +The DT schema project must be installed in order to validate the DT schema +binding documents and validate DTS files using the DT schema. The DT schema +project can be installed with pip:: + + pip3 install dtschema + +Note that 'dtschema' installation requires 'swig' and Python development files +installed first. On Debian/Ubuntu systems:: + + apt install swig python3-dev + +Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be +installed. Ensure they are in your PATH (~/.local/bin by default). + +Recommended is also to install yamllint (used by dtschema when present). + +Running checks +~~~~~~~~~~~~~~ + +In order to perform validation of DTB files, use the ``dtbs_check`` target:: + + make dtbs_check + +It is also possible to run checks with a subset of matching schema files by +setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or +patterns (partial match of a fixed string). Each file or pattern should be +separated by ':'. + +:: + + make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml + make dtbs_check DT_SCHEMA_FILES=/gpio/ + make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml + + Relocation, SPL and TPL -----------------------
@@ -261,8 +321,9 @@ used it before Linux (e.g. snow). The two projects developed in parallel and there are still some differences in the bindings for certain boards. While there has been discussion of having a separate repository for devicetree files, in practice the Linux kernel Git repository has become the place where -these are stored, with U-Boot taking copies and adding tweaks with u-boot.dtsi -files. +these are stored, with U-Boot taking copies via devicetree-rebasing repo +(see: dtrepo_) and adding tweaks with u-boot.dtsi files.
.. _dtspec: https://www.devicetree.org/specifications/ .. _dtlist: https://www.spinics.net/lists/devicetree-compiler/ +.. _dtrepo: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
On Thu, Dec 28, 2023 at 05:28:01PM +0530, Sumit Garg wrote:
Encourage SoC/board maintainers to migrate to using devicetree-rebasing subtree and maintain a regular sync with Linux kernel devicetree files and bindings.
Along with that add documentation regarding how to run DT bindings schema checks.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Thanks for the related cleanups in there.
Reviewed-by: Tom Rini trini@konsulko.com
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote:
Encourage SoC/board maintainers to migrate to using devicetree-rebasing subtree and maintain a regular sync with Linux kernel devicetree files and bindings.
Along with that add documentation regarding how to run DT bindings schema checks.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Replace CONFIG_* with Kconfig options
Changes in v2:
- s/U-boot/U-Boot/
doc/develop/devicetree/control.rst | 131 +++++++++++++++++++++-------- 1 file changed, 96 insertions(+), 35 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index cbb65c9b177..65180d33e8d 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -1,5 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0+ .. sectionauthor:: Copyright 2011 The Chromium OS Authors +.. Copyright 2023 Linaro Ltd.
Devicetree Control in U-Boot
@@ -22,14 +23,13 @@ for three reasons: hierarchical format
- It is fairly efficient to read incrementally
-The arch/<arch>/dts directories contains a Makefile for building the devicetree -blob and embedding it in the U-Boot image. This is useful since it allows -U-Boot to configure itself according to what it finds there. If you have -a number of similar boards with different peripherals, you can describe -the features of each board in the devicetree file, and have a single -generic source base. +The U-Boot Makefile infrastructure allows for building the devicetree blob +and embedding it in the U-Boot image. This is useful since it allows U-Boot +to configure itself according to what it finds there. If you have a number +of similar boards with different peripherals, you can describe the features +of each board in the devicetree file, and have a single generic source base.
-To enable this feature, add CONFIG_OF_CONTROL to your board config file. +To enable this feature, select `OF_CONTROL` via Kconfig.
These changes to remove CONFIG_ are good, but I think they should be in a separate, prior patch.
What is a Flattened Devicetree? @@ -68,8 +68,21 @@ a binary file. U-Boot adds its own `fdtgrep` for creating subsets of the file. Where do I get a devicetree file for my board?
-You may find that the Linux kernel has a suitable file. Look in the -kernel source in arch/<arch>/boot/dts. +Linux kernel Git repository has been the place where devicetree files along +with devicetree bindings are stored and maintained. There is devicetee-rebasing +(dtrepo_) which maintains a forked copy of devicetree files along with bindings +at every Linux kernel major release or intermideate release candidates.
+In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squash
This is an internal detail and I believe it will confuse people. Can you put this in a section like 'Resyncing with devicetree-rebasing' and explain when this might be needed?...almost enver, right?
+You may find that the `devicetee-rebasing/` sub-directory has a suitable +devicetree file for your board. Look in `devicetree-rebasing/src/<arch>/`.
If not you might find other boards with suitable files that you can modify to your needs. Look in the board directories for files with a @@ -81,34 +94,34 @@ Failing that, you could write one from scratch yourself! Configuration
-Use:: +Traditionally, U-Boot placed copies of devicetree source files from Linux +kernel into `arch/<arch>/dts/<name>.dts` which can be selected via setting +"<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig.
- #define CONFIG_DEFAULT_DEVICE_TREE "<name>"
+However, it has become combersome over time for each SoC/board maintainer to
spelling
+keep devicetree files in sync with Linux kernel. Thereby, SoC/board maintainers
s/Thereby/Therefore/
+are encouraged to migrate to use mirrored copies from `devicetree-rebasing/` +into `dts/arch/<arch>/<vendor>`. To do that enable `OF_UPSTREAM` via Kconfig
for the SoC being used
and +set up "<vendor>/<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig.
-to set the filename of the devicetree source. Then put your devicetree -file into:: +This should include your CPU or SOC's devicetree file. On top of that any U-Boot +specific tweaks (see: dttweaks_) can be made for your board.
- arch/<arch>/dts/<name>.dts
-This should include your CPU or SOC's devicetree file, placed in -`arch/<arch>/dts`, and then make any adjustments required using a u-boot-dtsi -file for your board.
-If CONFIG_OF_EMBED is defined, then it will be picked up and built into +If `OF_EMBED` is selected by Kconfig, then it will be picked up and built into the U-Boot image (including u-boot.bin). This is suitable for debugging and development only and is not recommended for production devices.
-If CONFIG_OF_SEPARATE is defined, then it will be built and placed in +If `OF_SEPARATE` is selected by Kconfig, then it will be built and placed in a u-boot.dtb file alongside u-boot-nodtb.bin with the combined result placed -in u-boot.bin so you can still just flash u-boot.bin onto your board. If you are -using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device -tree binary. +in u-boot.bin so you can still just flash u-boot.bin onto your board. If Kconfig +option `SPL_FRAMEWORK` is enabled, then u-boot.img will be built to include the +device tree binary.
-If CONFIG_OF_BOARD is defined, a board-specific routine will provide the +If `OF_BOARD` is selected by Kconfig, a board-specific routine will provide the devicetree at runtime, for example if an earlier bootloader stage creates it and passes it to U-Boot.
-If CONFIG_SANDBOX is defined, then it will be read from a file on +If `SANDBOX` is selected by Kconfig, then it will be read from a file on startup. Use the -d flag to U-Boot to specify the file to read, -D for the default and -T for the test devicetree, used to run sandbox unit tests.
As above, please move the CONFIG changes into a prior patch.
@@ -142,7 +155,7 @@ Build: After the board configuration is done, fdt supported u-boot can be built in two ways:
-# build the default dts which is defined from CONFIG_DEFAULT_DEVICE_TREE:: +# build the default dts which is selected by DEFAULT_DEVICE_TREE Kconfig::
$ make@@ -156,8 +169,9 @@ ways: Adding tweaks for U-Boot
-It is strongly recommended that devicetree files in U-Boot are an exact copy of -those in Linux, so that it is easy to sync them up from time to time. +With devicetee-rebasing Git subtree, it is ensured that devicetree files in +U-Boot are an exact copy of those in Linux kernel via mirroring into +`dts/arch/<arch>/<vendor>`.
U-Boot is of course a very different project from Linux, e.g. it operates under much more restrictive memory and code-size constraints. Where Linux may use a @@ -170,8 +184,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 the same directory as the -main file, in this order:: +devicetree for your board, searching for them in `arch/<arch>/dts/` in this +order::
<orig_filename>-u-boot.dtsi <CONFIG_SYS_SOC>-u-boot.dtsi@@ -195,11 +209,57 @@ As mentioned above, the U-Boot build system automatically includes a `*-u-boot.dtsi` file, if found, containing U-Boot specific quirks. However, some data, such as the mentioned public keys, are not appropriate for upstream U-Boot but are better kept and maintained -outside the U-Boot repository. You can use CONFIG_DEVICE_TREE_INCLUDES -to specify a list of .dtsi files that will also be included when +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.
+Devicetree bindings schema checks +---------------------------------
+With devicetee-rebasing Git subtree, the devicetree bindings are also regularly +synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This +allows U-Boot to run devicetree bindings schema checks which will bring +compliance to U-Boot core/drivers regarding usage of devicetree.
+Dependencies +~~~~~~~~~~~~
+The DT schema project must be installed in order to validate the DT schema +binding documents and validate DTS files using the DT schema. The DT schema +project can be installed with pip::
- pip3 install dtschema
+Note that 'dtschema' installation requires 'swig' and Python development files +installed first. On Debian/Ubuntu systems::
- apt install swig python3-dev
These two are already in doc/build/gcc.rst so please reference that here, rather than repeating it.
+Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be +installed. Ensure they are in your PATH (~/.local/bin by default).
+Recommended is also to install yamllint (used by dtschema when present).
How?
+Running checks +~~~~~~~~~~~~~~
+In order to perform validation of DTB files, use the ``dtbs_check`` target::
- make dtbs_check
+It is also possible to run checks with a subset of matching schema files by +setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or +patterns (partial match of a fixed string). Each file or pattern should be +separated by ':'.
+::
- make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml
- make dtbs_check DT_SCHEMA_FILES=/gpio/
- make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml
Relocation, SPL and TPL
@@ -261,8 +321,9 @@ used it before Linux (e.g. snow). The two projects developed in parallel and there are still some differences in the bindings for certain boards. While there has been discussion of having a separate repository for devicetree files, in practice the Linux kernel Git repository has become the place where -these are stored, with U-Boot taking copies and adding tweaks with u-boot.dtsi -files. +these are stored, with U-Boot taking copies via devicetree-rebasing repo +(see: dtrepo_) and adding tweaks with u-boot.dtsi files.
.. _dtspec: https://www.devicetree.org/specifications/ .. _dtlist: https://www.spinics.net/lists/devicetree-compiler/
+.. _dtrepo: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
2.34.1
Regards, Simon
On Thu, Dec 28, 2023 at 01:37:09PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote:
[snip]
@@ -68,8 +68,21 @@ a binary file. U-Boot adds its own `fdtgrep` for creating subsets of the file. Where do I get a devicetree file for my board?
-You may find that the Linux kernel has a suitable file. Look in the -kernel source in arch/<arch>/boot/dts. +Linux kernel Git repository has been the place where devicetree files along +with devicetree bindings are stored and maintained. There is devicetee-rebasing +(dtrepo_) which maintains a forked copy of devicetree files along with bindings +at every Linux kernel major release or intermideate release candidates.
+In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squashThis is an internal detail and I believe it will confuse people. Can you put this in a section like 'Resyncing with devicetree-rebasing' and explain when this might be needed?...almost enver, right?
I think this means the wording and sections need to be clearer, in the document. It's unlikely most users would need this (but I can see downstream cases), but I need to do this at least once a U-Boot release cycle, and I want to make sure it's documented on how to do it.
On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote:
Encourage SoC/board maintainers to migrate to using devicetree-rebasing subtree and maintain a regular sync with Linux kernel devicetree files and bindings.
Along with that add documentation regarding how to run DT bindings schema checks.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Replace CONFIG_* with Kconfig options
Changes in v2:
- s/U-boot/U-Boot/
doc/develop/devicetree/control.rst | 131 +++++++++++++++++++++-------- 1 file changed, 96 insertions(+), 35 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index cbb65c9b177..65180d33e8d 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -1,5 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0+ .. sectionauthor:: Copyright 2011 The Chromium OS Authors +.. Copyright 2023 Linaro Ltd.
Devicetree Control in U-Boot
@@ -22,14 +23,13 @@ for three reasons: hierarchical format
- It is fairly efficient to read incrementally
-The arch/<arch>/dts directories contains a Makefile for building the devicetree -blob and embedding it in the U-Boot image. This is useful since it allows -U-Boot to configure itself according to what it finds there. If you have -a number of similar boards with different peripherals, you can describe -the features of each board in the devicetree file, and have a single -generic source base. +The U-Boot Makefile infrastructure allows for building the devicetree blob +and embedding it in the U-Boot image. This is useful since it allows U-Boot +to configure itself according to what it finds there. If you have a number +of similar boards with different peripherals, you can describe the features +of each board in the devicetree file, and have a single generic source base.
-To enable this feature, add CONFIG_OF_CONTROL to your board config file. +To enable this feature, select `OF_CONTROL` via Kconfig.
What is a Flattened Devicetree? @@ -68,8 +68,21 @@ a binary file. U-Boot adds its own `fdtgrep` for creating subsets of the file. Where do I get a devicetree file for my board?
-You may find that the Linux kernel has a suitable file. Look in the -kernel source in arch/<arch>/boot/dts. +Linux kernel Git repository has been the place where devicetree files along +with devicetree bindings are stored and maintained. There is devicetee-rebasing +(dtrepo_) which maintains a forked copy of devicetree files along with bindings +at every Linux kernel major release or intermideate release candidates.
Typo.
+In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
I would suggest dropping "-rebasing" in the u-boot tree. (I wish we had in the original repo). I don't think it's relevant.
We're not likely to regenerate the tree, but any clue what 'git subtree pull' would do in this case? It could happen if we switched to git-filter-repo.
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squash
I'd put this in a script to run. Documentation tends to be not quite correct. A script could also be smarter and figure out <release-tag>.
+You may find that the `devicetee-rebasing/` sub-directory has a suitable +devicetree file for your board. Look in `devicetree-rebasing/src/<arch>/`.
On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote:
On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote:
[snip]
+In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
I would suggest dropping "-rebasing" in the u-boot tree. (I wish we had in the original repo). I don't think it's relevant.
We're not likely to regenerate the tree, but any clue what 'git subtree pull' would do in this case? It could happen if we switched to git-filter-repo.
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squashI'd put this in a script to run. Documentation tends to be not quite correct. A script could also be smarter and figure out <release-tag>.
Since you had mentioned elsewhere moving the kernel scripts/dtc/ to something using subtree, I do hope to learn some lessons from what you do there. The first thing is that given the size/nature of the commits, I had figured I'd be the one doing this as a subtree pull+squash then push, rather than posting to the ML since it'll be huge and un-reviewable, but with a note sent off to the ML that people should be aware the next sync has been done and retest as needed. But Sumit, were you planning to do some of this instead? The second thing is that if we move the subtree part in to dts/ instead (where we will still have the Makefile/Kconfig we have today and then our Makefiles within the directories, this might get more complex and so really require a script to keep it from getting error prone?
On Wed, 3 Jan 2024 at 22:02, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote:
On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote:
[snip]
+In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
I would suggest dropping "-rebasing" in the u-boot tree. (I wish we had in the original repo). I don't think it's relevant.
Sure, as Tom pointed out below that we would shift to put subtree as dts/upstream for v4. Does that make sense to you?
We're not likely to regenerate the tree, but any clue what 'git subtree pull' would do in this case? It could happen if we switched to git-filter-repo.
Yeah we just need to modify the prefix as:
git subtree pull --prefix dts/upstream \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squashI'd put this in a script to run. Documentation tends to be not quite correct. A script could also be smarter and figure out <release-tag>.
Sure, I will do that for v4.
Since you had mentioned elsewhere moving the kernel scripts/dtc/ to something using subtree, I do hope to learn some lessons from what you do there. The first thing is that given the size/nature of the commits, I had figured I'd be the one doing this as a subtree pull+squash then push, rather than posting to the ML since it'll be huge and un-reviewable, but with a note sent off to the ML that people should be aware the next sync has been done and retest as needed. But Sumit, were you planning to do some of this instead?
I am happy for you to do that. I am happy to assist in case any conflicts occur.
The second thing is that if we move the subtree part in to dts/ instead (where we will still have the Makefile/Kconfig we have today and then our Makefiles within the directories, this might get more complex and so really require a script to keep it from getting error prone?
IMO, we should give subtree a try and later if it becomes complex to manage then we can switch to a custom script as well. It is essentially a sub-directory which we start initially to manage via a subtree approach but later we can switch to a custom script to sync that subdirectory if there is a need.
-Sumit
-- Tom
On 1/3/24 17:32, Tom Rini wrote:
On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote:
On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote:
[snip]
+In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
I would suggest dropping "-rebasing" in the u-boot tree. (I wish we had in the original repo). I don't think it's relevant.
We're not likely to regenerate the tree, but any clue what 'git subtree pull' would do in this case? It could happen if we switched to git-filter-repo.
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squashI'd put this in a script to run. Documentation tends to be not quite correct. A script could also be smarter and figure out <release-tag>.
Since you had mentioned elsewhere moving the kernel scripts/dtc/ to something using subtree, I do hope to learn some lessons from what you do there. The first thing is that given the size/nature of the commits, I had figured I'd be the one doing this as a subtree pull+squash then push, rather than posting to the ML since it'll be huge and un-reviewable, but with a note sent off to the ML that people should be aware the next sync has been done and retest as needed. But Sumit, were you planning to do some of this instead? The second thing is that if we move the subtree part in to dts/ instead (where we will still have the Makefile/Kconfig we have today and then our Makefiles within the directories, this might get more complex and so really require a script to keep it from getting error prone?
I played with this series and didn't really have time to dig into subtree mechanics but one thing I see is that when squash and merge happens you can't do simple rebase anymore which is time to time very useful. I see some different rebase strategies and --rebase-merges option but if this is adopted it should be properly described how to rebase u-boot tree which contains some subtrees.
Thanks, Michal
Hi Michal,
On Thu, 4 Jan 2024 at 15:39, Michal Simek michal.simek@amd.com wrote:
On 1/3/24 17:32, Tom Rini wrote:
On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote:
On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote:
[snip]
+In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
I would suggest dropping "-rebasing" in the u-boot tree. (I wish we had in the original repo). I don't think it's relevant.
We're not likely to regenerate the tree, but any clue what 'git subtree pull' would do in this case? It could happen if we switched to git-filter-repo.
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squashI'd put this in a script to run. Documentation tends to be not quite correct. A script could also be smarter and figure out <release-tag>.
Since you had mentioned elsewhere moving the kernel scripts/dtc/ to something using subtree, I do hope to learn some lessons from what you do there. The first thing is that given the size/nature of the commits, I had figured I'd be the one doing this as a subtree pull+squash then push, rather than posting to the ML since it'll be huge and un-reviewable, but with a note sent off to the ML that people should be aware the next sync has been done and retest as needed. But Sumit, were you planning to do some of this instead? The second thing is that if we move the subtree part in to dts/ instead (where we will still have the Makefile/Kconfig we have today and then our Makefiles within the directories, this might get more complex and so really require a script to keep it from getting error prone?
I played with this series and didn't really have time to dig into subtree mechanics but one thing I see is that when squash and merge happens you can't do simple rebase anymore which is time to time very useful. I see some different rebase strategies and --rebase-merges option but if this is adopted it should be properly described how to rebase u-boot tree which contains some subtrees.
Did you observe any specific difference with respect to subtree merge commits (Tom will likely do those in the beginning of next release cycle) when compared with normal merge commits when Tom pulls in code from different custodians like one example below? The same rebasing rules should apply to both types of merge commits.
commit dffa6d0210f57793f1e4e1e209d91ca5642e4d05 (origin/next) Merge: 2b28c3b871c e266d273114 Author: Tom Rini trini@konsulko.com Date: Mon Jan 1 12:38:15 2024 -0500
Merge tag 'dm-next-1124' of https://source.denx.de/u-boot/custodians/u-boot-dm into next
support propagating supernode properties with bootph schema align bloblist with v0.9 of Firmware Handoff spec
-Sumit
Thanks, Michal
On Thu, Jan 04, 2024 at 06:52:32PM +0530, Sumit Garg wrote:
Hi Michal,
On Thu, 4 Jan 2024 at 15:39, Michal Simek michal.simek@amd.com wrote:
On 1/3/24 17:32, Tom Rini wrote:
On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote:
On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote:
[snip]
+In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
I would suggest dropping "-rebasing" in the u-boot tree. (I wish we had in the original repo). I don't think it's relevant.
We're not likely to regenerate the tree, but any clue what 'git subtree pull' would do in this case? It could happen if we switched to git-filter-repo.
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squashI'd put this in a script to run. Documentation tends to be not quite correct. A script could also be smarter and figure out <release-tag>.
Since you had mentioned elsewhere moving the kernel scripts/dtc/ to something using subtree, I do hope to learn some lessons from what you do there. The first thing is that given the size/nature of the commits, I had figured I'd be the one doing this as a subtree pull+squash then push, rather than posting to the ML since it'll be huge and un-reviewable, but with a note sent off to the ML that people should be aware the next sync has been done and retest as needed. But Sumit, were you planning to do some of this instead? The second thing is that if we move the subtree part in to dts/ instead (where we will still have the Makefile/Kconfig we have today and then our Makefiles within the directories, this might get more complex and so really require a script to keep it from getting error prone?
I played with this series and didn't really have time to dig into subtree mechanics but one thing I see is that when squash and merge happens you can't do simple rebase anymore which is time to time very useful. I see some different rebase strategies and --rebase-merges option but if this is adopted it should be properly described how to rebase u-boot tree which contains some subtrees.
Did you observe any specific difference with respect to subtree merge commits (Tom will likely do those in the beginning of next release cycle) when compared with normal merge commits when Tom pulls in code from different custodians like one example below? The same rebasing rules should apply to both types of merge commits.
commit dffa6d0210f57793f1e4e1e209d91ca5642e4d05 (origin/next) Merge: 2b28c3b871c e266d273114 Author: Tom Rini trini@konsulko.com Date: Mon Jan 1 12:38:15 2024 -0500
Merge tag 'dm-next-1124' ofhttps://source.denx.de/u-boot/custodians/u-boot-dm into next
support propagating supernode properties with bootph schema align bloblist with v0.9 of Firmware Handoff spec
There's two cases. The first and uncommon case is that if you want to do something like: - Branch next - Add this subtree, do a few subtree updates on it (like my experiment of starting with v6.1-dts and merging up to v6.6-dts) - Wait a while, have changes happen in next - Rebase on to current next
It gets painful and odd, but I don't know that this will ever really happen.
The second, common case is: - Assume "next" already has this subtree + some merge commits in it. - Make a new local branch. - Make change in your new local branch. - This hypothetical "next" branch moves forward with changes - Rebase your local branch on to this "next" branch
In this case things work as expected. Even if "next" in that case gets a new subtree merge that you need to rebase in.
A third case that I'm not sure if really will happen or is a case where the custodian should rework their tree instead (to drop the subtree merge) is: - Assume "next" already has this subtree + some merge commits in it. - Make a new local branch. - Make a subtree merge+squash in your local branch. - This hypothetical "next" branch moves forward with changes - Rebase your local branch on to this "next" branch.
This will then make you try and resolve some conflicts from that subtree merge. But is this a valid use case? Yes, I can see wanting to get a start on testing a dts merge before it happens, but is this a tree which needs to be rebased, or just re-created as needed, if the parent branch moves forward?
Can you explain a bit more your case Michal since it sounded to me like you had a problem that happened rather than a worry about what might happen?
Hi Tom,
On 1/4/24 14:50, Tom Rini wrote:
On Thu, Jan 04, 2024 at 06:52:32PM +0530, Sumit Garg wrote:
Hi Michal,
On Thu, 4 Jan 2024 at 15:39, Michal Simek michal.simek@amd.com wrote:
On 1/3/24 17:32, Tom Rini wrote:
On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote:
On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote:
[snip]
+In order to maintain devicetree files sync, U-Boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
I would suggest dropping "-rebasing" in the u-boot tree. (I wish we had in the original repo). I don't think it's relevant.
We're not likely to regenerate the tree, but any clue what 'git subtree pull' would do in this case? It could happen if we switched to git-filter-repo.
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squashI'd put this in a script to run. Documentation tends to be not quite correct. A script could also be smarter and figure out <release-tag>.
Since you had mentioned elsewhere moving the kernel scripts/dtc/ to something using subtree, I do hope to learn some lessons from what you do there. The first thing is that given the size/nature of the commits, I had figured I'd be the one doing this as a subtree pull+squash then push, rather than posting to the ML since it'll be huge and un-reviewable, but with a note sent off to the ML that people should be aware the next sync has been done and retest as needed. But Sumit, were you planning to do some of this instead? The second thing is that if we move the subtree part in to dts/ instead (where we will still have the Makefile/Kconfig we have today and then our Makefiles within the directories, this might get more complex and so really require a script to keep it from getting error prone?
I played with this series and didn't really have time to dig into subtree mechanics but one thing I see is that when squash and merge happens you can't do simple rebase anymore which is time to time very useful. I see some different rebase strategies and --rebase-merges option but if this is adopted it should be properly described how to rebase u-boot tree which contains some subtrees.
Did you observe any specific difference with respect to subtree merge commits (Tom will likely do those in the beginning of next release cycle) when compared with normal merge commits when Tom pulls in code from different custodians like one example below? The same rebasing rules should apply to both types of merge commits.
commit dffa6d0210f57793f1e4e1e209d91ca5642e4d05 (origin/next) Merge: 2b28c3b871c e266d273114 Author: Tom Rini trini@konsulko.com Date: Mon Jan 1 12:38:15 2024 -0500
Merge tag 'dm-next-1124' ofhttps://source.denx.de/u-boot/custodians/u-boot-dm into next
support propagating supernode properties with bootph schema align bloblist with v0.9 of Firmware Handoff specThere's two cases. The first and uncommon case is that if you want to do something like:
- Branch next
- Add this subtree, do a few subtree updates on it (like my experiment of starting with v6.1-dts and merging up to v6.6-dts)
- Wait a while, have changes happen in next
- Rebase on to current next
It gets painful and odd, but I don't know that this will ever really happen.
The second, common case is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make change in your new local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch
In this case things work as expected. Even if "next" in that case gets a new subtree merge that you need to rebase in.
A third case that I'm not sure if really will happen or is a case where the custodian should rework their tree instead (to drop the subtree merge) is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make a subtree merge+squash in your local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch.
This will then make you try and resolve some conflicts from that subtree merge. But is this a valid use case? Yes, I can see wanting to get a start on testing a dts merge before it happens, but is this a tree which needs to be rebased, or just re-created as needed, if the parent branch moves forward?
Can you explain a bit more your case Michal since it sounded to me like you had a problem that happened rather than a worry about what might happen?
I remember couple of bisects which I was doing and it works fine on the tree till the point you have 2 issues to deal with. It means pretty much you have config change/fix which has to be applied to see second issue.
The normal way what I have done was simply find major version apply that fix and then take the latest tree and rebase latest on the top of it. There were normally not so many conflicts to resolved (or easy to resolve/ignore). Then because the first fix is present all the time bisect is able to help me to find second issue.
If there is subtree update the whole rebase will horribly fail.
I see that Rob and you in DTC case just simply do c&p and create regular commit with all changes inside. From my perspective this is more straightforward to deal with which will handle all cases and it is also proven over that years.
Thanks, Michal
On Thu, Jan 04, 2024 at 03:45:10PM +0100, Michal Simek wrote:
Hi Tom,
On 1/4/24 14:50, Tom Rini wrote:
On Thu, Jan 04, 2024 at 06:52:32PM +0530, Sumit Garg wrote:
Hi Michal,
On Thu, 4 Jan 2024 at 15:39, Michal Simek michal.simek@amd.com wrote:
On 1/3/24 17:32, Tom Rini wrote:
On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote:
On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote:
[snip]
> +In order to maintain devicetree files sync, U-Boot maintains a Git subtree for > +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly > +kept updated with every new kernel major release via subtree pull as follows::
I would suggest dropping "-rebasing" in the u-boot tree. (I wish we had in the original repo). I don't think it's relevant.
We're not likely to regenerate the tree, but any clue what 'git subtree pull' would do in this case? It could happen if we switched to git-filter-repo.
> + > + git subtree pull --prefix devicetree-rebasing \ > + git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > + <release-tag> --squash
I'd put this in a script to run. Documentation tends to be not quite correct. A script could also be smarter and figure out <release-tag>.
Since you had mentioned elsewhere moving the kernel scripts/dtc/ to something using subtree, I do hope to learn some lessons from what you do there. The first thing is that given the size/nature of the commits, I had figured I'd be the one doing this as a subtree pull+squash then push, rather than posting to the ML since it'll be huge and un-reviewable, but with a note sent off to the ML that people should be aware the next sync has been done and retest as needed. But Sumit, were you planning to do some of this instead? The second thing is that if we move the subtree part in to dts/ instead (where we will still have the Makefile/Kconfig we have today and then our Makefiles within the directories, this might get more complex and so really require a script to keep it from getting error prone?
I played with this series and didn't really have time to dig into subtree mechanics but one thing I see is that when squash and merge happens you can't do simple rebase anymore which is time to time very useful. I see some different rebase strategies and --rebase-merges option but if this is adopted it should be properly described how to rebase u-boot tree which contains some subtrees.
Did you observe any specific difference with respect to subtree merge commits (Tom will likely do those in the beginning of next release cycle) when compared with normal merge commits when Tom pulls in code from different custodians like one example below? The same rebasing rules should apply to both types of merge commits.
commit dffa6d0210f57793f1e4e1e209d91ca5642e4d05 (origin/next) Merge: 2b28c3b871c e266d273114 Author: Tom Rini trini@konsulko.com Date: Mon Jan 1 12:38:15 2024 -0500
Merge tag 'dm-next-1124' ofhttps://source.denx.de/u-boot/custodians/u-boot-dm into next
support propagating supernode properties with bootph schema align bloblist with v0.9 of Firmware Handoff specThere's two cases. The first and uncommon case is that if you want to do something like:
- Branch next
- Add this subtree, do a few subtree updates on it (like my experiment of starting with v6.1-dts and merging up to v6.6-dts)
- Wait a while, have changes happen in next
- Rebase on to current next
It gets painful and odd, but I don't know that this will ever really happen.
The second, common case is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make change in your new local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch
In this case things work as expected. Even if "next" in that case gets a new subtree merge that you need to rebase in.
A third case that I'm not sure if really will happen or is a case where the custodian should rework their tree instead (to drop the subtree merge) is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make a subtree merge+squash in your local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch.
This will then make you try and resolve some conflicts from that subtree merge. But is this a valid use case? Yes, I can see wanting to get a start on testing a dts merge before it happens, but is this a tree which needs to be rebased, or just re-created as needed, if the parent branch moves forward?
Can you explain a bit more your case Michal since it sounded to me like you had a problem that happened rather than a worry about what might happen?
I remember couple of bisects which I was doing and it works fine on the tree till the point you have 2 issues to deal with. It means pretty much you have config change/fix which has to be applied to see second issue.
The normal way what I have done was simply find major version apply that fix and then take the latest tree and rebase latest on the top of it. There were normally not so many conflicts to resolved (or easy to resolve/ignore). Then because the first fix is present all the time bisect is able to help me to find second issue.
If there is subtree update the whole rebase will horribly fail.
I see that Rob and you in DTC case just simply do c&p and create regular commit with all changes inside. From my perspective this is more straightforward to deal with which will handle all cases and it is also proven over that years.
Ah, bisecting. Maybe the (annoying) answer is to turn that merge commit in to a regular commit in the bisect branch? This is a good point, and I need to go and construct a bigger example tree and check around at what happens.
On 1/4/24 16:30, Tom Rini wrote:
On Thu, Jan 04, 2024 at 03:45:10PM +0100, Michal Simek wrote:
Hi Tom,
On 1/4/24 14:50, Tom Rini wrote:
On Thu, Jan 04, 2024 at 06:52:32PM +0530, Sumit Garg wrote:
Hi Michal,
On Thu, 4 Jan 2024 at 15:39, Michal Simek michal.simek@amd.com wrote:
On 1/3/24 17:32, Tom Rini wrote:
On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote: > On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote: [snip] >> +In order to maintain devicetree files sync, U-Boot maintains a Git subtree for >> +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly >> +kept updated with every new kernel major release via subtree pull as follows:: > > I would suggest dropping "-rebasing" in the u-boot tree. (I wish we > had in the original repo). I don't think it's relevant. > > We're not likely to regenerate the tree, but any clue what 'git > subtree pull' would do in this case? It could happen if we switched to > git-filter-repo. > >> + >> + git subtree pull --prefix devicetree-rebasing \ >> + git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ >> + <release-tag> --squash > > I'd put this in a script to run. Documentation tends to be not quite > correct. A script could also be smarter and figure out <release-tag>.
Since you had mentioned elsewhere moving the kernel scripts/dtc/ to something using subtree, I do hope to learn some lessons from what you do there. The first thing is that given the size/nature of the commits, I had figured I'd be the one doing this as a subtree pull+squash then push, rather than posting to the ML since it'll be huge and un-reviewable, but with a note sent off to the ML that people should be aware the next sync has been done and retest as needed. But Sumit, were you planning to do some of this instead? The second thing is that if we move the subtree part in to dts/ instead (where we will still have the Makefile/Kconfig we have today and then our Makefiles within the directories, this might get more complex and so really require a script to keep it from getting error prone?
I played with this series and didn't really have time to dig into subtree mechanics but one thing I see is that when squash and merge happens you can't do simple rebase anymore which is time to time very useful. I see some different rebase strategies and --rebase-merges option but if this is adopted it should be properly described how to rebase u-boot tree which contains some subtrees.
Did you observe any specific difference with respect to subtree merge commits (Tom will likely do those in the beginning of next release cycle) when compared with normal merge commits when Tom pulls in code from different custodians like one example below? The same rebasing rules should apply to both types of merge commits.
commit dffa6d0210f57793f1e4e1e209d91ca5642e4d05 (origin/next) Merge: 2b28c3b871c e266d273114 Author: Tom Rini trini@konsulko.com Date: Mon Jan 1 12:38:15 2024 -0500
Merge tag 'dm-next-1124' ofhttps://source.denx.de/u-boot/custodians/u-boot-dm into next
support propagating supernode properties with bootph schema align bloblist with v0.9 of Firmware Handoff specThere's two cases. The first and uncommon case is that if you want to do something like:
- Branch next
- Add this subtree, do a few subtree updates on it (like my experiment of starting with v6.1-dts and merging up to v6.6-dts)
- Wait a while, have changes happen in next
- Rebase on to current next
It gets painful and odd, but I don't know that this will ever really happen.
The second, common case is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make change in your new local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch
In this case things work as expected. Even if "next" in that case gets a new subtree merge that you need to rebase in.
A third case that I'm not sure if really will happen or is a case where the custodian should rework their tree instead (to drop the subtree merge) is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make a subtree merge+squash in your local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch.
This will then make you try and resolve some conflicts from that subtree merge. But is this a valid use case? Yes, I can see wanting to get a start on testing a dts merge before it happens, but is this a tree which needs to be rebased, or just re-created as needed, if the parent branch moves forward?
Can you explain a bit more your case Michal since it sounded to me like you had a problem that happened rather than a worry about what might happen?
I remember couple of bisects which I was doing and it works fine on the tree till the point you have 2 issues to deal with. It means pretty much you have config change/fix which has to be applied to see second issue.
The normal way what I have done was simply find major version apply that fix and then take the latest tree and rebase latest on the top of it. There were normally not so many conflicts to resolved (or easy to resolve/ignore). Then because the first fix is present all the time bisect is able to help me to find second issue.
If there is subtree update the whole rebase will horribly fail.
I see that Rob and you in DTC case just simply do c&p and create regular commit with all changes inside. From my perspective this is more straightforward to deal with which will handle all cases and it is also proven over that years.
Ah, bisecting. Maybe the (annoying) answer is to turn that merge commit in to a regular commit in the bisect branch? This is a good point, and I need to go and construct a bigger example tree and check around at what happens.
Sure you can do whatever you like. But I expect that at the end if this started to be used you will have subtree for devicetree, dtc, lwip and maybe something else. It means you have to start to keep track where that subtree are and what version is used at what time. Because dt binding is extending often likely you will need to merge it every Linux release. It means you would have to do it multiple times depends on how many releases you are going over.
I know that Qemu is using gitmodules that's definitely another option but not sure if better or worse.
I can also imagine that companies with SR IR certified firmware would keep downstream version where they want to just take code fixes, DT fixes and devicetree-rebasing tree to make sure that they are still aligned with DT schema. Can you simply just cherry pick that merged commit without any side effect?
Back to my point. At the end what we need to is to document it properly how to deal with it.
Thanks, Michal
On Thu, Jan 04, 2024 at 04:50:14PM +0100, Michal Simek wrote:
On 1/4/24 16:30, Tom Rini wrote:
On Thu, Jan 04, 2024 at 03:45:10PM +0100, Michal Simek wrote:
Hi Tom,
On 1/4/24 14:50, Tom Rini wrote:
On Thu, Jan 04, 2024 at 06:52:32PM +0530, Sumit Garg wrote:
Hi Michal,
On Thu, 4 Jan 2024 at 15:39, Michal Simek michal.simek@amd.com wrote:
On 1/3/24 17:32, Tom Rini wrote: > On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote: > > On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote: > [snip] > > > +In order to maintain devicetree files sync, U-Boot maintains a Git subtree for > > > +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly > > > +kept updated with every new kernel major release via subtree pull as follows:: > > > > I would suggest dropping "-rebasing" in the u-boot tree. (I wish we > > had in the original repo). I don't think it's relevant. > > > > We're not likely to regenerate the tree, but any clue what 'git > > subtree pull' would do in this case? It could happen if we switched to > > git-filter-repo. > > > > > + > > > + git subtree pull --prefix devicetree-rebasing \ > > > + git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > + <release-tag> --squash > > > > I'd put this in a script to run. Documentation tends to be not quite > > correct. A script could also be smarter and figure out <release-tag>. > > Since you had mentioned elsewhere moving the kernel scripts/dtc/ to > something using subtree, I do hope to learn some lessons from what you > do there. The first thing is that given the size/nature of the commits, > I had figured I'd be the one doing this as a subtree pull+squash then > push, rather than posting to the ML since it'll be huge and > un-reviewable, but with a note sent off to the ML that people should be > aware the next sync has been done and retest as needed. But Sumit, were > you planning to do some of this instead? The second thing is that if we > move the subtree part in to dts/ instead (where we will still have the > Makefile/Kconfig we have today and then our Makefiles within the > directories, this might get more complex and so really require a script > to keep it from getting error prone?
I played with this series and didn't really have time to dig into subtree mechanics but one thing I see is that when squash and merge happens you can't do simple rebase anymore which is time to time very useful. I see some different rebase strategies and --rebase-merges option but if this is adopted it should be properly described how to rebase u-boot tree which contains some subtrees.
Did you observe any specific difference with respect to subtree merge commits (Tom will likely do those in the beginning of next release cycle) when compared with normal merge commits when Tom pulls in code from different custodians like one example below? The same rebasing rules should apply to both types of merge commits.
commit dffa6d0210f57793f1e4e1e209d91ca5642e4d05 (origin/next) Merge: 2b28c3b871c e266d273114 Author: Tom Rini trini@konsulko.com Date: Mon Jan 1 12:38:15 2024 -0500
Merge tag 'dm-next-1124' ofhttps://source.denx.de/u-boot/custodians/u-boot-dm into next
support propagating supernode properties with bootph schema align bloblist with v0.9 of Firmware Handoff specThere's two cases. The first and uncommon case is that if you want to do something like:
- Branch next
- Add this subtree, do a few subtree updates on it (like my experiment of starting with v6.1-dts and merging up to v6.6-dts)
- Wait a while, have changes happen in next
- Rebase on to current next
It gets painful and odd, but I don't know that this will ever really happen.
The second, common case is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make change in your new local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch
In this case things work as expected. Even if "next" in that case gets a new subtree merge that you need to rebase in.
A third case that I'm not sure if really will happen or is a case where the custodian should rework their tree instead (to drop the subtree merge) is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make a subtree merge+squash in your local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch.
This will then make you try and resolve some conflicts from that subtree merge. But is this a valid use case? Yes, I can see wanting to get a start on testing a dts merge before it happens, but is this a tree which needs to be rebased, or just re-created as needed, if the parent branch moves forward?
Can you explain a bit more your case Michal since it sounded to me like you had a problem that happened rather than a worry about what might happen?
I remember couple of bisects which I was doing and it works fine on the tree till the point you have 2 issues to deal with. It means pretty much you have config change/fix which has to be applied to see second issue.
The normal way what I have done was simply find major version apply that fix and then take the latest tree and rebase latest on the top of it. There were normally not so many conflicts to resolved (or easy to resolve/ignore). Then because the first fix is present all the time bisect is able to help me to find second issue.
If there is subtree update the whole rebase will horribly fail.
I see that Rob and you in DTC case just simply do c&p and create regular commit with all changes inside. From my perspective this is more straightforward to deal with which will handle all cases and it is also proven over that years.
Ah, bisecting. Maybe the (annoying) answer is to turn that merge commit in to a regular commit in the bisect branch? This is a good point, and I need to go and construct a bigger example tree and check around at what happens.
Sure you can do whatever you like. But I expect that at the end if this started to be used you will have subtree for devicetree, dtc, lwip and maybe something else. It means you have to start to keep track where that subtree are and what version is used at what time.
Yes, lwip would be a subtree too, dtc is trickier but I see and agree with your point.
Because dt binding is extending often likely you will need to merge it every Linux release. It means you would have to do it multiple times depends on how many releases you are going over.
Yes, the plan is to re-sync every time our next opens with the kernel release at the time (which maybe needs to be clearer in the docs).
I know that Qemu is using gitmodules that's definitely another option but not sure if better or worse.
Yeah, submodules is harder and we're not going that path.
I can also imagine that companies with SR IR certified firmware would keep downstream version where they want to just take code fixes, DT fixes and devicetree-rebasing tree to make sure that they are still aligned with DT schema. Can you simply just cherry pick that merged commit without any side effect?
Life downstream is always fun. Personally, I would re-run the "git subtree" command rather than cherry-pick from U-Boot itself in that case, but it should be no different than any other commit.
Back to my point. At the end what we need to is to document it properly how to deal with it.
So, here's the test I did. I went back to v2023.10, then added v6.1-dts as a subtree. I rebased v2024.01-rc1 on top of that, added a fake bad commit, synced up subtrees to v6.6, and then rebased the tags along the way to v2024.01-rc6. I then went for a bisect back to the fake bad commit. Everything went fine, git didn't have troubles rebasing things as it went.
But to re-iterate, yes, the policy around when dts and bindings will be resynced needs to be clear and documented. Does that cover it?
On 1/4/24 19:03, Tom Rini wrote:
On Thu, Jan 04, 2024 at 04:50:14PM +0100, Michal Simek wrote:
On 1/4/24 16:30, Tom Rini wrote:
On Thu, Jan 04, 2024 at 03:45:10PM +0100, Michal Simek wrote:
Hi Tom,
On 1/4/24 14:50, Tom Rini wrote:
On Thu, Jan 04, 2024 at 06:52:32PM +0530, Sumit Garg wrote:
Hi Michal,
On Thu, 4 Jan 2024 at 15:39, Michal Simek michal.simek@amd.com wrote: > > > > On 1/3/24 17:32, Tom Rini wrote: >> On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote: >>> On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote: >> [snip] >>>> +In order to maintain devicetree files sync, U-Boot maintains a Git subtree for >>>> +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly >>>> +kept updated with every new kernel major release via subtree pull as follows:: >>> >>> I would suggest dropping "-rebasing" in the u-boot tree. (I wish we >>> had in the original repo). I don't think it's relevant. >>> >>> We're not likely to regenerate the tree, but any clue what 'git >>> subtree pull' would do in this case? It could happen if we switched to >>> git-filter-repo. >>> >>>> + >>>> + git subtree pull --prefix devicetree-rebasing \ >>>> + git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ >>>> + <release-tag> --squash >>> >>> I'd put this in a script to run. Documentation tends to be not quite >>> correct. A script could also be smarter and figure out <release-tag>. >> >> Since you had mentioned elsewhere moving the kernel scripts/dtc/ to >> something using subtree, I do hope to learn some lessons from what you >> do there. The first thing is that given the size/nature of the commits, >> I had figured I'd be the one doing this as a subtree pull+squash then >> push, rather than posting to the ML since it'll be huge and >> un-reviewable, but with a note sent off to the ML that people should be >> aware the next sync has been done and retest as needed. But Sumit, were >> you planning to do some of this instead? The second thing is that if we >> move the subtree part in to dts/ instead (where we will still have the >> Makefile/Kconfig we have today and then our Makefiles within the >> directories, this might get more complex and so really require a script >> to keep it from getting error prone? > > I played with this series and didn't really have time to dig into subtree > mechanics but one thing I see is that when squash and merge happens you can't do > simple rebase anymore which is time to time very useful. > I see some different rebase strategies and --rebase-merges option but if this is > adopted it should be properly described how to rebase u-boot tree which contains > some subtrees.
Did you observe any specific difference with respect to subtree merge commits (Tom will likely do those in the beginning of next release cycle) when compared with normal merge commits when Tom pulls in code from different custodians like one example below? The same rebasing rules should apply to both types of merge commits.
commit dffa6d0210f57793f1e4e1e209d91ca5642e4d05 (origin/next) Merge: 2b28c3b871c e266d273114 Author: Tom Rini trini@konsulko.com Date: Mon Jan 1 12:38:15 2024 -0500
Merge tag 'dm-next-1124' ofhttps://source.denx.de/u-boot/custodians/u-boot-dm into next
support propagating supernode properties with bootph schema align bloblist with v0.9 of Firmware Handoff specThere's two cases. The first and uncommon case is that if you want to do something like:
- Branch next
- Add this subtree, do a few subtree updates on it (like my experiment of starting with v6.1-dts and merging up to v6.6-dts)
- Wait a while, have changes happen in next
- Rebase on to current next
It gets painful and odd, but I don't know that this will ever really happen.
The second, common case is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make change in your new local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch
In this case things work as expected. Even if "next" in that case gets a new subtree merge that you need to rebase in.
A third case that I'm not sure if really will happen or is a case where the custodian should rework their tree instead (to drop the subtree merge) is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make a subtree merge+squash in your local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch.
This will then make you try and resolve some conflicts from that subtree merge. But is this a valid use case? Yes, I can see wanting to get a start on testing a dts merge before it happens, but is this a tree which needs to be rebased, or just re-created as needed, if the parent branch moves forward?
Can you explain a bit more your case Michal since it sounded to me like you had a problem that happened rather than a worry about what might happen?
I remember couple of bisects which I was doing and it works fine on the tree till the point you have 2 issues to deal with. It means pretty much you have config change/fix which has to be applied to see second issue.
The normal way what I have done was simply find major version apply that fix and then take the latest tree and rebase latest on the top of it. There were normally not so many conflicts to resolved (or easy to resolve/ignore). Then because the first fix is present all the time bisect is able to help me to find second issue.
If there is subtree update the whole rebase will horribly fail.
I see that Rob and you in DTC case just simply do c&p and create regular commit with all changes inside. From my perspective this is more straightforward to deal with which will handle all cases and it is also proven over that years.
Ah, bisecting. Maybe the (annoying) answer is to turn that merge commit in to a regular commit in the bisect branch? This is a good point, and I need to go and construct a bigger example tree and check around at what happens.
Sure you can do whatever you like. But I expect that at the end if this started to be used you will have subtree for devicetree, dtc, lwip and maybe something else. It means you have to start to keep track where that subtree are and what version is used at what time.
Yes, lwip would be a subtree too, dtc is trickier but I see and agree with your point.
Because dt binding is extending often likely you will need to merge it every Linux release. It means you would have to do it multiple times depends on how many releases you are going over.
Yes, the plan is to re-sync every time our next opens with the kernel release at the time (which maybe needs to be clearer in the docs).
I know that Qemu is using gitmodules that's definitely another option but not sure if better or worse.
Yeah, submodules is harder and we're not going that path.
I can also imagine that companies with SR IR certified firmware would keep downstream version where they want to just take code fixes, DT fixes and devicetree-rebasing tree to make sure that they are still aligned with DT schema. Can you simply just cherry pick that merged commit without any side effect?
Life downstream is always fun. Personally, I would re-run the "git subtree" command rather than cherry-pick from U-Boot itself in that case, but it should be no different than any other commit.
Back to my point. At the end what we need to is to document it properly how to deal with it.
So, here's the test I did. I went back to v2023.10, then added v6.1-dts as a subtree. I rebased v2024.01-rc1 on top of that, added a fake bad commit, synced up subtrees to v6.6, and then rebased the tags along the way to v2024.01-rc6. I then went for a bisect back to the fake bad commit. Everything went fine, git didn't have troubles rebasing things as it went.
But to re-iterate, yes, the policy around when dts and bindings will be resynced needs to be clear and documented. Does that cover it?
I am fine with it when we have documentation around.
Thanks, Michal
On Fri, 5 Jan 2024 at 13:46, Michal Simek michal.simek@amd.com wrote:
On 1/4/24 19:03, Tom Rini wrote:
On Thu, Jan 04, 2024 at 04:50:14PM +0100, Michal Simek wrote:
On 1/4/24 16:30, Tom Rini wrote:
On Thu, Jan 04, 2024 at 03:45:10PM +0100, Michal Simek wrote:
Hi Tom,
On 1/4/24 14:50, Tom Rini wrote:
On Thu, Jan 04, 2024 at 06:52:32PM +0530, Sumit Garg wrote: > Hi Michal, > > On Thu, 4 Jan 2024 at 15:39, Michal Simek michal.simek@amd.com wrote: >> >> >> >> On 1/3/24 17:32, Tom Rini wrote: >>> On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote: >>>> On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg sumit.garg@linaro.org wrote: >>> [snip] >>>>> +In order to maintain devicetree files sync, U-Boot maintains a Git subtree for >>>>> +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly >>>>> +kept updated with every new kernel major release via subtree pull as follows:: >>>> >>>> I would suggest dropping "-rebasing" in the u-boot tree. (I wish we >>>> had in the original repo). I don't think it's relevant. >>>> >>>> We're not likely to regenerate the tree, but any clue what 'git >>>> subtree pull' would do in this case? It could happen if we switched to >>>> git-filter-repo. >>>> >>>>> + >>>>> + git subtree pull --prefix devicetree-rebasing \ >>>>> + git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ >>>>> + <release-tag> --squash >>>> >>>> I'd put this in a script to run. Documentation tends to be not quite >>>> correct. A script could also be smarter and figure out <release-tag>. >>> >>> Since you had mentioned elsewhere moving the kernel scripts/dtc/ to >>> something using subtree, I do hope to learn some lessons from what you >>> do there. The first thing is that given the size/nature of the commits, >>> I had figured I'd be the one doing this as a subtree pull+squash then >>> push, rather than posting to the ML since it'll be huge and >>> un-reviewable, but with a note sent off to the ML that people should be >>> aware the next sync has been done and retest as needed. But Sumit, were >>> you planning to do some of this instead? The second thing is that if we >>> move the subtree part in to dts/ instead (where we will still have the >>> Makefile/Kconfig we have today and then our Makefiles within the >>> directories, this might get more complex and so really require a script >>> to keep it from getting error prone? >> >> I played with this series and didn't really have time to dig into subtree >> mechanics but one thing I see is that when squash and merge happens you can't do >> simple rebase anymore which is time to time very useful. >> I see some different rebase strategies and --rebase-merges option but if this is >> adopted it should be properly described how to rebase u-boot tree which contains >> some subtrees. > > Did you observe any specific difference with respect to subtree merge > commits (Tom will likely do those in the beginning of next release > cycle) when compared with normal merge commits when Tom pulls in code > from different custodians like one example below? The same rebasing > rules should apply to both types of merge commits. > > commit dffa6d0210f57793f1e4e1e209d91ca5642e4d05 (origin/next) > Merge: 2b28c3b871c e266d273114 > Author: Tom Rini trini@konsulko.com > Date: Mon Jan 1 12:38:15 2024 -0500 > > Merge tag 'dm-next-1124' of > https://source.denx.de/u-boot/custodians/u-boot-dm into next > > support propagating supernode properties with bootph schema > align bloblist with v0.9 of Firmware Handoff spec
There's two cases. The first and uncommon case is that if you want to do something like:
- Branch next
- Add this subtree, do a few subtree updates on it (like my experiment of starting with v6.1-dts and merging up to v6.6-dts)
- Wait a while, have changes happen in next
- Rebase on to current next
It gets painful and odd, but I don't know that this will ever really happen.
The second, common case is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make change in your new local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch
In this case things work as expected. Even if "next" in that case gets a new subtree merge that you need to rebase in.
A third case that I'm not sure if really will happen or is a case where the custodian should rework their tree instead (to drop the subtree merge) is:
- Assume "next" already has this subtree + some merge commits in it.
- Make a new local branch.
- Make a subtree merge+squash in your local branch.
- This hypothetical "next" branch moves forward with changes
- Rebase your local branch on to this "next" branch.
This will then make you try and resolve some conflicts from that subtree merge. But is this a valid use case? Yes, I can see wanting to get a start on testing a dts merge before it happens, but is this a tree which needs to be rebased, or just re-created as needed, if the parent branch moves forward?
Can you explain a bit more your case Michal since it sounded to me like you had a problem that happened rather than a worry about what might happen?
I remember couple of bisects which I was doing and it works fine on the tree till the point you have 2 issues to deal with. It means pretty much you have config change/fix which has to be applied to see second issue.
The normal way what I have done was simply find major version apply that fix and then take the latest tree and rebase latest on the top of it. There were normally not so many conflicts to resolved (or easy to resolve/ignore). Then because the first fix is present all the time bisect is able to help me to find second issue.
If there is subtree update the whole rebase will horribly fail.
I see that Rob and you in DTC case just simply do c&p and create regular commit with all changes inside. From my perspective this is more straightforward to deal with which will handle all cases and it is also proven over that years.
Ah, bisecting. Maybe the (annoying) answer is to turn that merge commit in to a regular commit in the bisect branch? This is a good point, and I need to go and construct a bigger example tree and check around at what happens.
Sure you can do whatever you like. But I expect that at the end if this started to be used you will have subtree for devicetree, dtc, lwip and maybe something else. It means you have to start to keep track where that subtree are and what version is used at what time.
Yes, lwip would be a subtree too, dtc is trickier but I see and agree with your point.
Because dt binding is extending often likely you will need to merge it every Linux release. It means you would have to do it multiple times depends on how many releases you are going over.
Yes, the plan is to re-sync every time our next opens with the kernel release at the time (which maybe needs to be clearer in the docs).
I will clarify this further in the docs.
-Sumit
I know that Qemu is using gitmodules that's definitely another option but not sure if better or worse.
Yeah, submodules is harder and we're not going that path.
I can also imagine that companies with SR IR certified firmware would keep downstream version where they want to just take code fixes, DT fixes and devicetree-rebasing tree to make sure that they are still aligned with DT schema. Can you simply just cherry pick that merged commit without any side effect?
Life downstream is always fun. Personally, I would re-run the "git subtree" command rather than cherry-pick from U-Boot itself in that case, but it should be no different than any other commit.
Back to my point. At the end what we need to is to document it properly how to deal with it.
So, here's the test I did. I went back to v2023.10, then added v6.1-dts as a subtree. I rebased v2024.01-rc1 on top of that, added a fake bad commit, synced up subtrees to v6.6, and then rebased the tags along the way to v2024.01-rc6. I then went for a bisect back to the fake bad commit. Everything went fine, git didn't have troubles rebasing things as it went.
But to re-iterate, yes, the policy around when dts and bindings will be resynced needs to be clear and documented. Does that cover it?
I am fine with it when we have documentation around.
Thanks, Michal
Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v3: -------------- - Picked up review tag
Changes in v2: -------------- - Picked up review tag
MAINTAINERS | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS index 969514468cb..253092c345c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -951,6 +951,12 @@ F: cmd/cyclic.c F: common/cyclic.c F: include/cyclic.h
+DEVICETREE REBASING SUBTREE +M: Sumit Garg sumit.garg@linaro.org +S: Maintained +F: devicetree-rebasing/ +F: dts/arch/ + DFU M: Lukasz Majewski lukma@denx.de M: Mattijs Korpershoek mkorpershoek@baylibre.com
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote:
Please can you add a commit message?
Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Picked up review tag
BTW 'patman status' does this for you.
Changes in v2:
- Picked up review tag
MAINTAINERS | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS index 969514468cb..253092c345c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -951,6 +951,12 @@ F: cmd/cyclic.c F: common/cyclic.c F: include/cyclic.h
+DEVICETREE REBASING SUBTREE +M: Sumit Garg sumit.garg@linaro.org +S: Maintained +F: devicetree-rebasing/ +F: dts/arch/
DFU M: Lukasz Majewski lukma@denx.de M: Mattijs Korpershoek mkorpershoek@baylibre.com -- 2.34.1
Regards, Simon
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v3: -------------- - Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
Changes in v2: -------------- - Picked up review tag
arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- dts/arch/arm64/amlogic | 1 + 9 files changed, 9 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index d6c89058061..8ddb59161a0 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig @@ -25,6 +25,7 @@ choice config MESON_GXBB bool "GXBB" select MESON_GX + imply OF_UPSTREAM help Select this if your SoC is an S905
diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..2e1c756bf7a 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig index 5f9f323e06e..ce5eaec3cd2 100644 --- a/configs/odroid-c2_defconfig +++ b/configs/odroid-c2_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/p200_defconfig b/configs/p200_defconfig index cd579ef5f14..b6946034795 100644 --- a/configs/p200_defconfig +++ b/configs/p200_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p200" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p200" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/p201_defconfig b/configs/p201_defconfig index b2f0a0ccdb4..dcc1454be16 100644 --- a/configs/p201_defconfig +++ b/configs/p201_defconfig @@ -7,7 +7,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p201" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p201" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/videostrong-kii-pro_defconfig b/configs/videostrong-kii-pro_defconfig index 3eda8f14a21..7a5af234471 100644 --- a/configs/videostrong-kii-pro_defconfig +++ b/configs/videostrong-kii-pro_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-kii-pro" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/wetek-hub_defconfig b/configs/wetek-hub_defconfig index fd92b041e73..85cff73f50f 100644 --- a/configs/wetek-hub_defconfig +++ b/configs/wetek-hub_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-hub" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-hub" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/wetek-play2_defconfig b/configs/wetek-play2_defconfig index b887419a6ba..efdf820165b 100644 --- a/configs/wetek-play2_defconfig +++ b/configs/wetek-play2_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-play2" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-play2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/dts/arch/arm64/amlogic b/dts/arch/arm64/amlogic new file mode 120000 index 00000000000..73f7c3e7bd0 --- /dev/null +++ b/dts/arch/arm64/amlogic @@ -0,0 +1 @@ +../../../devicetree-rebasing/src/arm64/amlogic/ \ No newline at end of file
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote:
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
Changes in v2:
- Picked up review tag
arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- dts/arch/arm64/amlogic | 1 + 9 files changed, 9 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
Reviewed-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index d6c89058061..8ddb59161a0 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig @@ -25,6 +25,7 @@ choice config MESON_GXBB bool "GXBB" select MESON_GX
imply OF_UPSTREAM help Select this if your SoC is an S905diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..2e1c756bf7a 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0
So now I am wondering if we can (later) have the SoC be implied when using OF_UPSTREAM so we can do:
CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
and it will add the 'amlogic/' automatically?
Perhaps that might be a way to bridge the gap in terms of file layout?
[..]
Regards, Simon
On Thu, Dec 28, 2023 at 01:37:11PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote:
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
Changes in v2:
- Picked up review tag
arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- dts/arch/arm64/amlogic | 1 + 9 files changed, 9 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
Reviewed-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index d6c89058061..8ddb59161a0 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig @@ -25,6 +25,7 @@ choice config MESON_GXBB bool "GXBB" select MESON_GX
imply OF_UPSTREAM help Select this if your SoC is an S905diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..2e1c756bf7a 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0
So now I am wondering if we can (later) have the SoC be implied when using OF_UPSTREAM so we can do:
CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
and it will add the 'amlogic/' automatically?
Perhaps that might be a way to bridge the gap in terms of file layout?
That's going to start to look real ugly real quick I suspect and I'm not sure what it really gets us? It seems to me that the convention of "vendor/board" has already been well enough adapted outside of the kernel, with the odd sticking point being getting everyone used to whatever will be happening for 32bit boards long term. So I think hiding the vendor part of the string here will be more, not less, confusing long term.
Hi Tom,
On Thu, Dec 28, 2023 at 1:56 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:11PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote:
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
Changes in v2:
- Picked up review tag
arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- dts/arch/arm64/amlogic | 1 + 9 files changed, 9 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
Reviewed-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index d6c89058061..8ddb59161a0 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig @@ -25,6 +25,7 @@ choice config MESON_GXBB bool "GXBB" select MESON_GX
imply OF_UPSTREAM help Select this if your SoC is an S905diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..2e1c756bf7a 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0
So now I am wondering if we can (later) have the SoC be implied when using OF_UPSTREAM so we can do:
CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
and it will add the 'amlogic/' automatically?
Perhaps that might be a way to bridge the gap in terms of file layout?
That's going to start to look real ugly real quick I suspect and I'm not sure what it really gets us? It seems to me that the convention of "vendor/board" has already been well enough adapted outside of the kernel, with the odd sticking point being getting everyone used to whatever will be happening for 32bit boards long term. So I think hiding the vendor part of the string here will be more, not less, confusing long term.
Now that I dig in a bit, I see that the devicetree-rebasing tree does not have any Makefiles in it. How does Linux build with it? Does anyone have instructions?
Regards, Simon
On Thu, Dec 28, 2023 at 03:09:41PM +0000, Simon Glass wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 1:56 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:11PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote:
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
Changes in v2:
- Picked up review tag
arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- dts/arch/arm64/amlogic | 1 + 9 files changed, 9 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
Reviewed-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index d6c89058061..8ddb59161a0 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig @@ -25,6 +25,7 @@ choice config MESON_GXBB bool "GXBB" select MESON_GX
imply OF_UPSTREAM help Select this if your SoC is an S905diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..2e1c756bf7a 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0
So now I am wondering if we can (later) have the SoC be implied when using OF_UPSTREAM so we can do:
CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
and it will add the 'amlogic/' automatically?
Perhaps that might be a way to bridge the gap in terms of file layout?
That's going to start to look real ugly real quick I suspect and I'm not sure what it really gets us? It seems to me that the convention of "vendor/board" has already been well enough adapted outside of the kernel, with the odd sticking point being getting everyone used to whatever will be happening for 32bit boards long term. So I think hiding the vendor part of the string here will be more, not less, confusing long term.
Now that I dig in a bit, I see that the devicetree-rebasing tree does not have any Makefiles in it. How does Linux build with it? Does anyone have instructions?
Linux doesn't build with it, it's the relevant parts of the kernel tree extracted for other projects to more easily use (more or less).
Hi Tom,
On Thu, Dec 28, 2023 at 3:25 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:41PM +0000, Simon Glass wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 1:56 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:11PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote:
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
Changes in v2:
- Picked up review tag
arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- dts/arch/arm64/amlogic | 1 + 9 files changed, 9 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
Reviewed-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index d6c89058061..8ddb59161a0 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig @@ -25,6 +25,7 @@ choice config MESON_GXBB bool "GXBB" select MESON_GX
imply OF_UPSTREAM help Select this if your SoC is an S905diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..2e1c756bf7a 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0
So now I am wondering if we can (later) have the SoC be implied when using OF_UPSTREAM so we can do:
CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
and it will add the 'amlogic/' automatically?
Perhaps that might be a way to bridge the gap in terms of file layout?
That's going to start to look real ugly real quick I suspect and I'm not sure what it really gets us? It seems to me that the convention of "vendor/board" has already been well enough adapted outside of the kernel, with the odd sticking point being getting everyone used to whatever will be happening for 32bit boards long term. So I think hiding the vendor part of the string here will be more, not less, confusing long term.
Now that I dig in a bit, I see that the devicetree-rebasing tree does not have any Makefiles in it. How does Linux build with it? Does anyone have instructions?
Linux doesn't build with it, it's the relevant parts of the kernel tree extracted for other projects to more easily use (more or less).
Hmmm, in that case can we add Makefiles into the U-Boot version of the tree, for U-Boot use?
Regards, Simon
On Thu, Dec 28, 2023 at 07:48:13PM +0000, Simon Glass wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 3:25 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:41PM +0000, Simon Glass wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 1:56 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:11PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote:
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
Changes in v2:
- Picked up review tag
arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- dts/arch/arm64/amlogic | 1 + 9 files changed, 9 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
Reviewed-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index d6c89058061..8ddb59161a0 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig @@ -25,6 +25,7 @@ choice config MESON_GXBB bool "GXBB" select MESON_GX
imply OF_UPSTREAM help Select this if your SoC is an S905diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..2e1c756bf7a 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0
So now I am wondering if we can (later) have the SoC be implied when using OF_UPSTREAM so we can do:
CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
and it will add the 'amlogic/' automatically?
Perhaps that might be a way to bridge the gap in terms of file layout?
That's going to start to look real ugly real quick I suspect and I'm not sure what it really gets us? It seems to me that the convention of "vendor/board" has already been well enough adapted outside of the kernel, with the odd sticking point being getting everyone used to whatever will be happening for 32bit boards long term. So I think hiding the vendor part of the string here will be more, not less, confusing long term.
Now that I dig in a bit, I see that the devicetree-rebasing tree does not have any Makefiles in it. How does Linux build with it? Does anyone have instructions?
Linux doesn't build with it, it's the relevant parts of the kernel tree extracted for other projects to more easily use (more or less).
Hmmm, in that case can we add Makefiles into the U-Boot version of the tree, for U-Boot use?
No? Why would we do that? I think you're missing how the amlogic conversion works.
Hi Tom,
On Thu, Dec 28, 2023 at 1:32 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 07:48:13PM +0000, Simon Glass wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 3:25 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:41PM +0000, Simon Glass wrote:
Hi Tom,
On Thu, Dec 28, 2023 at 1:56 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:11PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg sumit.garg@linaro.org wrote: > > Although there were still some variations in board DTS files based on > meson-gxbb SoC but I think those were minor differences from upstream > and shouldn't impact boot on these devices. > > So switch to upstream DT via mirroring amlogic/ directory from > devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly > building DTB from there including *-u-boot.dtsi files from > arch/$(ARCH)/dts/ directory. > > Reviewed-by: Neil Armstrong neil.armstrong@linaro.org > Signed-off-by: Sumit Garg sumit.garg@linaro.org > --- > > Changes in v3: > -------------- > - Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead. > > Changes in v2: > -------------- > - Picked up review tag > > arch/arm/mach-meson/Kconfig | 1 + > configs/nanopi-k2_defconfig | 2 +- > configs/odroid-c2_defconfig | 2 +- > configs/p200_defconfig | 2 +- > configs/p201_defconfig | 2 +- > configs/videostrong-kii-pro_defconfig | 2 +- > configs/wetek-hub_defconfig | 2 +- > configs/wetek-play2_defconfig | 2 +- > dts/arch/arm64/amlogic | 1 + > 9 files changed, 9 insertions(+), 7 deletions(-) > create mode 120000 dts/arch/arm64/amlogic >
Reviewed-by: Simon Glass sjg@chromium.org
> diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig > index d6c89058061..8ddb59161a0 100644 > --- a/arch/arm/mach-meson/Kconfig > +++ b/arch/arm/mach-meson/Kconfig > @@ -25,6 +25,7 @@ choice > config MESON_GXBB > bool "GXBB" > select MESON_GX > + imply OF_UPSTREAM > help > Select this if your SoC is an S905 > > diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig > index 41dbf7981f8..2e1c756bf7a 100644 > --- a/configs/nanopi-k2_defconfig > +++ b/configs/nanopi-k2_defconfig > @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 > CONFIG_ENV_SIZE=0x2000 > CONFIG_DM_GPIO=y > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" > CONFIG_OF_LIBFDT_OVERLAY=y > CONFIG_DM_RESET=y > CONFIG_DEBUG_UART_BASE=0xc81004c0
So now I am wondering if we can (later) have the SoC be implied when using OF_UPSTREAM so we can do:
CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
and it will add the 'amlogic/' automatically?
Perhaps that might be a way to bridge the gap in terms of file layout?
That's going to start to look real ugly real quick I suspect and I'm not sure what it really gets us? It seems to me that the convention of "vendor/board" has already been well enough adapted outside of the kernel, with the odd sticking point being getting everyone used to whatever will be happening for 32bit boards long term. So I think hiding the vendor part of the string here will be more, not less, confusing long term.
Now that I dig in a bit, I see that the devicetree-rebasing tree does not have any Makefiles in it. How does Linux build with it? Does anyone have instructions?
Linux doesn't build with it, it's the relevant parts of the kernel tree extracted for other projects to more easily use (more or less).
Hmmm, in that case can we add Makefiles into the U-Boot version of the tree, for U-Boot use?
No? Why would we do that? I think you're missing how the amlogic conversion works.
I will reply on the other thread about this.
Regards, Simon
Since meson-gxbb based boards switched to using upstream DT, so drop redundant files from arch/arm/dts directory. Only *-u-boot.dtsi files kept in arch/arm/dts directory for these boards.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v3: -------------- - Picked up review tag
Changes in v2: -------------- - None
arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 415 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 418 ------------ arch/arm/dts/meson-gxbb-p200.dts | 100 --- arch/arm/dts/meson-gxbb-p201.dts | 26 - arch/arm/dts/meson-gxbb-p20x.dtsi | 250 ------- arch/arm/dts/meson-gxbb-wetek-hub.dts | 58 -- arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 ---- arch/arm/dts/meson-gxbb-wetek.dtsi | 292 -------- arch/arm/dts/meson-gxbb.dtsi | 856 ------------------------ 11 files changed, 2682 deletions(-) delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi delete mode 100644 arch/arm/dts/meson-gxbb.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 5fc888680b3..45bd1166029 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -212,14 +212,6 @@ dtb-$(CONFIG_ARCH_MESON) += \ meson-a1-ad401.dtb \ meson-axg-s400.dtb \ meson-axg-jethome-jethub-j100.dtb \ - meson-gxbb-kii-pro.dtb \ - meson-gxbb-nanopi-k2.dtb \ - meson-gxbb-odroidc2.dtb \ - meson-gxbb-nanopi-k2.dtb \ - meson-gxbb-p200.dtb \ - meson-gxbb-p201.dtb \ - meson-gxbb-wetek-hub.dtb \ - meson-gxbb-wetek-play2.dtb \ meson-gxl-s805x-libretech-ac.dtb \ meson-gxl-s905d-libretech-pc.dtb \ meson-gxl-s905w-jethome-jethub-j80.dtb \ diff --git a/arch/arm/dts/meson-gxbb-kii-pro.dts b/arch/arm/dts/meson-gxbb-kii-pro.dts deleted file mode 100644 index e238f1f1012..00000000000 --- a/arch/arm/dts/meson-gxbb-kii-pro.dts +++ /dev/null @@ -1,140 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2019 Mohammad Rasim mohammad.rasim96@gmail.com - */ - -/dts-v1/; - -#include "meson-gxbb-p20x.dtsi" -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/input/input.h> -#include <dt-bindings/leds/common.h> -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "videostrong,kii-pro", "amlogic,meson-gxbb"; - model = "Videostrong KII Pro"; - - spdif_dit: audio-codec-0 { - #sound-dai-cells = <0>; - compatible = "linux,spdif-dit"; - status = "okay"; - sound-name-prefix = "DIT"; - }; - - leds { - compatible = "gpio-leds"; - led { - gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>; - color = <LED_COLOR_ID_RED>; - function = LED_FUNCTION_STATUS; - default-state = "off"; - }; - }; - - gpio-keys-polled { - compatible = "gpio-keys-polled"; - poll-interval = <20>; - - button-reset { - label = "reset"; - linux,code = <KEY_POWER>; - gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>; - }; - }; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "KII-PRO"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-3 { - sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>; - - codec-0 { - sound-dai = <&spdif_dit>; - }; - }; - - dai-link-4 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; - pinctrl-0 = <&spdif_out_y_pins>; - pinctrl-names = "default"; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rmii_pins>; - pinctrl-names = "default"; - - phy-handle = <ð_phy0>; - phy-mode = "rmii"; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@0 { - /* IC Plus IP101GR (0x02430c54) */ - reg = <0>; - reset-assert-us = <10000>; - reset-deassert-us = <10000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - }; - }; -}; - -&ir { - linux,rc-map-name = "rc-videostrong-kii-pro"; -}; - -&uart_A { - status = "okay"; - pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>; - pinctrl-names = "default"; - uart-has-rtscts; - - bluetooth { - compatible = "brcm,bcm4335a0"; - shutdown-gpios = <&gpio GPIOX_20 GPIO_ACTIVE_HIGH>; - host-wakeup-gpios = <&gpio GPIOX_21 GPIO_ACTIVE_HIGH>; - max-speed = <2000000>; - clocks = <&wifi32k>; - clock-names = "lpo"; - }; -}; diff --git a/arch/arm/dts/meson-gxbb-nanopi-k2.dts b/arch/arm/dts/meson-gxbb-nanopi-k2.dts deleted file mode 100644 index 7273eed5292..00000000000 --- a/arch/arm/dts/meson-gxbb-nanopi-k2.dts +++ /dev/null @@ -1,415 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2017 Andreas Färber - */ - -/dts-v1/; - -#include "meson-gxbb.dtsi" -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "friendlyarm,nanopi-k2", "amlogic,meson-gxbb"; - model = "FriendlyARM NanoPi K2"; - - aliases { - serial0 = &uart_AO; - ethernet0 = ðmac; - }; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - memory@0 { - device_type = "memory"; - reg = <0x0 0x0 0x0 0x80000000>; - }; - - leds { - compatible = "gpio-leds"; - - led-stat { - label = "nanopi-k2:blue:stat"; - gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>; - default-state = "on"; - panic-indicator; - }; - }; - - vdd_5v: regulator-vdd-5v { - compatible = "regulator-fixed"; - regulator-name = "VDD_5V"; - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - }; - - vddio_ao18: regulator-vddio-ao18 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO18"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - vddio_ao3v3: regulator-vddio-ao3v3 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - vddio_tf: regulator-vddio-tf { - compatible = "regulator-gpio"; - - regulator-name = "VDDIO_TF"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - - gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_HIGH>; - gpios-states = <0>; - - states = <3300000 0>, - <1800000 1>; - - regulator-settling-time-up-us = <100>; - regulator-settling-time-down-us = <5000>; - }; - - wifi_32k: wifi-32k { - compatible = "pwm-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */ - }; - - sdio_pwrseq: sdio-pwrseq { - compatible = "mmc-pwrseq-simple"; - reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>; - clocks = <&wifi_32k>; - clock-names = "ext_clock"; - }; - - vcc1v8: regulator-vcc1v8 { - compatible = "regulator-fixed"; - regulator-name = "VCC1.8V"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - vcc3v3: regulator-vcc3v3 { - compatible = "regulator-fixed"; - regulator-name = "VCC3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - emmc_pwrseq: emmc-pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; - }; - - /* CVBS is available on CON1 pin 36, disabled by default */ - cvbs-connector { - compatible = "composite-video-connector"; - status = "disabled"; - - port { - cvbs_connector_in: endpoint { - remote-endpoint = <&cvbs_vdac_out>; - }; - }; - }; - - hdmi-connector { - compatible = "hdmi-connector"; - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&hdmi_tx_tmds_out>; - }; - }; - }; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "NANOPI-K2"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - status = "okay"; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; -}; - -&cec_AO { - status = "okay"; - pinctrl-0 = <&ao_cec_pins>; - pinctrl-names = "default"; - hdmi-phandle = <&hdmi_tx>; -}; - -&cvbs_vdac_port { - cvbs_vdac_out: endpoint { - remote-endpoint = <&cvbs_connector_in>; - }; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rgmii_pins>; - pinctrl-names = "default"; - - phy-handle = <ð_phy0>; - phy-mode = "rgmii"; - - amlogic,tx-delay-ns = <2>; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@0 { - /* Realtek RTL8211F (0x001cc916) */ - reg = <0>; - - reset-assert-us = <10000>; - reset-deassert-us = <80000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - - interrupt-parent = <&gpio_intc>; - /* MAC_INTR on GPIOZ_15 */ - interrupts = <29 IRQ_TYPE_LEVEL_LOW>; - }; - }; -}; - -&hdmi_tx { - status = "okay"; - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>; - pinctrl-names = "default"; -}; - -&hdmi_tx_tmds_port { - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; -}; - -&ir { - status = "okay"; - pinctrl-0 = <&remote_input_ao_pins>; - pinctrl-names = "default"; -}; - -&gpio_ao { - gpio-line-names = "UART TX", "UART RX", "Power Control", "Power Key In", - "VCCK En", "CON1 Header Pin31", - "I2S Header Pin6", "IR In", "I2S Header Pin7", - "I2S Header Pin3", "I2S Header Pin4", - "I2S Header Pin5", "HDMI CEC", "SYS LED", - /* GPIO_TEST_N */ - ""; -}; - -&gpio { - gpio-line-names = /* Bank GPIOZ */ - "Eth MDIO", "Eth MDC", "Eth RGMII RX Clk", - "Eth RX DV", "Eth RX D0", "Eth RX D1", "Eth RX D2", - "Eth RX D3", "Eth RGMII TX Clk", "Eth TX En", - "Eth TX D0", "Eth TX D1", "Eth TX D2", "Eth TX D3", - "Eth PHY nRESET", "Eth PHY Intc", - /* Bank GPIOH */ - "HDMI HPD", "HDMI DDC SDA", "HDMI DDC SCL", - "CON1 Header Pin33", - /* Bank BOOT */ - "eMMC D0", "eMMC D1", "eMMC D2", "eMMC D3", "eMMC D4", - "eMMC D5", "eMMC D6", "eMMC D7", "eMMC Clk", - "eMMC Reset", "eMMC CMD", - "", "", "", "", "eMMC DS", - "", "", - /* Bank CARD */ - "SDCard D1", "SDCard D0", "SDCard CLK", "SDCard CMD", - "SDCard D3", "SDCard D2", "SDCard Det", - /* Bank GPIODV */ - "", "", "", "", "", "", "", "", "", "", "", "", "", - "", "", "", "", "", "", "", "", "", "", "", - "I2C A SDA", "I2C A SCK", "I2C B SDA", "I2C B SCK", - "VDDEE Regulator", "VCCK Regulator", - /* Bank GPIOY */ - "CON1 Header Pin7", "CON1 Header Pin11", - "CON1 Header Pin13", "CON1 Header Pin15", - "CON1 Header Pin18", "CON1 Header Pin19", - "CON1 Header Pin22", "CON1 Header Pin21", - "CON1 Header Pin24", "CON1 Header Pin23", - "CON1 Header Pin26", "CON1 Header Pin29", - "CON1 Header Pin32", "CON1 Header Pin8", - "CON1 Header Pin10", "CON1 Header Pin16", - "CON1 Header Pin12", - /* Bank GPIOX */ - "WIFI SDIO D0", "WIFI SDIO D1", "WIFI SDIO D2", - "WIFI SDIO D3", "WIFI SDIO CLK", "WIFI SDIO CMD", - "WIFI Power Enable", "WIFI WAKE HOST", - "Bluetooth PCM DOUT", "Bluetooth PCM DIN", - "Bluetooth PCM SYNC", "Bluetooth PCM CLK", - "Bluetooth UART TX", "Bluetooth UART RX", - "Bluetooth UART CTS", "Bluetooth UART RTS", - "", "", "", "WIFI 32K", "Bluetooth Enable", - "Bluetooth WAKE HOST", "", - /* Bank GPIOCLK */ - "", "CON1 Header Pin35", "", ""; -}; - -&pwm_ef { - status = "okay"; - pinctrl-0 = <&pwm_e_pins>; - pinctrl-names = "default"; - clocks = <&clkc CLKID_FCLK_DIV4>; - clock-names = "clkin0"; -}; - -&saradc { - status = "okay"; - vref-supply = <&vddio_ao18>; -}; - -/* SDIO */ -&sd_emmc_a { - status = "okay"; - pinctrl-0 = <&sdio_pins>, <&sdio_irq_pins>; - pinctrl-1 = <&sdio_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - #address-cells = <1>; - #size-cells = <0>; - - bus-width = <4>; - cap-sd-highspeed; - max-frequency = <50000000>; - - non-removable; - disable-wp; - - /* WiFi firmware requires power to be kept while in suspend */ - keep-power-in-suspend; - - mmc-pwrseq = <&sdio_pwrseq>; - - vmmc-supply = <&vddio_ao3v3>; - vqmmc-supply = <&vddio_ao18>; - - brcmf: wifi@1 { - compatible = "brcm,bcm4329-fmac"; - reg = <1>; - }; -}; - -/* SD */ -&sd_emmc_b { - status = "okay"; - pinctrl-0 = <&sdcard_pins>; - pinctrl-1 = <&sdcard_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <4>; - cap-sd-highspeed; - sd-uhs-sdr12; - sd-uhs-sdr25; - sd-uhs-sdr50; - sd-uhs-ddr50; - max-frequency = <100000000>; - disable-wp; - - cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>; - - vmmc-supply = <&vddio_ao3v3>; - vqmmc-supply = <&vddio_tf>; -}; - -/* eMMC */ -&sd_emmc_c { - status = "disabled"; - pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>; - pinctrl-1 = <&emmc_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <8>; - max-frequency = <200000000>; - non-removable; - disable-wp; - cap-mmc-highspeed; - mmc-ddr-1_8v; - mmc-hs200-1_8v; - - mmc-pwrseq = <&emmc_pwrseq>; - vmmc-supply = <&vcc3v3>; - vqmmc-supply = <&vcc1v8>; -}; - -/* DBG_UART */ -&uart_AO { - status = "okay"; - pinctrl-0 = <&uart_ao_a_pins>; - pinctrl-names = "default"; -}; - -/* Bluetooth on AP6212 */ -&uart_A { - status = "disabled"; - pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>; - pinctrl-names = "default"; -}; - -/* 40-pin CON1 */ -&uart_C { - status = "disabled"; - pinctrl-0 = <&uart_c_pins>; - pinctrl-names = "default"; -}; - -&usb0_phy { - status = "okay"; - phy-supply = <&vdd_5v>; -}; - -&usb1_phy { - status = "okay"; -}; - -&usb0 { - status = "okay"; -}; - -&usb1 { - status = "okay"; -}; diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts b/arch/arm/dts/meson-gxbb-odroidc2.dts deleted file mode 100644 index 201596247fd..00000000000 --- a/arch/arm/dts/meson-gxbb-odroidc2.dts +++ /dev/null @@ -1,418 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -/dts-v1/; - -#include "meson-gxbb.dtsi" -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb"; - model = "Hardkernel ODROID-C2"; - - aliases { - serial0 = &uart_AO; - ethernet0 = ðmac; - }; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - memory@0 { - device_type = "memory"; - reg = <0x0 0x0 0x0 0x80000000>; - }; - - usb_otg_pwr: regulator-usb-pwrs { - compatible = "regulator-fixed"; - - regulator-name = "USB_OTG_PWR"; - - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - - /* - * signal name from schematics: PWREN - */ - gpio = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>; - enable-active-high; - /* - * signal name from schematics: USB_POWER - */ - vin-supply = <&p5v0>; - }; - - leds { - compatible = "gpio-leds"; - led-blue { - label = "c2:blue:alive"; - gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>; - linux,default-trigger = "heartbeat"; - default-state = "off"; - }; - }; - - p5v0: regulator-p5v0 { - compatible = "regulator-fixed"; - - regulator-name = "P5V0"; - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - regulator-always-on; - }; - - hdmi_p5v0: regulator-hdmi_p5v0 { - compatible = "regulator-fixed"; - regulator-name = "HDMI_P5V0"; - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - /* AP2331SA-7 */ - vin-supply = <&p5v0>; - }; - - tflash_vdd: regulator-tflash_vdd { - compatible = "regulator-fixed"; - - regulator-name = "TFLASH_VDD"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - - /* - * signal name from schematics: TFLASH_VDD_EN - */ - gpio = <&gpio GPIOY_12 GPIO_ACTIVE_HIGH>; - enable-active-high; - /* U16 RT9179GB */ - vin-supply = <&vddio_ao3v3>; - }; - - tf_io: gpio-regulator-tf_io { - compatible = "regulator-gpio"; - - regulator-name = "TF_IO"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - - /* - * signal name from schematics: TF_3V3N_1V8_EN - */ - gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>; - gpios-states = <0>; - - states = <3300000 0>, - <1800000 1>; - /* U12/U13 RT9179GB */ - vin-supply = <&vddio_ao3v3>; - }; - - vcc1v8: regulator-vcc1v8 { - compatible = "regulator-fixed"; - regulator-name = "VCC1V8"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - /* U18 RT9179GB */ - vin-supply = <&vddio_ao3v3>; - }; - - vcc3v3: regulator-vcc3v3 { - compatible = "regulator-fixed"; - regulator-name = "VCC3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - vddio_ao1v8: regulator-vddio-ao1v8 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO1V8"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - /* U17 RT9179GB */ - vin-supply = <&p5v0>; - }; - - vddio_ao3v3: regulator-vddio-ao3v3 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-always-on; - /* U11 MP2161GJ-C499 */ - vin-supply = <&p5v0>; - }; - - ddr3_1v5: regulator-ddr3_1v5 { - compatible = "regulator-fixed"; - regulator-name = "DDR3_1V5"; - regulator-min-microvolt = <1500000>; - regulator-max-microvolt = <1500000>; - regulator-always-on; - /* U15 MP2161GJ-C499 */ - vin-supply = <&p5v0>; - }; - - emmc_pwrseq: emmc-pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; - }; - - hdmi-connector { - compatible = "hdmi-connector"; - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&hdmi_tx_tmds_out>; - }; - }; - }; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "ODROID-C2"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - status = "okay"; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; -}; - -&cec_AO { - status = "okay"; - pinctrl-0 = <&ao_cec_pins>; - pinctrl-names = "default"; - hdmi-phandle = <&hdmi_tx>; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rgmii_pins>; - pinctrl-names = "default"; - phy-handle = <ð_phy0>; - phy-mode = "rgmii"; - - amlogic,tx-delay-ns = <2>; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@0 { - /* Realtek RTL8211F (0x001cc916) */ - reg = <0>; - - reset-assert-us = <10000>; - reset-deassert-us = <80000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - - interrupt-parent = <&gpio_intc>; - /* MAC_INTR on GPIOZ_15 */ - interrupts = <29 IRQ_TYPE_LEVEL_LOW>; - }; - }; -}; - -&gpio_ao { - /* - * WARNING: The USB Hub on the Odroid-C2 needs a reset signal - * to be turned high in order to be detected by the USB Controller - * This signal should be handled by a USB specific power sequence - * in order to reset the Hub when USB bus is powered down. - */ - hog-0 { - gpio-hog; - gpios = <GPIOAO_4 GPIO_ACTIVE_HIGH>; - output-high; - line-name = "usb-hub-reset"; - }; -}; - -&hdmi_tx { - status = "okay"; - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>; - pinctrl-names = "default"; - hdmi-supply = <&hdmi_p5v0>; -}; - -&hdmi_tx_tmds_port { - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; -}; - -&i2c_A { - status = "okay"; - pinctrl-0 = <&i2c_a_pins>; - pinctrl-names = "default"; -}; - -&ir { - status = "okay"; - pinctrl-0 = <&remote_input_ao_pins>; - pinctrl-names = "default"; - linux,rc-map-name = "rc-odroid"; -}; - -&gpio_ao { - gpio-line-names = "UART TX", "UART RX", "VCCK En", "TF 3V3/1V8 En", - "USB HUB nRESET", "USB OTG Power En", - "J7 Header Pin2", "IR In", "J7 Header Pin4", - "J7 Header Pin6", "J7 Header Pin5", "J7 Header Pin7", - "HDMI CEC", "SYS LED", - /* GPIO_TEST_N */ - ""; -}; - -&gpio { - gpio-line-names = /* Bank GPIOZ */ - "Eth MDIO", "Eth MDC", "Eth RGMII RX Clk", - "Eth RX DV", "Eth RX D0", "Eth RX D1", "Eth RX D2", - "Eth RX D3", "Eth RGMII TX Clk", "Eth TX En", - "Eth TX D0", "Eth TX D1", "Eth TX D2", "Eth TX D3", - "Eth PHY nRESET", "Eth PHY Intc", - /* Bank GPIOH */ - "HDMI HPD", "HDMI DDC SDA", "HDMI DDC SCL", "", - /* Bank BOOT */ - "eMMC D0", "eMMC D1", "eMMC D2", "eMMC D3", "eMMC D4", - "eMMC D5", "eMMC D6", "eMMC D7", "eMMC Clk", - "eMMC Reset", "eMMC CMD", - "", "", "", "", "", "", "", - /* Bank CARD */ - "SDCard D1", "SDCard D0", "SDCard CLK", "SDCard CMD", - "SDCard D3", "SDCard D2", "SDCard Det", - /* Bank GPIODV */ - "", "", "", "", "", "", "", "", "", "", "", "", "", - "", "", "", "", "", "", "", "", "", "", "", - "I2C A SDA", "I2C A SCK", "I2C B SDA", "I2C B SCK", - "PWM D", "PWM B", - /* Bank GPIOY */ - "Revision Bit0", "Revision Bit1", "", - "J2 Header Pin35", "", "", "", "J2 Header Pin36", - "J2 Header Pin31", "", "", "", "TF VDD En", - "J2 Header Pin32", "J2 Header Pin26", "", "", - /* Bank GPIOX */ - "J2 Header Pin29", "J2 Header Pin24", - "J2 Header Pin23", "J2 Header Pin22", - "J2 Header Pin21", "J2 Header Pin18", - "J2 Header Pin33", "J2 Header Pin19", - "J2 Header Pin16", "J2 Header Pin15", - "J2 Header Pin12", "J2 Header Pin13", - "J2 Header Pin8", "J2 Header Pin10", - "", "", "", "", "", - "J2 Header Pin11", "", "J2 Header Pin7", "", - /* Bank GPIOCLK */ - "", "", "", ""; -}; - -&saradc { - status = "okay"; - vref-supply = <&vcc1v8>; -}; - -&scpi_clocks { - status = "disabled"; -}; - -/* SD */ -&sd_emmc_b { - status = "okay"; - pinctrl-0 = <&sdcard_pins>; - pinctrl-1 = <&sdcard_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <4>; - cap-sd-highspeed; - sd-uhs-sdr12; - sd-uhs-sdr25; - sd-uhs-sdr50; - sd-uhs-ddr50; - max-frequency = <100000000>; - disable-wp; - - cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>; - - vmmc-supply = <&tflash_vdd>; - vqmmc-supply = <&tf_io>; -}; - -/* eMMC */ -&sd_emmc_c { - status = "okay"; - pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>; - pinctrl-1 = <&emmc_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <8>; - max-frequency = <200000000>; - non-removable; - disable-wp; - cap-mmc-highspeed; - mmc-ddr-1_8v; - mmc-hs200-1_8v; - - mmc-pwrseq = <&emmc_pwrseq>; - vmmc-supply = <&vcc3v3>; - vqmmc-supply = <&vcc1v8>; -}; - -&uart_AO { - status = "okay"; - pinctrl-0 = <&uart_ao_a_pins>; - pinctrl-names = "default"; -}; - -&usb0_phy { - status = "disabled"; - phy-supply = <&usb_otg_pwr>; -}; - -&usb1_phy { - status = "okay"; - phy-supply = <&usb_otg_pwr>; -}; - -&usb0 { - status = "disabled"; -}; - -&usb1 { - status = "okay"; -}; diff --git a/arch/arm/dts/meson-gxbb-p200.dts b/arch/arm/dts/meson-gxbb-p200.dts deleted file mode 100644 index 3c93d1898b4..00000000000 --- a/arch/arm/dts/meson-gxbb-p200.dts +++ /dev/null @@ -1,100 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -/dts-v1/; - -#include "meson-gxbb-p20x.dtsi" -#include <dt-bindings/input/input.h> - -/ { - compatible = "amlogic,p200", "amlogic,meson-gxbb"; - model = "Amlogic Meson GXBB P200 Development Board"; - - avdd18_usb_adc: regulator-avdd18_usb_adc { - compatible = "regulator-fixed"; - regulator-name = "AVDD18_USB_ADC"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - adc_keys { - compatible = "adc-keys"; - io-channels = <&saradc 0>; - io-channel-names = "buttons"; - keyup-threshold-microvolt = <1800000>; - - button-home { - label = "Home"; - linux,code = <KEY_HOME>; - press-threshold-microvolt = <900000>; /* 50% */ - }; - - button-esc { - label = "Esc"; - linux,code = <KEY_ESC>; - press-threshold-microvolt = <684000>; /* 38% */ - }; - - button-up { - label = "Volume Up"; - linux,code = <KEY_VOLUMEUP>; - press-threshold-microvolt = <468000>; /* 26% */ - }; - - button-down { - label = "Volume Down"; - linux,code = <KEY_VOLUMEDOWN>; - press-threshold-microvolt = <252000>; /* 14% */ - }; - - button-menu { - label = "Menu"; - linux,code = <KEY_MENU>; - press-threshold-microvolt = <0>; /* 0% */ - }; - }; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rgmii_pins>; - pinctrl-names = "default"; - phy-handle = <ð_phy0>; - phy-mode = "rgmii"; - - amlogic,tx-delay-ns = <2>; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@3 { - /* Micrel KSZ9031 (0x00221620) */ - reg = <3>; - - reset-assert-us = <10000>; - reset-deassert-us = <30000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - - interrupt-parent = <&gpio_intc>; - /* MAC_INTR on GPIOZ_15 */ - interrupts = <29 IRQ_TYPE_LEVEL_LOW>; - }; - }; -}; - -&i2c_B { - status = "okay"; - pinctrl-0 = <&i2c_b_pins>; - pinctrl-names = "default"; -}; - -&saradc { - status = "okay"; - vref-supply = <&avdd18_usb_adc>; -}; diff --git a/arch/arm/dts/meson-gxbb-p201.dts b/arch/arm/dts/meson-gxbb-p201.dts deleted file mode 100644 index 150a82f3b2d..00000000000 --- a/arch/arm/dts/meson-gxbb-p201.dts +++ /dev/null @@ -1,26 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -/dts-v1/; - -#include "meson-gxbb-p20x.dtsi" - -/ { - compatible = "amlogic,p201", "amlogic,meson-gxbb"; - model = "Amlogic Meson GXBB P201 Development Board"; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rmii_pins>; - pinctrl-names = "default"; - phy-mode = "rmii"; - - snps,reset-gpio = <&gpio GPIOZ_14 0>; - snps,reset-delays-us = <0>, <10000>, <1000000>; - snps,reset-active-low; -}; diff --git a/arch/arm/dts/meson-gxbb-p20x.dtsi b/arch/arm/dts/meson-gxbb-p20x.dtsi deleted file mode 100644 index e803a466fe4..00000000000 --- a/arch/arm/dts/meson-gxbb-p20x.dtsi +++ /dev/null @@ -1,250 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -#include "meson-gxbb.dtsi" - -/ { - aliases { - serial0 = &uart_AO; - ethernet0 = ðmac; - }; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - memory@0 { - device_type = "memory"; - reg = <0x0 0x0 0x0 0x40000000>; - }; - - usb_pwr: regulator-usb-pwrs { - compatible = "regulator-fixed"; - - regulator-name = "USB_PWR"; - - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - - /* signal name in schematic: USB_PWR_EN */ - gpio = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>; - enable-active-high; - }; - - vddio_card: gpio-regulator { - compatible = "regulator-gpio"; - - regulator-name = "VDDIO_CARD"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - - gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>; - gpios-states = <1>; - - /* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */ - states = <1800000 0>, - <3300000 1>; - - regulator-settling-time-up-us = <10000>; - regulator-settling-time-down-us = <150000>; - }; - - vddio_boot: regulator-vddio_boot { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_BOOT"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - vddao_3v3: regulator-vddao_3v3 { - compatible = "regulator-fixed"; - regulator-name = "VDDAO_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - vcc_3v3: regulator-vcc_3v3 { - compatible = "regulator-fixed"; - regulator-name = "VCC_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - emmc_pwrseq: emmc-pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; - }; - - wifi32k: wifi32k { - compatible = "pwm-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */ - }; - - sdio_pwrseq: sdio-pwrseq { - compatible = "mmc-pwrseq-simple"; - reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>; - clocks = <&wifi32k>; - clock-names = "ext_clock"; - }; - - cvbs_connector: cvbs-connector { - compatible = "composite-video-connector"; - - port { - cvbs_connector_in: endpoint { - remote-endpoint = <&cvbs_vdac_out>; - }; - }; - }; - - hdmi-connector { - compatible = "hdmi-connector"; - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&hdmi_tx_tmds_out>; - }; - }; - }; -}; - -&cec_AO { - status = "okay"; - pinctrl-0 = <&ao_cec_pins>; - pinctrl-names = "default"; - hdmi-phandle = <&hdmi_tx>; -}; - -&cvbs_vdac_port { - cvbs_vdac_out: endpoint { - remote-endpoint = <&cvbs_connector_in>; - }; -}; - -&hdmi_tx { - status = "okay"; - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>; - pinctrl-names = "default"; -}; - -&hdmi_tx_tmds_port { - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; -}; - -&ir { - status = "okay"; - pinctrl-0 = <&remote_input_ao_pins>; - pinctrl-names = "default"; -}; - -&pwm_ef { - status = "okay"; - pinctrl-0 = <&pwm_e_pins>; - pinctrl-names = "default"; - clocks = <&clkc CLKID_FCLK_DIV4>; - clock-names = "clkin0"; -}; - -/* Wireless SDIO Module */ -&sd_emmc_a { - status = "okay"; - pinctrl-0 = <&sdio_pins>; - pinctrl-1 = <&sdio_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - #address-cells = <1>; - #size-cells = <0>; - - bus-width = <4>; - cap-sd-highspeed; - max-frequency = <50000000>; - - non-removable; - disable-wp; - - /* WiFi firmware requires power to be kept while in suspend */ - keep-power-in-suspend; - - mmc-pwrseq = <&sdio_pwrseq>; - - vmmc-supply = <&vddao_3v3>; - vqmmc-supply = <&vddio_boot>; - - brcmf: wifi@1 { - reg = <1>; - compatible = "brcm,bcm4329-fmac"; - }; -}; - -/* SD card */ -&sd_emmc_b { - status = "okay"; - pinctrl-0 = <&sdcard_pins>; - pinctrl-1 = <&sdcard_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <4>; - cap-sd-highspeed; - sd-uhs-sdr12; - sd-uhs-sdr25; - sd-uhs-sdr50; - max-frequency = <100000000>; - disable-wp; - - cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>; - - vmmc-supply = <&vddao_3v3>; - vqmmc-supply = <&vddio_card>; -}; - -/* eMMC */ -&sd_emmc_c { - status = "okay"; - pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>; - pinctrl-1 = <&emmc_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <8>; - cap-mmc-highspeed; - max-frequency = <200000000>; - non-removable; - disable-wp; - mmc-ddr-1_8v; - mmc-hs200-1_8v; - - mmc-pwrseq = <&emmc_pwrseq>; - vmmc-supply = <&vcc_3v3>; - vqmmc-supply = <&vddio_boot>; -}; - -/* This UART is brought out to the DB9 connector */ -&uart_AO { - status = "okay"; - pinctrl-0 = <&uart_ao_a_pins>; - pinctrl-names = "default"; -}; - -&usb0_phy { - status = "okay"; - phy-supply = <&usb_pwr>; -}; - -&usb1_phy { - status = "okay"; -}; - -&usb0 { - status = "okay"; -}; - -&usb1 { - status = "okay"; -}; diff --git a/arch/arm/dts/meson-gxbb-wetek-hub.dts b/arch/arm/dts/meson-gxbb-wetek-hub.dts deleted file mode 100644 index 58733017eda..00000000000 --- a/arch/arm/dts/meson-gxbb-wetek-hub.dts +++ /dev/null @@ -1,58 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 BayLibre, Inc. - * Author: Neil Armstrong narmstrong@baylibre.com - */ - -/dts-v1/; - -#include "meson-gxbb-wetek.dtsi" -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "wetek,hub", "amlogic,meson-gxbb"; - model = "WeTek Hub"; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "WETEK-HUB"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - status = "okay"; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; -}; - -&ir { - linux,rc-map-name = "rc-wetek-hub"; -}; diff --git a/arch/arm/dts/meson-gxbb-wetek-play2.dts b/arch/arm/dts/meson-gxbb-wetek-play2.dts deleted file mode 100644 index 505ffcd8eb7..00000000000 --- a/arch/arm/dts/meson-gxbb-wetek-play2.dts +++ /dev/null @@ -1,119 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 BayLibre, Inc. - * Author: Neil Armstrong narmstrong@baylibre.com - */ - -/dts-v1/; - -#include "meson-gxbb-wetek.dtsi" -#include <dt-bindings/input/input.h> -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "wetek,play2", "amlogic,meson-gxbb"; - model = "WeTek Play 2"; - - spdif_dit: audio-codec-0 { - #sound-dai-cells = <0>; - compatible = "linux,spdif-dit"; - status = "okay"; - sound-name-prefix = "DIT"; - }; - - leds { - led-wifi { - label = "wetek-play:wifi-status"; - gpios = <&gpio GPIODV_26 GPIO_ACTIVE_HIGH>; - default-state = "off"; - }; - - led-ethernet { - label = "wetek-play:ethernet-status"; - gpios = <&gpio GPIODV_27 GPIO_ACTIVE_HIGH>; - default-state = "off"; - }; - }; - - gpio-keys-polled { - compatible = "gpio-keys-polled"; - poll-interval = <100>; - - button { - label = "reset"; - linux,code = <KEY_RESTART>; - gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_LOW>; - }; - }; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "WETEK-PLAY2"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - status = "okay"; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-3 { - sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>; - - codec-0 { - sound-dai = <&spdif_dit>; - }; - }; - - dai-link-4 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; - pinctrl-0 = <&spdif_out_y_pins>; - pinctrl-names = "default"; -}; - -&i2c_A { - status = "okay"; - pinctrl-0 = <&i2c_a_pins>; - pinctrl-names = "default"; -}; - -&usb1_phy { - status = "okay"; -}; - -&usb1 { - status = "okay"; -}; - -&ir { - linux,rc-map-name = "rc-wetek-play2"; -}; diff --git a/arch/arm/dts/meson-gxbb-wetek.dtsi b/arch/arm/dts/meson-gxbb-wetek.dtsi deleted file mode 100644 index 94dafb95530..00000000000 --- a/arch/arm/dts/meson-gxbb-wetek.dtsi +++ /dev/null @@ -1,292 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -#include "meson-gxbb.dtsi" -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/leds/common.h> - -/ { - aliases { - serial0 = &uart_AO; - ethernet0 = ðmac; - }; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - memory@0 { - device_type = "memory"; - reg = <0x0 0x0 0x0 0x40000000>; - }; - - leds { - compatible = "gpio-leds"; - - led-power { - /* red in suspend or power-off */ - color = <LED_COLOR_ID_BLUE>; - function = LED_FUNCTION_POWER; - gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>; - default-state = "on"; - panic-indicator; - }; - }; - - usb_pwr: regulator-usb-pwrs { - compatible = "regulator-fixed"; - - regulator-name = "USB_PWR"; - - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - - gpio = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>; - enable-active-high; - }; - - vddio_boot: regulator-vddio_boot { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_BOOT"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - vddao_3v3: regulator-vddao_3v3 { - compatible = "regulator-fixed"; - regulator-name = "VDDAO_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - vddio_ao18: regulator-vddio_ao18 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO18"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - }; - - vcc_3v3: regulator-vcc_3v3 { - compatible = "regulator-fixed"; - regulator-name = "VCC_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - emmc_pwrseq: emmc-pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; - }; - - wifi32k: wifi32k { - compatible = "pwm-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */ - }; - - sdio_pwrseq: sdio-pwrseq { - compatible = "mmc-pwrseq-simple"; - reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>; - clocks = <&wifi32k>; - clock-names = "ext_clock"; - }; - - cvbs-connector { - compatible = "composite-video-connector"; - - port { - cvbs_connector_in: endpoint { - remote-endpoint = <&cvbs_vdac_out>; - }; - }; - }; - - hdmi-connector { - compatible = "hdmi-connector"; - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&hdmi_tx_tmds_out>; - }; - }; - }; -}; - -&cec_AO { - status = "okay"; - pinctrl-0 = <&ao_cec_pins>; - pinctrl-names = "default"; - hdmi-phandle = <&hdmi_tx>; -}; - -&cvbs_vdac_port { - cvbs_vdac_out: endpoint { - remote-endpoint = <&cvbs_connector_in>; - }; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rgmii_pins>; - pinctrl-names = "default"; - - phy-handle = <ð_phy0>; - phy-mode = "rgmii"; - - amlogic,tx-delay-ns = <2>; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@0 { - /* Realtek RTL8211F (0x001cc916) */ - reg = <0>; - - reset-assert-us = <10000>; - reset-deassert-us = <80000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - - interrupt-parent = <&gpio_intc>; - /* MAC_INTR on GPIOZ_15 */ - interrupts = <29 IRQ_TYPE_LEVEL_LOW>; - }; - }; -}; - -&hdmi_tx { - status = "okay"; - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>; - pinctrl-names = "default"; - hdmi-supply = <&vddio_ao18>; -}; - -&hdmi_tx_tmds_port { - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; -}; - -&ir { - status = "okay"; - pinctrl-0 = <&remote_input_ao_pins>; - pinctrl-names = "default"; -}; - -&pwm_ef { - status = "okay"; - pinctrl-0 = <&pwm_e_pins>; - pinctrl-names = "default"; - clocks = <&clkc CLKID_FCLK_DIV4>; - clock-names = "clkin0"; -}; - -&saradc { - status = "okay"; - vref-supply = <&vddio_ao18>; -}; - -/* Wireless SDIO Module */ -&sd_emmc_a { - status = "okay"; - pinctrl-0 = <&sdio_pins>; - pinctrl-1 = <&sdio_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - #address-cells = <1>; - #size-cells = <0>; - - bus-width = <4>; - cap-sd-highspeed; - max-frequency = <50000000>; - - non-removable; - disable-wp; - - /* WiFi firmware requires power to be kept while in suspend */ - keep-power-in-suspend; - - mmc-pwrseq = <&sdio_pwrseq>; - - vmmc-supply = <&vddao_3v3>; - vqmmc-supply = <&vddio_boot>; - - brcmf: wifi@1 { - reg = <1>; - compatible = "brcm,bcm4329-fmac"; - }; -}; - -/* SD card */ -&sd_emmc_b { - status = "okay"; - pinctrl-0 = <&sdcard_pins>; - pinctrl-1 = <&sdcard_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <4>; - cap-sd-highspeed; - max-frequency = <50000000>; - disable-wp; - - cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>; - - vmmc-supply = <&vddao_3v3>; - vqmmc-supply = <&vcc_3v3>; -}; - -/* eMMC */ -&sd_emmc_c { - status = "okay"; - pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>; - pinctrl-1 = <&emmc_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <8>; - cap-mmc-highspeed; - max-frequency = <200000000>; - non-removable; - disable-wp; - mmc-ddr-1_8v; - mmc-hs200-1_8v; - - mmc-pwrseq = <&emmc_pwrseq>; - vmmc-supply = <&vcc_3v3>; - vqmmc-supply = <&vddio_boot>; -}; - -/* This is connected to the Bluetooth module: */ -&uart_A { - status = "okay"; - pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>; - pinctrl-names = "default"; - uart-has-rtscts; - - bluetooth { - compatible = "brcm,bcm43438-bt"; - shutdown-gpios = <&gpio GPIOX_20 GPIO_ACTIVE_HIGH>; - }; -}; - -/* This UART is brought out to the DB9 connector */ -&uart_AO { - status = "okay"; - pinctrl-0 = <&uart_ao_a_pins>; - pinctrl-names = "default"; -}; - -&usb0_phy { - status = "okay"; - phy-supply = <&usb_pwr>; -}; - -&usb0 { - status = "okay"; -}; diff --git a/arch/arm/dts/meson-gxbb.dtsi b/arch/arm/dts/meson-gxbb.dtsi deleted file mode 100644 index 7c029f552a2..00000000000 --- a/arch/arm/dts/meson-gxbb.dtsi +++ /dev/null @@ -1,856 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - */ - -#include "meson-gx.dtsi" -#include "meson-gx-mali450.dtsi" -#include <dt-bindings/gpio/meson-gxbb-gpio.h> -#include <dt-bindings/reset/amlogic,meson-gxbb-reset.h> -#include <dt-bindings/clock/gxbb-clkc.h> -#include <dt-bindings/clock/gxbb-aoclkc.h> -#include <dt-bindings/reset/gxbb-aoclkc.h> - -/ { - compatible = "amlogic,meson-gxbb"; - - soc { - usb0_phy: phy@c0000000 { - compatible = "amlogic,meson-gxbb-usb2-phy"; - #phy-cells = <0>; - reg = <0x0 0xc0000000 0x0 0x20>; - resets = <&reset RESET_USB_OTG>; - clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB0>; - clock-names = "usb_general", "usb"; - status = "disabled"; - }; - - usb1_phy: phy@c0000020 { - compatible = "amlogic,meson-gxbb-usb2-phy"; - #phy-cells = <0>; - reg = <0x0 0xc0000020 0x0 0x20>; - resets = <&reset RESET_USB_OTG>; - clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB1>; - clock-names = "usb_general", "usb"; - status = "disabled"; - }; - - usb0: usb@c9000000 { - compatible = "amlogic,meson-gxbb-usb", "snps,dwc2"; - reg = <0x0 0xc9000000 0x0 0x40000>; - interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clkc CLKID_USB0_DDR_BRIDGE>; - clock-names = "otg"; - phys = <&usb0_phy>; - phy-names = "usb2-phy"; - dr_mode = "host"; - status = "disabled"; - }; - - usb1: usb@c9100000 { - compatible = "amlogic,meson-gxbb-usb", "snps,dwc2"; - reg = <0x0 0xc9100000 0x0 0x40000>; - interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clkc CLKID_USB1_DDR_BRIDGE>; - clock-names = "otg"; - phys = <&usb1_phy>; - phy-names = "usb2-phy"; - dr_mode = "host"; - status = "disabled"; - }; - }; -}; - -&aiu { - compatible = "amlogic,aiu-gxbb", "amlogic,aiu"; - clocks = <&clkc CLKID_AIU_GLUE>, - <&clkc CLKID_I2S_OUT>, - <&clkc CLKID_AOCLK_GATE>, - <&clkc CLKID_CTS_AMCLK>, - <&clkc CLKID_MIXER_IFACE>, - <&clkc CLKID_IEC958>, - <&clkc CLKID_IEC958_GATE>, - <&clkc CLKID_CTS_MCLK_I958>, - <&clkc CLKID_CTS_I958>; - clock-names = "pclk", - "i2s_pclk", - "i2s_aoclk", - "i2s_mclk", - "i2s_mixer", - "spdif_pclk", - "spdif_aoclk", - "spdif_mclk", - "spdif_mclk_sel"; - resets = <&reset RESET_AIU>; -}; - -&aobus { - pinctrl_aobus: pinctrl@14 { - compatible = "amlogic,meson-gxbb-aobus-pinctrl"; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - gpio_ao: bank@14 { - reg = <0x0 0x00014 0x0 0x8>, - <0x0 0x0002c 0x0 0x4>, - <0x0 0x00024 0x0 0x8>; - reg-names = "mux", "pull", "gpio"; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&pinctrl_aobus 0 0 14>; - }; - - uart_ao_a_pins: uart_ao_a { - mux { - groups = "uart_tx_ao_a", "uart_rx_ao_a"; - function = "uart_ao"; - bias-disable; - }; - }; - - uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts { - mux { - groups = "uart_cts_ao_a", - "uart_rts_ao_a"; - function = "uart_ao"; - bias-disable; - }; - }; - - uart_ao_b_pins: uart_ao_b { - mux { - groups = "uart_tx_ao_b", "uart_rx_ao_b"; - function = "uart_ao_b"; - bias-disable; - }; - }; - - uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts { - mux { - groups = "uart_cts_ao_b", - "uart_rts_ao_b"; - function = "uart_ao_b"; - bias-disable; - }; - }; - - remote_input_ao_pins: remote_input_ao { - mux { - groups = "remote_input_ao"; - function = "remote_input_ao"; - bias-disable; - }; - }; - - i2c_ao_pins: i2c_ao { - mux { - groups = "i2c_sck_ao", - "i2c_sda_ao"; - function = "i2c_ao"; - bias-disable; - }; - }; - - pwm_ao_a_3_pins: pwm_ao_a_3 { - mux { - groups = "pwm_ao_a_3"; - function = "pwm_ao_a_3"; - bias-disable; - }; - }; - - pwm_ao_a_6_pins: pwm_ao_a_6 { - mux { - groups = "pwm_ao_a_6"; - function = "pwm_ao_a_6"; - bias-disable; - }; - }; - - pwm_ao_a_12_pins: pwm_ao_a_12 { - mux { - groups = "pwm_ao_a_12"; - function = "pwm_ao_a_12"; - bias-disable; - }; - }; - - pwm_ao_b_pins: pwm_ao_b { - mux { - groups = "pwm_ao_b"; - function = "pwm_ao_b"; - bias-disable; - }; - }; - - i2s_am_clk_pins: i2s_am_clk { - mux { - groups = "i2s_am_clk"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_ao_clk_pins: i2s_out_ao_clk { - mux { - groups = "i2s_out_ao_clk"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_lr_clk_pins: i2s_out_lr_clk { - mux { - groups = "i2s_out_lr_clk"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_ch01_ao_pins: i2s_out_ch01_ao { - mux { - groups = "i2s_out_ch01_ao"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_ch23_ao_pins: i2s_out_ch23_ao { - mux { - groups = "i2s_out_ch23_ao"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_ch45_ao_pins: i2s_out_ch45_ao { - mux { - groups = "i2s_out_ch45_ao"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - spdif_out_ao_6_pins: spdif_out_ao_6 { - mux { - groups = "spdif_out_ao_6"; - function = "spdif_out_ao"; - }; - }; - - spdif_out_ao_13_pins: spdif_out_ao_13 { - mux { - groups = "spdif_out_ao_13"; - function = "spdif_out_ao"; - bias-disable; - }; - }; - - ao_cec_pins: ao_cec { - mux { - groups = "ao_cec"; - function = "cec_ao"; - bias-disable; - }; - }; - - ee_cec_pins: ee_cec { - mux { - groups = "ee_cec"; - function = "cec_ao"; - bias-disable; - }; - }; - }; -}; - -&cbus { - spifc: spi@8c80 { - compatible = "amlogic,meson-gxbb-spifc"; - reg = <0x0 0x08c80 0x0 0x80>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&clkc CLKID_SPI>; - status = "disabled"; - }; -}; - -&cec_AO { - clocks = <&clkc_AO CLKID_AO_CEC_32K>; - clock-names = "core"; -}; - -&clkc_AO { - compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc"; - clocks = <&xtal>, <&clkc CLKID_CLK81>; - clock-names = "xtal", "mpeg-clk"; -}; - -&efuse { - clocks = <&clkc CLKID_EFUSE>; -}; - -ðmac { - clocks = <&clkc CLKID_ETH>, - <&clkc CLKID_FCLK_DIV2>, - <&clkc CLKID_MPLL2>, - <&clkc CLKID_FCLK_DIV2>; - clock-names = "stmmaceth", "clkin0", "clkin1", "timing-adjustment"; -}; - -&gpio_intc { - compatible = "amlogic,meson-gpio-intc", - "amlogic,meson-gxbb-gpio-intc"; - status = "okay"; -}; - -&hdmi_tx { - compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi"; - resets = <&reset RESET_HDMITX_CAPB3>, - <&reset RESET_HDMI_SYSTEM_RESET>, - <&reset RESET_HDMI_TX>; - reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy"; - clocks = <&clkc CLKID_HDMI_PCLK>, - <&clkc CLKID_CLK81>, - <&clkc CLKID_GCLK_VENCI_INT0>; - clock-names = "isfr", "iahb", "venci"; -}; - -&sysctrl { - clkc: clock-controller { - compatible = "amlogic,gxbb-clkc"; - #clock-cells = <1>; - clocks = <&xtal>; - clock-names = "xtal"; - }; -}; - -&hwrng { - clocks = <&clkc CLKID_RNG0>; - clock-names = "core"; -}; - -&i2c_A { - clocks = <&clkc CLKID_I2C>; -}; - -&i2c_AO { - clocks = <&clkc CLKID_AO_I2C>; -}; - -&i2c_B { - clocks = <&clkc CLKID_I2C>; -}; - -&i2c_C { - clocks = <&clkc CLKID_I2C>; -}; - -&mali { - compatible = "amlogic,meson-gxbb-mali", "arm,mali-450"; - - clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>; - clock-names = "bus", "core"; - - assigned-clocks = <&clkc CLKID_GP0_PLL>; - assigned-clock-rates = <744000000>; -}; - -&periphs { - pinctrl_periphs: pinctrl@4b0 { - compatible = "amlogic,meson-gxbb-periphs-pinctrl"; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - gpio: bank@4b0 { - reg = <0x0 0x004b0 0x0 0x28>, - <0x0 0x004e8 0x0 0x14>, - <0x0 0x00520 0x0 0x14>, - <0x0 0x00430 0x0 0x40>; - reg-names = "mux", "pull", "pull-enable", "gpio"; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&pinctrl_periphs 0 0 119>; - }; - - emmc_pins: emmc { - mux-0 { - groups = "emmc_nand_d07", - "emmc_cmd"; - function = "emmc"; - bias-pull-up; - }; - - mux-1 { - groups = "emmc_clk"; - function = "emmc"; - bias-disable; - }; - }; - - emmc_ds_pins: emmc-ds { - mux { - groups = "emmc_ds"; - function = "emmc"; - bias-pull-down; - }; - }; - - emmc_clk_gate_pins: emmc_clk_gate { - mux { - groups = "BOOT_8"; - function = "gpio_periphs"; - bias-pull-down; - }; - }; - - nor_pins: nor { - mux { - groups = "nor_d", - "nor_q", - "nor_c", - "nor_cs"; - function = "nor"; - bias-disable; - }; - }; - - spi_pins: spi-pins { - mux { - groups = "spi_miso", - "spi_mosi", - "spi_sclk"; - function = "spi"; - bias-disable; - }; - }; - - spi_ss0_pins: spi-ss0 { - mux { - groups = "spi_ss0"; - function = "spi"; - bias-disable; - }; - }; - - sdcard_pins: sdcard { - mux-0 { - groups = "sdcard_d0", - "sdcard_d1", - "sdcard_d2", - "sdcard_d3", - "sdcard_cmd"; - function = "sdcard"; - bias-pull-up; - }; - - mux-1 { - groups = "sdcard_clk"; - function = "sdcard"; - bias-disable; - }; - }; - - sdcard_clk_gate_pins: sdcard_clk_gate { - mux { - groups = "CARD_2"; - function = "gpio_periphs"; - bias-pull-down; - }; - }; - - sdio_pins: sdio { - mux-0 { - groups = "sdio_d0", - "sdio_d1", - "sdio_d2", - "sdio_d3", - "sdio_cmd"; - function = "sdio"; - bias-pull-up; - }; - - mux-1 { - groups = "sdio_clk"; - function = "sdio"; - bias-disable; - }; - }; - - sdio_clk_gate_pins: sdio_clk_gate { - mux { - groups = "GPIOX_4"; - function = "gpio_periphs"; - bias-pull-down; - }; - }; - - sdio_irq_pins: sdio_irq { - mux { - groups = "sdio_irq"; - function = "sdio"; - bias-disable; - }; - }; - - uart_a_pins: uart_a { - mux { - groups = "uart_tx_a", - "uart_rx_a"; - function = "uart_a"; - bias-disable; - }; - }; - - uart_a_cts_rts_pins: uart_a_cts_rts { - mux { - groups = "uart_cts_a", - "uart_rts_a"; - function = "uart_a"; - bias-disable; - }; - }; - - uart_b_pins: uart_b { - mux { - groups = "uart_tx_b", - "uart_rx_b"; - function = "uart_b"; - bias-disable; - }; - }; - - uart_b_cts_rts_pins: uart_b_cts_rts { - mux { - groups = "uart_cts_b", - "uart_rts_b"; - function = "uart_b"; - bias-disable; - }; - }; - - uart_c_pins: uart_c { - mux { - groups = "uart_tx_c", - "uart_rx_c"; - function = "uart_c"; - bias-disable; - }; - }; - - uart_c_cts_rts_pins: uart_c_cts_rts { - mux { - groups = "uart_cts_c", - "uart_rts_c"; - function = "uart_c"; - bias-disable; - }; - }; - - i2c_a_pins: i2c_a { - mux { - groups = "i2c_sck_a", - "i2c_sda_a"; - function = "i2c_a"; - bias-disable; - }; - }; - - i2c_b_pins: i2c_b { - mux { - groups = "i2c_sck_b", - "i2c_sda_b"; - function = "i2c_b"; - bias-disable; - }; - }; - - i2c_c_pins: i2c_c { - mux { - groups = "i2c_sck_c", - "i2c_sda_c"; - function = "i2c_c"; - bias-disable; - }; - }; - - eth_rgmii_pins: eth-rgmii { - mux { - groups = "eth_mdio", - "eth_mdc", - "eth_clk_rx_clk", - "eth_rx_dv", - "eth_rxd0", - "eth_rxd1", - "eth_rxd2", - "eth_rxd3", - "eth_rgmii_tx_clk", - "eth_tx_en", - "eth_txd0", - "eth_txd1", - "eth_txd2", - "eth_txd3"; - function = "eth"; - bias-disable; - }; - }; - - eth_rmii_pins: eth-rmii { - mux { - groups = "eth_mdio", - "eth_mdc", - "eth_clk_rx_clk", - "eth_rx_dv", - "eth_rxd0", - "eth_rxd1", - "eth_tx_en", - "eth_txd0", - "eth_txd1"; - function = "eth"; - bias-disable; - }; - }; - - pwm_a_x_pins: pwm_a_x { - mux { - groups = "pwm_a_x"; - function = "pwm_a_x"; - bias-disable; - }; - }; - - pwm_a_y_pins: pwm_a_y { - mux { - groups = "pwm_a_y"; - function = "pwm_a_y"; - bias-disable; - }; - }; - - pwm_b_pins: pwm_b { - mux { - groups = "pwm_b"; - function = "pwm_b"; - bias-disable; - }; - }; - - pwm_d_pins: pwm_d { - mux { - groups = "pwm_d"; - function = "pwm_d"; - bias-disable; - }; - }; - - pwm_e_pins: pwm_e { - mux { - groups = "pwm_e"; - function = "pwm_e"; - bias-disable; - }; - }; - - pwm_f_x_pins: pwm_f_x { - mux { - groups = "pwm_f_x"; - function = "pwm_f_x"; - bias-disable; - }; - }; - - pwm_f_y_pins: pwm_f_y { - mux { - groups = "pwm_f_y"; - function = "pwm_f_y"; - bias-disable; - }; - }; - - hdmi_hpd_pins: hdmi_hpd { - mux { - groups = "hdmi_hpd"; - function = "hdmi_hpd"; - bias-disable; - }; - }; - - hdmi_i2c_pins: hdmi_i2c { - mux { - groups = "hdmi_sda", "hdmi_scl"; - function = "hdmi_i2c"; - bias-disable; - }; - }; - - i2sout_ch23_y_pins: i2sout_ch23_y { - mux { - groups = "i2sout_ch23_y"; - function = "i2s_out"; - bias-disable; - }; - }; - - i2sout_ch45_y_pins: i2sout_ch45_y { - mux { - groups = "i2sout_ch45_y"; - function = "i2s_out"; - bias-disable; - }; - }; - - i2sout_ch67_y_pins: i2sout_ch67_y { - mux { - groups = "i2sout_ch67_y"; - function = "i2s_out"; - bias-disable; - }; - }; - - spdif_out_y_pins: spdif_out_y { - mux { - groups = "spdif_out_y"; - function = "spdif_out"; - bias-disable; - }; - }; - }; -}; - -&pwrc { - resets = <&reset RESET_VIU>, - <&reset RESET_VENC>, - <&reset RESET_VCBUS>, - <&reset RESET_BT656>, - <&reset RESET_DVIN_RESET>, - <&reset RESET_RDMA>, - <&reset RESET_VENCI>, - <&reset RESET_VENCP>, - <&reset RESET_VDAC>, - <&reset RESET_VDI6>, - <&reset RESET_VENCL>, - <&reset RESET_VID_LOCK>; - reset-names = "viu", "venc", "vcbus", "bt656", - "dvin", "rdma", "venci", "vencp", - "vdac", "vdi6", "vencl", "vid_lock"; - clocks = <&clkc CLKID_VPU>, - <&clkc CLKID_VAPB>; - clock-names = "vpu", "vapb"; - /* - * VPU clocking is provided by two identical clock paths - * VPU_0 and VPU_1 muxed to a single clock by a glitch - * free mux to safely change frequency while running. - * Same for VAPB but with a final gate after the glitch free mux. - */ - assigned-clocks = <&clkc CLKID_VPU_0_SEL>, - <&clkc CLKID_VPU_0>, - <&clkc CLKID_VPU>, /* Glitch free mux */ - <&clkc CLKID_VAPB_0_SEL>, - <&clkc CLKID_VAPB_0>, - <&clkc CLKID_VAPB_SEL>; /* Glitch free mux */ - assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>, - <0>, /* Do Nothing */ - <&clkc CLKID_VPU_0>, - <&clkc CLKID_FCLK_DIV4>, - <0>, /* Do Nothing */ - <&clkc CLKID_VAPB_0>; - assigned-clock-rates = <0>, /* Do Nothing */ - <666666666>, - <0>, /* Do Nothing */ - <0>, /* Do Nothing */ - <250000000>, - <0>; /* Do Nothing */ -}; - -&saradc { - compatible = "amlogic,meson-gxbb-saradc", "amlogic,meson-saradc"; - clocks = <&xtal>, - <&clkc CLKID_SAR_ADC>, - <&clkc CLKID_SAR_ADC_CLK>, - <&clkc CLKID_SAR_ADC_SEL>; - clock-names = "clkin", "core", "adc_clk", "adc_sel"; -}; - -&sd_emmc_a { - clocks = <&clkc CLKID_SD_EMMC_A>, - <&clkc CLKID_SD_EMMC_A_CLK0>, - <&clkc CLKID_FCLK_DIV2>; - clock-names = "core", "clkin0", "clkin1"; - resets = <&reset RESET_SD_EMMC_A>; -}; - -&sd_emmc_b { - clocks = <&clkc CLKID_SD_EMMC_B>, - <&clkc CLKID_SD_EMMC_B_CLK0>, - <&clkc CLKID_FCLK_DIV2>; - clock-names = "core", "clkin0", "clkin1"; - resets = <&reset RESET_SD_EMMC_B>; -}; - -&sd_emmc_c { - clocks = <&clkc CLKID_SD_EMMC_C>, - <&clkc CLKID_SD_EMMC_C_CLK0>, - <&clkc CLKID_FCLK_DIV2>; - clock-names = "core", "clkin0", "clkin1"; - resets = <&reset RESET_SD_EMMC_C>; -}; - -&simplefb_hdmi { - clocks = <&clkc CLKID_HDMI_PCLK>, - <&clkc CLKID_CLK81>, - <&clkc CLKID_GCLK_VENCI_INT0>; -}; - -&spicc { - clocks = <&clkc CLKID_SPICC>; - clock-names = "core"; - resets = <&reset RESET_PERIPHS_SPICC>; - num-cs = <1>; -}; - -&spifc { - clocks = <&clkc CLKID_SPI>; -}; - -&uart_A { - clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&uart_AO { - clocks = <&xtal>, <&clkc_AO CLKID_AO_UART1>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&uart_AO_B { - clocks = <&xtal>, <&clkc_AO CLKID_AO_UART2>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&uart_B { - clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&uart_C { - clocks = <&xtal>, <&clkc CLKID_UART2>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&vpu { - compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu"; - power-domains = <&pwrc PWRC_GXBB_VPU_ID>; -}; - -&vdec { - compatible = "amlogic,gxbb-vdec", "amlogic,gx-vdec"; - clocks = <&clkc CLKID_DOS_PARSER>, - <&clkc CLKID_DOS>, - <&clkc CLKID_VDEC_1>, - <&clkc CLKID_VDEC_HEVC>; - clock-names = "dos_parser", "dos", "vdec_1", "vdec_hevc"; - resets = <&reset RESET_PARSER>; - reset-names = "esparser"; -};
On 12/28/23 12:57, Sumit Garg wrote:
Changes in v3:
- Patch #4: Minor commit message update
- Patch #5: Replace CONFIG_* with Kconfig options
- Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
- Patch #1, #3, #6 and #8: Picked up review tags
Changes in v2:
- Patch #1: excluded gitab CI config check and added commit description.
- Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/
- Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
- Patch #5: s/U-boot/U-Boot/
- Patch #6 and #7: Picked up review tags
Prerequisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-Boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
Background
This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-Boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained.
However, Linux kernel DT maintainers proposed [2] for U-Boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel.
In order to maintain devicetree files sync, U-Boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows:
$ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash
The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-Boot maintainers here [4]. Now we would like to reach out to wider U-Boot community to seek feedback.
[1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+... [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9j... [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... [4] https://github.com/u-boot/u-boot/pull/451
Changes
Traditionally, U-Boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via:
CONFIG_DEFAULT_DEVICE_TREE "<name>"
SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via:
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8.
Devicetree bindings schema checks
With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-Boot to run devicetree bindings schema checks which will bring compliance to U-Boot core/drivers regarding usage of devicetree.
Dependencies
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:
$ pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems:
$ apt install swig python3-dev
Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default).
Recommended is also to install yamllint (used by dtschema when present).
Running checks
In order to perform validation of DTB files, use the ``dtbs_check`` target:
$ make dtbs_check
I have been following your guidance here and I have also seen it to work but not sure why. Anyway I have strong suspicious that any Makefile rule is not right.
I am getting this issue.
/bin/sh: line 1: @: command not found make[1]: *** [devicetree-rebasing/Bindings/Makefile:68: devicetree-rebasing/Bindings/processed-schema.json] Error 127 make: *** [Makefile:1181: dt_binding_check] Error 2
devicetree-rebasing/Bindings/processed-schema.json is not generated properly
I am using the latest dt schema $ dt-validate -V 2023.12.dev6+gfb80ec43c204
and no issue to run it from Linux source code that's why I expect it is not issue with my PC in general. Do you know what can be wrong?
Thanks, Michal
Hi Michal,
On Wed, 3 Jan 2024 at 18:24, Michal Simek michal.simek@amd.com wrote:
On 12/28/23 12:57, Sumit Garg wrote:
Changes in v3:
- Patch #4: Minor commit message update
- Patch #5: Replace CONFIG_* with Kconfig options
- Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
- Patch #1, #3, #6 and #8: Picked up review tags
Changes in v2:
- Patch #1: excluded gitab CI config check and added commit description.
- Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/
- Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
- Patch #5: s/U-boot/U-Boot/
- Patch #6 and #7: Picked up review tags
Prerequisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-Boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
Background
This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-Boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained.
However, Linux kernel DT maintainers proposed [2] for U-Boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel.
In order to maintain devicetree files sync, U-Boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows:
$ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash
The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-Boot maintainers here [4]. Now we would like to reach out to wider U-Boot community to seek feedback.
[1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+... [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9j... [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... [4] https://github.com/u-boot/u-boot/pull/451
Changes
Traditionally, U-Boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via:
CONFIG_DEFAULT_DEVICE_TREE "<name>"
SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via:
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8.
Devicetree bindings schema checks
With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-Boot to run devicetree bindings schema checks which will bring compliance to U-Boot core/drivers regarding usage of devicetree.
Dependencies
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:
$ pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems:
$ apt install swig python3-dev
Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default).
Recommended is also to install yamllint (used by dtschema when present).
Running checks
In order to perform validation of DTB files, use the ``dtbs_check`` target:
$ make dtbs_check
I have been following your guidance here and I have also seen it to work but not sure why. Anyway I have strong suspicious that any Makefile rule is not right.
Thanks for taking time to test DT schema checks. It looks like your suspicion is correct.
I am getting this issue.
/bin/sh: line 1: @: command not found make[1]: *** [devicetree-rebasing/Bindings/Makefile:68: devicetree-rebasing/Bindings/processed-schema.json] Error 127 make: *** [Makefile:1181: dt_binding_check] Error 2
I was able to reproduce this issue once I installed yamllint on my Ubuntu machine.
devicetree-rebasing/Bindings/processed-schema.json is not generated properly
I am using the latest dt schema $ dt-validate -V 2023.12.dev6+gfb80ec43c204
and no issue to run it from Linux source code that's why I expect it is not issue with my PC in general. Do you know what can be wrong?
The issue here is basically due to old U-Boot Kbuild infrastructure which isn't in sync with Linux kernel. This Kbuild commit [1] changes aren't present in U-Boot leading to this issue.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Following change to adapt bindings Makefile to old U-Boot Kbuild expectation should resolve this issue:
diff --git a/devicetree-rebasing/Bindings/Makefile b/devicetree-rebasing/Bindings/Makefile index 8b395893bd8..7d08372691c 100644 --- a/devicetree-rebasing/Bindings/Makefile +++ b/devicetree-rebasing/Bindings/Makefile @@ -47,9 +47,9 @@ quiet_cmd_mk_schema = SCHEMA $@ rm -f $$f
define rule_chkdt - $(if $(DT_SCHEMA_LINT),$(call cmd,yamllint),) - $(call cmd,chk_bindings) - $(call cmd,mk_schema) + $(if $(DT_SCHEMA_LINT),$(call echo-cmd,yamllint) $(cmd_yamllint),); \ + $(call echo-cmd,chk_bindings) $(cmd_chk_bindings); \ + $(call echo-cmd,mk_schema) $(cmd_mk_schema) endef
DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd)))
If this works for you then I will include it as a separate patch for v4.
-Sumit
Thanks, Michal
Hi,
On 1/4/24 09:18, Sumit Garg wrote:
Hi Michal,
On Wed, 3 Jan 2024 at 18:24, Michal Simek michal.simek@amd.com wrote:
On 12/28/23 12:57, Sumit Garg wrote:
Changes in v3:
- Patch #4: Minor commit message update
- Patch #5: Replace CONFIG_* with Kconfig options
- Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
- Patch #1, #3, #6 and #8: Picked up review tags
Changes in v2:
- Patch #1: excluded gitab CI config check and added commit description.
- Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/
- Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
- Patch #5: s/U-boot/U-Boot/
- Patch #6 and #7: Picked up review tags
Prerequisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-Boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
Background
This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-Boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained.
However, Linux kernel DT maintainers proposed [2] for U-Boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel.
In order to maintain devicetree files sync, U-Boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows:
$ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash
The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-Boot maintainers here [4]. Now we would like to reach out to wider U-Boot community to seek feedback.
[1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+... [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9j... [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... [4] https://github.com/u-boot/u-boot/pull/451
Changes
Traditionally, U-Boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via:
CONFIG_DEFAULT_DEVICE_TREE "<name>"
SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via:
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8.
Devicetree bindings schema checks
With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-Boot to run devicetree bindings schema checks which will bring compliance to U-Boot core/drivers regarding usage of devicetree.
Dependencies
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:
$ pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems:
$ apt install swig python3-dev
Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default).
Recommended is also to install yamllint (used by dtschema when present).
Running checks
In order to perform validation of DTB files, use the ``dtbs_check`` target:
$ make dtbs_check
I have been following your guidance here and I have also seen it to work but not sure why. Anyway I have strong suspicious that any Makefile rule is not right.
Thanks for taking time to test DT schema checks. It looks like your suspicion is correct.
I am getting this issue.
/bin/sh: line 1: @: command not found make[1]: *** [devicetree-rebasing/Bindings/Makefile:68: devicetree-rebasing/Bindings/processed-schema.json] Error 127 make: *** [Makefile:1181: dt_binding_check] Error 2
I was able to reproduce this issue once I installed yamllint on my Ubuntu machine.
devicetree-rebasing/Bindings/processed-schema.json is not generated properly
I am using the latest dt schema $ dt-validate -V 2023.12.dev6+gfb80ec43c204
and no issue to run it from Linux source code that's why I expect it is not issue with my PC in general. Do you know what can be wrong?
The issue here is basically due to old U-Boot Kbuild infrastructure which isn't in sync with Linux kernel. This Kbuild commit [1] changes aren't present in U-Boot leading to this issue.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Following change to adapt bindings Makefile to old U-Boot Kbuild expectation should resolve this issue:
diff --git a/devicetree-rebasing/Bindings/Makefile b/devicetree-rebasing/Bindings/Makefile index 8b395893bd8..7d08372691c 100644 --- a/devicetree-rebasing/Bindings/Makefile +++ b/devicetree-rebasing/Bindings/Makefile @@ -47,9 +47,9 @@ quiet_cmd_mk_schema = SCHEMA $@ rm -f $$f
define rule_chkdt
$(if $(DT_SCHEMA_LINT),$(call cmd,yamllint),)$(call cmd,chk_bindings)$(call cmd,mk_schema)
$(if $(DT_SCHEMA_LINT),$(call echo-cmd,yamllint) $(cmd_yamllint),); \$(call echo-cmd,chk_bindings) $(cmd_chk_bindings); \$(call echo-cmd,mk_schema) $(cmd_mk_schema)endef
DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd)))
If this works for you then I will include it as a separate patch for v4.
yes that works.
Thanks, Michal
participants (9)
-
Bryan Brattlof -
Caleb Connolly -
Ilias Apalodimas -
Mark Kettenis -
Michal Simek -
Rob Herring -
Simon Glass -
Sumit Garg -
Tom Rini