Hi Sumit,
On Wed, Dec 20, 2023 at 12:01 PM Sumit Garg sumit.garg@linaro.org wrote:
Hi Simon,
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, 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.
I suppose you are referring to dts/arch/arm64/Makefile which has been added by this patch.
Yes, I just mean that you should mention this in the commit message
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
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..96396f12b67 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 devicetreeU-Boot
(I think I mentioned this, but you thought I said U-boot...but it really is U-Boot). Perhaps grep your patches next time.
Ah, I see. It looks like I missed that bit, and will take care of it in the next revision.
files 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.I'm a bit nervous about this. It means that boards chose between this dir of the local files. It means there is some effort to switch.
I wonder if we could default to using the rebasing thing, with boards having to 'opt out'? So this should be 'default y' ?
Ideally that should be our migration path going forward once we get enough boards migrated to use rebasing repo. But at this initial stage we have to put some effort on migrating boards to use rebasing subtree, although effort should be just adding (given DT bindings compliance) following to defconfig (see patch #7):
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
and create a mirrored copy of: ../../../devicetree-rebasing/src/arm64/amlogic/ into dts/arch/arm64/amlogic/ with modifications to add targets to dts/arch/arm64/Makefile.
I am happy to put in that effort but certainly for new board support that would like to import DT from Linux it should be the default. That stands true for the Qcom platform series for which Caleb is currently working on.
The problem I see is that this is board-by-board, so will never happen. Changing one board (e.g. rockpro64-rk3399) typically involves changing the .dtsi files it includes (e.g. rk3399.dtsi) so it is hard/impossible to do one board without doing all.
So this is why I believe the setting should be on an SoC basis, not on a board basis.
choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..8098bf8191a 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) +DEVICE_TREE_LOC := dts/arch/arm64
dt_dir ?
Okay I will rename it.
Should we move the arm64 DTs to arch/arm64 ?
IMO, the migration path should be to use rebasing subtree via dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems like a redundant change to me.
I can see that argument, but having two different directory structures would be confusing.
What about the subdirs used in Linux?
I hope I have described above regarding how subdirs are mirrored. However, have a look at patch #7 for the amlogic/ subdir example.
OK
Regards, Simon