OF_UPSTREAM vs. additional dtbs
Hi all,
I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm facing issues because I need to still build the u-boot-only overlays. It is also a bit weird (but works) having to specify
CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
for our spl dtb.
Are there means to still build certain dtb[o] files in arch/<arch>/dts? I'm a bit lost in the Makefile forest.
Thanks, Jan
On 11:16-20240813, Jan Kiszka wrote:
Hi all,
I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm facing issues because I need to still build the u-boot-only overlays. It is also a bit weird (but works) having to specify
CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
for our spl dtb.
Are there means to still build certain dtb[o] files in arch/<arch>/dts? I'm a bit lost in the Makefile forest.
Sumit: Any suggestions?
On 13.08.24 14:52, Nishanth Menon wrote:
On 11:16-20240813, Jan Kiszka wrote:
Hi all,
I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm facing issues because I need to still build the u-boot-only overlays. It is also a bit weird (but works) having to specify
CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
Actually, this does NOT work: I just had a long morning debugging SPL which no longer started because it picked the non-filtered dtb. The filtered one ended up in a folder outside of the u-boot sources because of all those ../ and hard-wiring to dts/upstream.
for our spl dtb.
Are there means to still build certain dtb[o] files in arch/<arch>/dts? I'm a bit lost in the Makefile forest.
Sumit: Any suggestions?
I would really like to hear some better proposals than my local workarounds to far. They don't converge although I already patched some core Makefile (overlays are building now).
Jan
On 14.08.24 11:41, Jan Kiszka wrote:
On 13.08.24 14:52, Nishanth Menon wrote:
On 11:16-20240813, Jan Kiszka wrote:
Hi all,
I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm facing issues because I need to still build the u-boot-only overlays. It is also a bit weird (but works) having to specify
CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
Actually, this does NOT work: I just had a long morning debugging SPL which no longer started because it picked the non-filtered dtb. The filtered one ended up in a folder outside of the u-boot sources because of all those ../ and hard-wiring to dts/upstream.
for our spl dtb.
Are there means to still build certain dtb[o] files in arch/<arch>/dts? I'm a bit lost in the Makefile forest.
Sumit: Any suggestions?
I would really like to hear some better proposals than my local workarounds to far. They don't converge although I already patched some core Makefile (overlays are building now).
OK, I side-stepped the spl issue by using one of our variant DTBs for spl as well - happens to work.
For the overlays, I need to add
--- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/config.mk + dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
in order to then be able to do
--- a/board/siemens/iot2050/config.mk +++ b/board/siemens/iot2050/config.mk @@ -5,4 +5,12 @@ # Authors: # Jan Kiszka jan.kiszka@siemens.com
+ifneq ($(CONFIG_SPL_BUILD),y) +dtbo-list = \ + k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \ + k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay + +dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) +endif + flash.bin: all
Does that make sense?
Jan
Hi,
On Wed, 14 Aug 2024 at 22:14, Jan Kiszka jan.kiszka@siemens.com wrote:
On 14.08.24 11:41, Jan Kiszka wrote:
On 13.08.24 14:52, Nishanth Menon wrote:
On 11:16-20240813, Jan Kiszka wrote:
Hi all,
I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm facing issues because I need to still build the u-boot-only overlays. It is also a bit weird (but works) having to specify
CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
Actually, this does NOT work: I just had a long morning debugging SPL which no longer started because it picked the non-filtered dtb. The filtered one ended up in a folder outside of the u-boot sources because of all those ../ and hard-wiring to dts/upstream.
for our spl dtb.
Are there means to still build certain dtb[o] files in arch/<arch>/dts? I'm a bit lost in the Makefile forest.
Sumit: Any suggestions?
Apologies for the delayed reply. I was a bit busy with other high priority stuff.
I would really like to hear some better proposals than my local workarounds to far. They don't converge although I already patched some core Makefile (overlays are building now).
OK, I side-stepped the spl issue by using one of our variant DTBs for spl as well - happens to work.
That's good to know.
For the overlays, I need to add
--- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/config.mk
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
in order to then be able to do
--- a/board/siemens/iot2050/config.mk +++ b/board/siemens/iot2050/config.mk @@ -5,4 +5,12 @@ # Authors: # Jan Kiszka jan.kiszka@siemens.com
+ifneq ($(CONFIG_SPL_BUILD),y) +dtbo-list = \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay+dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) +endif
flash.bin: all
Does that make sense?
A switch to OF_UPSTREAM means that we build all the DT artifacts from dts/upstream/src/ directory with the only exception that we include U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In case of overlays, is there any reason for IOT2050 board overlays not being pushed into Linux kernel repo? AFAIU, overlays are also describing puggable hardware so they shouldn't be referred to as "u-boot-only" overlays.
-Sumit
Jan
-- Siemens AG, Technology Linux Expert Center
On 26.08.24 08:44, Sumit Garg wrote:
Hi,
On Wed, 14 Aug 2024 at 22:14, Jan Kiszka jan.kiszka@siemens.com wrote:
On 14.08.24 11:41, Jan Kiszka wrote:
On 13.08.24 14:52, Nishanth Menon wrote:
On 11:16-20240813, Jan Kiszka wrote:
Hi all,
I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm facing issues because I need to still build the u-boot-only overlays. It is also a bit weird (but works) having to specify
CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
Actually, this does NOT work: I just had a long morning debugging SPL which no longer started because it picked the non-filtered dtb. The filtered one ended up in a folder outside of the u-boot sources because of all those ../ and hard-wiring to dts/upstream.
for our spl dtb.
Are there means to still build certain dtb[o] files in arch/<arch>/dts? I'm a bit lost in the Makefile forest.
Sumit: Any suggestions?
Apologies for the delayed reply. I was a bit busy with other high priority stuff.
I would really like to hear some better proposals than my local workarounds to far. They don't converge although I already patched some core Makefile (overlays are building now).
OK, I side-stepped the spl issue by using one of our variant DTBs for spl as well - happens to work.
That's good to know.
For the overlays, I need to add
--- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/config.mk
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
in order to then be able to do
--- a/board/siemens/iot2050/config.mk +++ b/board/siemens/iot2050/config.mk @@ -5,4 +5,12 @@ # Authors: # Jan Kiszka jan.kiszka@siemens.com
+ifneq ($(CONFIG_SPL_BUILD),y) +dtbo-list = \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay+dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) +endif
flash.bin: all
Does that make sense?
A switch to OF_UPSTREAM means that we build all the DT artifacts from dts/upstream/src/ directory with the only exception that we include U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In case of overlays, is there any reason for IOT2050 board overlays not being pushed into Linux kernel repo? AFAIU, overlays are also describing puggable hardware so they shouldn't be referred to as "u-boot-only" overlays.
We are using the overlay to massage the DT presented to the OS based on firmware configuration. So, those two belong to the firmware logically, but - with some disclaimers, we could also try to upstream them.
Jan
On Mon, 26 Aug 2024 at 12:19, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 08:44, Sumit Garg wrote:
Hi,
On Wed, 14 Aug 2024 at 22:14, Jan Kiszka jan.kiszka@siemens.com wrote:
On 14.08.24 11:41, Jan Kiszka wrote:
On 13.08.24 14:52, Nishanth Menon wrote:
On 11:16-20240813, Jan Kiszka wrote:
Hi all,
I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm facing issues because I need to still build the u-boot-only overlays. It is also a bit weird (but works) having to specify
CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
Actually, this does NOT work: I just had a long morning debugging SPL which no longer started because it picked the non-filtered dtb. The filtered one ended up in a folder outside of the u-boot sources because of all those ../ and hard-wiring to dts/upstream.
for our spl dtb.
Are there means to still build certain dtb[o] files in arch/<arch>/dts? I'm a bit lost in the Makefile forest.
Sumit: Any suggestions?
Apologies for the delayed reply. I was a bit busy with other high priority stuff.
I would really like to hear some better proposals than my local workarounds to far. They don't converge although I already patched some core Makefile (overlays are building now).
OK, I side-stepped the spl issue by using one of our variant DTBs for spl as well - happens to work.
That's good to know.
For the overlays, I need to add
--- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/config.mk
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
in order to then be able to do
--- a/board/siemens/iot2050/config.mk +++ b/board/siemens/iot2050/config.mk @@ -5,4 +5,12 @@ # Authors: # Jan Kiszka jan.kiszka@siemens.com
+ifneq ($(CONFIG_SPL_BUILD),y) +dtbo-list = \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay+dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) +endif
flash.bin: all
Does that make sense?
A switch to OF_UPSTREAM means that we build all the DT artifacts from dts/upstream/src/ directory with the only exception that we include U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In case of overlays, is there any reason for IOT2050 board overlays not being pushed into Linux kernel repo? AFAIU, overlays are also describing puggable hardware so they shouldn't be referred to as "u-boot-only" overlays.
We are using the overlay to massage the DT presented to the OS based on firmware configuration.
Agree and more than that I prefer the firmware to own the overall DT and present that to the OS.
So, those two belong to the firmware logically, but - with some disclaimers, we could also try to upstream them.
For historical reasons, Linux kernel source tree has become the defacto upstream repo for DT sources. So it's better to contribute there and sync back in U-Boot.
-Sumit
Jan
-- Siemens AG, Technology Linux Expert Center
On 26.08.24 09:10, Sumit Garg wrote:
On Mon, 26 Aug 2024 at 12:19, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 08:44, Sumit Garg wrote:
Hi,
On Wed, 14 Aug 2024 at 22:14, Jan Kiszka jan.kiszka@siemens.com wrote:
On 14.08.24 11:41, Jan Kiszka wrote:
On 13.08.24 14:52, Nishanth Menon wrote:
On 11:16-20240813, Jan Kiszka wrote: > Hi all, > > I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm > facing issues because I need to still build the u-boot-only overlays. It > is also a bit weird (but works) having to specify > > CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl" >
Actually, this does NOT work: I just had a long morning debugging SPL which no longer started because it picked the non-filtered dtb. The filtered one ended up in a folder outside of the u-boot sources because of all those ../ and hard-wiring to dts/upstream.
> for our spl dtb. > > Are there means to still build certain dtb[o] files in arch/<arch>/dts? > I'm a bit lost in the Makefile forest. >
Sumit: Any suggestions?
Apologies for the delayed reply. I was a bit busy with other high priority stuff.
I would really like to hear some better proposals than my local workarounds to far. They don't converge although I already patched some core Makefile (overlays are building now).
OK, I side-stepped the spl issue by using one of our variant DTBs for spl as well - happens to work.
That's good to know.
For the overlays, I need to add
--- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/config.mk
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
in order to then be able to do
--- a/board/siemens/iot2050/config.mk +++ b/board/siemens/iot2050/config.mk @@ -5,4 +5,12 @@ # Authors: # Jan Kiszka jan.kiszka@siemens.com
+ifneq ($(CONFIG_SPL_BUILD),y) +dtbo-list = \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay+dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) +endif
flash.bin: all
Does that make sense?
A switch to OF_UPSTREAM means that we build all the DT artifacts from dts/upstream/src/ directory with the only exception that we include U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In case of overlays, is there any reason for IOT2050 board overlays not being pushed into Linux kernel repo? AFAIU, overlays are also describing puggable hardware so they shouldn't be referred to as "u-boot-only" overlays.
We are using the overlay to massage the DT presented to the OS based on firmware configuration.
Agree and more than that I prefer the firmware to own the overall DT and present that to the OS.
So, those two belong to the firmware logically, but - with some disclaimers, we could also try to upstream them.
For historical reasons, Linux kernel source tree has become the defacto upstream repo for DT sources. So it's better to contribute there and sync back in U-Boot.
Will do ASAP, hope to hit at least 6.12 then.
Still, this will delay our next patches for U-Boot by many months. Also for that reason, a plan B for U-Boot local DTs should remain, no left-or-right policy.
Jan
On Mon, 26 Aug 2024 at 18:02, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 09:10, Sumit Garg wrote:
On Mon, 26 Aug 2024 at 12:19, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 08:44, Sumit Garg wrote:
Hi,
On Wed, 14 Aug 2024 at 22:14, Jan Kiszka jan.kiszka@siemens.com wrote:
On 14.08.24 11:41, Jan Kiszka wrote:
On 13.08.24 14:52, Nishanth Menon wrote: > On 11:16-20240813, Jan Kiszka wrote: >> Hi all, >> >> I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm >> facing issues because I need to still build the u-boot-only overlays. It >> is also a bit weird (but works) having to specify >> >> CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl" >>
Actually, this does NOT work: I just had a long morning debugging SPL which no longer started because it picked the non-filtered dtb. The filtered one ended up in a folder outside of the u-boot sources because of all those ../ and hard-wiring to dts/upstream.
>> for our spl dtb. >> >> Are there means to still build certain dtb[o] files in arch/<arch>/dts? >> I'm a bit lost in the Makefile forest. >> > > Sumit: Any suggestions? >
Apologies for the delayed reply. I was a bit busy with other high priority stuff.
I would really like to hear some better proposals than my local workarounds to far. They don't converge although I already patched some core Makefile (overlays are building now).
OK, I side-stepped the spl issue by using one of our variant DTBs for spl as well - happens to work.
That's good to know.
For the overlays, I need to add
--- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/config.mk
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
in order to then be able to do
--- a/board/siemens/iot2050/config.mk +++ b/board/siemens/iot2050/config.mk @@ -5,4 +5,12 @@ # Authors: # Jan Kiszka jan.kiszka@siemens.com
+ifneq ($(CONFIG_SPL_BUILD),y) +dtbo-list = \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay+dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) +endif
flash.bin: all
Does that make sense?
A switch to OF_UPSTREAM means that we build all the DT artifacts from dts/upstream/src/ directory with the only exception that we include U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In case of overlays, is there any reason for IOT2050 board overlays not being pushed into Linux kernel repo? AFAIU, overlays are also describing puggable hardware so they shouldn't be referred to as "u-boot-only" overlays.
We are using the overlay to massage the DT presented to the OS based on firmware configuration.
Agree and more than that I prefer the firmware to own the overall DT and present that to the OS.
So, those two belong to the firmware logically, but - with some disclaimers, we could also try to upstream them.
For historical reasons, Linux kernel source tree has become the defacto upstream repo for DT sources. So it's better to contribute there and sync back in U-Boot.
Will do ASAP, hope to hit at least 6.12 then.
Still, this will delay our next patches for U-Boot by many months. Also for that reason, a plan B for U-Boot local DTs should remain, no left-or-right policy.
Yeah, the U-Boot local DTs should be used until the board is fully supported by the dts/upstream directory.
-Sumit
Jan
-- Siemens AG, Technology Linux Expert Center
On 27.08.24 09:13, Sumit Garg wrote:
On Mon, 26 Aug 2024 at 18:02, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 09:10, Sumit Garg wrote:
On Mon, 26 Aug 2024 at 12:19, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 08:44, Sumit Garg wrote:
Hi,
On Wed, 14 Aug 2024 at 22:14, Jan Kiszka jan.kiszka@siemens.com wrote:
On 14.08.24 11:41, Jan Kiszka wrote: > On 13.08.24 14:52, Nishanth Menon wrote: >> On 11:16-20240813, Jan Kiszka wrote: >>> Hi all, >>> >>> I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm >>> facing issues because I need to still build the u-boot-only overlays. It >>> is also a bit weird (but works) having to specify >>> >>> CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl" >>> > > Actually, this does NOT work: I just had a long morning debugging SPL > which no longer started because it picked the non-filtered dtb. The > filtered one ended up in a folder outside of the u-boot sources because > of all those ../ and hard-wiring to dts/upstream. > >>> for our spl dtb. >>> >>> Are there means to still build certain dtb[o] files in arch/<arch>/dts? >>> I'm a bit lost in the Makefile forest. >>> >> >> Sumit: Any suggestions? >>
Apologies for the delayed reply. I was a bit busy with other high priority stuff.
> > I would really like to hear some better proposals than my local > workarounds to far. They don't converge although I already patched some > core Makefile (overlays are building now). >
OK, I side-stepped the spl issue by using one of our variant DTBs for spl as well - happens to work.
That's good to know.
For the overlays, I need to add
--- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/config.mk
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
in order to then be able to do
--- a/board/siemens/iot2050/config.mk +++ b/board/siemens/iot2050/config.mk @@ -5,4 +5,12 @@ # Authors: # Jan Kiszka jan.kiszka@siemens.com
+ifneq ($(CONFIG_SPL_BUILD),y) +dtbo-list = \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay+dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) +endif
flash.bin: all
Does that make sense?
A switch to OF_UPSTREAM means that we build all the DT artifacts from dts/upstream/src/ directory with the only exception that we include U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In case of overlays, is there any reason for IOT2050 board overlays not being pushed into Linux kernel repo? AFAIU, overlays are also describing puggable hardware so they shouldn't be referred to as "u-boot-only" overlays.
We are using the overlay to massage the DT presented to the OS based on firmware configuration.
Agree and more than that I prefer the firmware to own the overall DT and present that to the OS.
So, those two belong to the firmware logically, but - with some disclaimers, we could also try to upstream them.
For historical reasons, Linux kernel source tree has become the defacto upstream repo for DT sources. So it's better to contribute there and sync back in U-Boot.
Will do ASAP, hope to hit at least 6.12 then.
Still, this will delay our next patches for U-Boot by many months. Also for that reason, a plan B for U-Boot local DTs should remain, no left-or-right policy.
Yeah, the U-Boot local DTs should be used until the board is fully supported by the dts/upstream directory.
This is not what I mean and won't help: Given the longer pipeline, it should remain possible to carry also local changes after switching to OF_UPSTREAM and while waiting for upstreaming to be done - if ever. We are missing middle ground.
Jan
On Tue, 27 Aug 2024 at 15:05, Jan Kiszka jan.kiszka@siemens.com wrote:
On 27.08.24 09:13, Sumit Garg wrote:
On Mon, 26 Aug 2024 at 18:02, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 09:10, Sumit Garg wrote:
On Mon, 26 Aug 2024 at 12:19, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 08:44, Sumit Garg wrote:
Hi,
On Wed, 14 Aug 2024 at 22:14, Jan Kiszka jan.kiszka@siemens.com wrote: > > On 14.08.24 11:41, Jan Kiszka wrote: >> On 13.08.24 14:52, Nishanth Menon wrote: >>> On 11:16-20240813, Jan Kiszka wrote: >>>> Hi all, >>>> >>>> I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm >>>> facing issues because I need to still build the u-boot-only overlays. It >>>> is also a bit weird (but works) having to specify >>>> >>>> CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl" >>>> >> >> Actually, this does NOT work: I just had a long morning debugging SPL >> which no longer started because it picked the non-filtered dtb. The >> filtered one ended up in a folder outside of the u-boot sources because >> of all those ../ and hard-wiring to dts/upstream. >> >>>> for our spl dtb. >>>> >>>> Are there means to still build certain dtb[o] files in arch/<arch>/dts? >>>> I'm a bit lost in the Makefile forest. >>>> >>> >>> Sumit: Any suggestions? >>>
Apologies for the delayed reply. I was a bit busy with other high priority stuff.
>> >> I would really like to hear some better proposals than my local >> workarounds to far. They don't converge although I already patched some >> core Makefile (overlays are building now). >> > > OK, I side-stepped the spl issue by using one of our variant DTBs for > spl as well - happens to work.
That's good to know.
> > For the overlays, I need to add > > --- a/scripts/Makefile.dts > +++ b/scripts/Makefile.dts > @@ -1,5 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0+ > > +include $(srctree)/config.mk > + > dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) > > ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) > > > in order to then be able to do > > --- a/board/siemens/iot2050/config.mk > +++ b/board/siemens/iot2050/config.mk > @@ -5,4 +5,12 @@ > # Authors: > # Jan Kiszka jan.kiszka@siemens.com > > +ifneq ($(CONFIG_SPL_BUILD),y) > +dtbo-list = \ > + k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \ > + k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay > + > +dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) > +endif > + > flash.bin: all > > > Does that make sense?
A switch to OF_UPSTREAM means that we build all the DT artifacts from dts/upstream/src/ directory with the only exception that we include U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In case of overlays, is there any reason for IOT2050 board overlays not being pushed into Linux kernel repo? AFAIU, overlays are also describing puggable hardware so they shouldn't be referred to as "u-boot-only" overlays.
We are using the overlay to massage the DT presented to the OS based on firmware configuration.
Agree and more than that I prefer the firmware to own the overall DT and present that to the OS.
So, those two belong to the firmware logically, but - with some disclaimers, we could also try to upstream them.
For historical reasons, Linux kernel source tree has become the defacto upstream repo for DT sources. So it's better to contribute there and sync back in U-Boot.
Will do ASAP, hope to hit at least 6.12 then.
Still, this will delay our next patches for U-Boot by many months. Also for that reason, a plan B for U-Boot local DTs should remain, no left-or-right policy.
Yeah, the U-Boot local DTs should be used until the board is fully supported by the dts/upstream directory.
This is not what I mean and won't help: Given the longer pipeline, it should remain possible to carry also local changes after switching to OF_UPSTREAM and while waiting for upstreaming to be done - if ever. We are missing middle ground.
For local changes we already have the middle ground as *-u-boot.dtsi. Also, cherry-picking [1] from upstream rc* releases is pretty effective in shortening that pipeline. However, building DTB artifacts from multiple directories is going to make Makefiles messy and in turn will be difficult to be consumed by packaging tools like binman. Your Makefile change demonstrates it too. But if you can come up with a cleaner solution then I will be happy to review that.
[1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-...
-Sumit
Jan
-- Siemens AG, Technology Linux Expert Center
On 27.08.24 12:39, Sumit Garg wrote:
On Tue, 27 Aug 2024 at 15:05, Jan Kiszka jan.kiszka@siemens.com wrote:
On 27.08.24 09:13, Sumit Garg wrote:
On Mon, 26 Aug 2024 at 18:02, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 09:10, Sumit Garg wrote:
On Mon, 26 Aug 2024 at 12:19, Jan Kiszka jan.kiszka@siemens.com wrote:
On 26.08.24 08:44, Sumit Garg wrote: > Hi, > > On Wed, 14 Aug 2024 at 22:14, Jan Kiszka jan.kiszka@siemens.com wrote: >> >> On 14.08.24 11:41, Jan Kiszka wrote: >>> On 13.08.24 14:52, Nishanth Menon wrote: >>>> On 11:16-20240813, Jan Kiszka wrote: >>>>> Hi all, >>>>> >>>>> I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm >>>>> facing issues because I need to still build the u-boot-only overlays. It >>>>> is also a bit weird (but works) having to specify >>>>> >>>>> CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl" >>>>> >>> >>> Actually, this does NOT work: I just had a long morning debugging SPL >>> which no longer started because it picked the non-filtered dtb. The >>> filtered one ended up in a folder outside of the u-boot sources because >>> of all those ../ and hard-wiring to dts/upstream. >>> >>>>> for our spl dtb. >>>>> >>>>> Are there means to still build certain dtb[o] files in arch/<arch>/dts? >>>>> I'm a bit lost in the Makefile forest. >>>>> >>>> >>>> Sumit: Any suggestions? >>>> > > Apologies for the delayed reply. I was a bit busy with other high > priority stuff. > >>> >>> I would really like to hear some better proposals than my local >>> workarounds to far. They don't converge although I already patched some >>> core Makefile (overlays are building now). >>> >> >> OK, I side-stepped the spl issue by using one of our variant DTBs for >> spl as well - happens to work. > > That's good to know. > >> >> For the overlays, I need to add >> >> --- a/scripts/Makefile.dts >> +++ b/scripts/Makefile.dts >> @@ -1,5 +1,7 @@ >> # SPDX-License-Identifier: GPL-2.0+ >> >> +include $(srctree)/config.mk >> + >> dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) >> >> ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) >> >> >> in order to then be able to do >> >> --- a/board/siemens/iot2050/config.mk >> +++ b/board/siemens/iot2050/config.mk >> @@ -5,4 +5,12 @@ >> # Authors: >> # Jan Kiszka jan.kiszka@siemens.com >> >> +ifneq ($(CONFIG_SPL_BUILD),y) >> +dtbo-list = \ >> + k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \ >> + k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay >> + >> +dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) >> +endif >> + >> flash.bin: all >> >> >> Does that make sense? > > A switch to OF_UPSTREAM means that we build all the DT artifacts from > dts/upstream/src/ directory with the only exception that we include > U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In > case of overlays, is there any reason for IOT2050 board overlays not > being pushed into Linux kernel repo? AFAIU, overlays are also > describing puggable hardware so they shouldn't be referred to as > "u-boot-only" overlays.
We are using the overlay to massage the DT presented to the OS based on firmware configuration.
Agree and more than that I prefer the firmware to own the overall DT and present that to the OS.
So, those two belong to the firmware logically, but - with some disclaimers, we could also try to upstream them.
For historical reasons, Linux kernel source tree has become the defacto upstream repo for DT sources. So it's better to contribute there and sync back in U-Boot.
Will do ASAP, hope to hit at least 6.12 then.
Still, this will delay our next patches for U-Boot by many months. Also for that reason, a plan B for U-Boot local DTs should remain, no left-or-right policy.
Yeah, the U-Boot local DTs should be used until the board is fully supported by the dts/upstream directory.
This is not what I mean and won't help: Given the longer pipeline, it should remain possible to carry also local changes after switching to OF_UPSTREAM and while waiting for upstreaming to be done - if ever. We are missing middle ground.
For local changes we already have the middle ground as *-u-boot.dtsi. Also, cherry-picking [1] from upstream rc* releases is pretty effective in shortening that pipeline. However, building DTB artifacts from multiple directories is going to make Makefiles messy and in turn will be difficult to be consumed by packaging tools like binman. Your Makefile change demonstrates it too. But if you can come up with a cleaner solution then I will be happy to review that.
[1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-...
OK, our overlay sources are on their way into mainline, will only take until 6.12-rc1 to get them here. To accelerate the preparation, I ported that change to a local branch - just to find out that OF_UPSTREAM has no clue about DT overlays so far. And it is not just that there are no build rules for them (that was quickly fixed). It's also that there is no way to trigger their build for your u-boot proper.
Are there plans for addressing this? I'm inclined to revive my patch that allows to augment dtb-y from the board's config.mk. Better suggestions?
Jan
Gesendet: Mittwoch, 04. September 2024 um 19:16 Uhr Von: "Jan Kiszka" jan.kiszka@siemens.com OK, our overlay sources are on their way into mainline, will only take until 6.12-rc1 to get them here. To accelerate the preparation, I ported that change to a local branch - just to find out that OF_UPSTREAM has no clue about DT overlays so far. And it is not just that there are no build rules for them (that was quickly fixed). It's also that there is no way to trigger their build for your u-boot proper.
Are there plans for addressing this? I'm inclined to revive my patch that allows to augment dtb-y from the board's config.mk. Better suggestions?
Hi
i hang also on this part, in my case i build the dtbos for the vendor and try to use fdtoverlay to merge base-dt with the defined overlays.
see commits till July 11th
https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/
this fails because the target for fdtoverlays needs targets for the dtbos (have used the fdtoverlay target from linux)... but i build then without dedicated target (while building the basedt).
maybe you can help solving the "small" problem in makefile.
regards Frank
Jan
On 04.09.24 19:29, Frank Wunderlich wrote:
Gesendet: Mittwoch, 04. September 2024 um 19:16 Uhr Von: "Jan Kiszka" jan.kiszka@siemens.com OK, our overlay sources are on their way into mainline, will only take until 6.12-rc1 to get them here. To accelerate the preparation, I ported that change to a local branch - just to find out that OF_UPSTREAM has no clue about DT overlays so far. And it is not just that there are no build rules for them (that was quickly fixed). It's also that there is no way to trigger their build for your u-boot proper.
Are there plans for addressing this? I'm inclined to revive my patch that allows to augment dtb-y from the board's config.mk. Better suggestions?
Hi
i hang also on this part, in my case i build the dtbos for the vendor and try to use fdtoverlay to merge base-dt with the defined overlays.
see commits till July 11th
https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/
this fails because the target for fdtoverlays needs targets for the dtbos (have used the fdtoverlay target from linux)... but i build then without dedicated target (while building the basedt).
maybe you can help solving the "small" problem in makefile.
This is close but not quite the same scenario because I only need "our" dtbos, and there is no need to create dtbs with them applied (they will be used during dt fixup in our case).
What I've now done is this:
diff --git a/dts/Kconfig b/dts/Kconfig index 569d4be338e..7ea4fd5a79b 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -226,11 +226,11 @@ config OF_LIST
config OF_OVERLAY_LIST string "List of device tree overlays to include for DT control" - depends on SPL_LOAD_FIT_APPLY_OVERLAY help This option specifies a list of device tree overlays to use for DT control. This option can then be used by a FIT generator to include - the overlays in the FIT image. + the overlays in the FIT image or by binman when assembling an image + that uses overlays during DT fixup.
choice prompt "OF LIST compression" diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts index 790f3c508f1..dc181240a21 100644 --- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) +dtb-y += $(patsubst %,%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) ifeq ($(CONFIG_ARM64),y)
I will also provide a patch to enhance the machinery in dts/upstream /Makefile. This apparently plays no role when building U-Boot, but it would still be useful for validation purposes to have overlay support there.
Jan
Hi Jan,
On Thu, 5 Sept 2024 at 12:08, Jan Kiszka jan.kiszka@siemens.com wrote:
On 04.09.24 19:29, Frank Wunderlich wrote:
Gesendet: Mittwoch, 04. September 2024 um 19:16 Uhr Von: "Jan Kiszka" jan.kiszka@siemens.com OK, our overlay sources are on their way into mainline, will only take until 6.12-rc1 to get them here.
Glad to hear that.
To accelerate the preparation, I ported that change to a local branch - just to find out that OF_UPSTREAM has no clue about DT overlays so far. And it is not just that there are no build rules for them (that was quickly fixed). It's also that there is no way to trigger their build for your u-boot proper.
Are there plans for addressing this? I'm inclined to revive my patch that allows to augment dtb-y from the board's config.mk. Better suggestions?
Hi
i hang also on this part, in my case i build the dtbos for the vendor and try to use fdtoverlay to merge base-dt with the defined overlays.
see commits till July 11th
https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/
this fails because the target for fdtoverlays needs targets for the dtbos (have used the fdtoverlay target from linux)... but i build then without dedicated target (while building the basedt).
maybe you can help solving the "small" problem in makefile.
This is close but not quite the same scenario because I only need "our" dtbos, and there is no need to create dtbs with them applied (they will be used during dt fixup in our case).
What I've now done is this:
diff --git a/dts/Kconfig b/dts/Kconfig index 569d4be338e..7ea4fd5a79b 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -226,11 +226,11 @@ config OF_LIST
config OF_OVERLAY_LIST string "List of device tree overlays to include for DT control"
depends on SPL_LOAD_FIT_APPLY_OVERLAY help This option specifies a list of device tree overlays to use for DT control. This option can then be used by a FIT generator to includethe overlays in the FIT image.
the overlays in the FIT image or by binman when assembling an imagethat uses overlays during DT fixup.choice prompt "OF LIST compression" diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts index 790f3c508f1..dc181240a21 100644 --- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) +dtb-y += $(patsubst %,%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) ifeq ($(CONFIG_ARM64),y)
Yeah that's all you need to build DT overlays from dts/upstream subtree. Care to send a proper patch for this?
I will also provide a patch to enhance the machinery in dts/upstream /Makefile. This apparently plays no role when building U-Boot, but it would still be useful for validation purposes to have overlay support there.
As you mentioned we don't use Makefile for U-Boot builds. So it's better to directly send that patch for inclusion in the DT rebasing tree.
-Sumit
Jan
-- Siemens AG, Technology Linux Expert Center
On 10.09.24 08:38, Sumit Garg wrote:
Hi Jan,
On Thu, 5 Sept 2024 at 12:08, Jan Kiszka jan.kiszka@siemens.com wrote:
On 04.09.24 19:29, Frank Wunderlich wrote:
Gesendet: Mittwoch, 04. September 2024 um 19:16 Uhr Von: "Jan Kiszka" jan.kiszka@siemens.com OK, our overlay sources are on their way into mainline, will only take until 6.12-rc1 to get them here.
Glad to hear that.
To accelerate the preparation, I ported that change to a local branch - just to find out that OF_UPSTREAM has no clue about DT overlays so far. And it is not just that there are no build rules for them (that was quickly fixed). It's also that there is no way to trigger their build for your u-boot proper.
Are there plans for addressing this? I'm inclined to revive my patch that allows to augment dtb-y from the board's config.mk. Better suggestions?
Hi
i hang also on this part, in my case i build the dtbos for the vendor and try to use fdtoverlay to merge base-dt with the defined overlays.
see commits till July 11th
https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/
this fails because the target for fdtoverlays needs targets for the dtbos (have used the fdtoverlay target from linux)... but i build then without dedicated target (while building the basedt).
maybe you can help solving the "small" problem in makefile.
This is close but not quite the same scenario because I only need "our" dtbos, and there is no need to create dtbs with them applied (they will be used during dt fixup in our case).
What I've now done is this:
diff --git a/dts/Kconfig b/dts/Kconfig index 569d4be338e..7ea4fd5a79b 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -226,11 +226,11 @@ config OF_LIST
config OF_OVERLAY_LIST string "List of device tree overlays to include for DT control"
depends on SPL_LOAD_FIT_APPLY_OVERLAY help This option specifies a list of device tree overlays to use for DT control. This option can then be used by a FIT generator to includethe overlays in the FIT image.
the overlays in the FIT image or by binman when assembling an imagethat uses overlays during DT fixup.choice prompt "OF LIST compression" diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts index 790f3c508f1..dc181240a21 100644 --- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) +dtb-y += $(patsubst %,%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) ifeq ($(CONFIG_ARM64),y)
Yeah that's all you need to build DT overlays from dts/upstream subtree. Care to send a proper patch for this?
Can do if you already want this [1]. Our tree [2] where it is currently included still has to wait for upstream 6.12, possibly even 6.13 as we need one more overlay now.
I will also provide a patch to enhance the machinery in dts/upstream /Makefile. This apparently plays no role when building U-Boot, but it would still be useful for validation purposes to have overlay support there.
As you mentioned we don't use Makefile for U-Boot builds. So it's better to directly send that patch for inclusion in the DT rebasing tree.
No, this is about our shadow Makefiles, see [3].
Jan
[1] https://github.com/siemens/u-boot/commit/2be0393b1718990abf2feb0b13dbaf79629... [2] https://github.com/siemens/u-boot/commits/jan/iot2050 [3] https://github.com/siemens/u-boot/commit/de3df1fed47d2075bb3f9ecccfaa93a368b...
Am 10. September 2024 14:08:07 MESZ schrieb Jan Kiszka jan.kiszka@siemens.com:
On 10.09.24 08:38, Sumit Garg wrote:
Hi Jan,
On Thu, 5 Sept 2024 at 12:08, Jan Kiszka jan.kiszka@siemens.com wrote:
On 04.09.24 19:29, Frank Wunderlich wrote:
Gesendet: Mittwoch, 04. September 2024 um 19:16 Uhr Von: "Jan Kiszka" jan.kiszka@siemens.com OK, our overlay sources are on their way into mainline, will only take until 6.12-rc1 to get them here.
Glad to hear that.
To accelerate the preparation, I ported that change to a local branch - just to find out that OF_UPSTREAM has no clue about DT overlays so far. And it is not just that there are no build rules for them (that was quickly fixed). It's also that there is no way to trigger their build for your u-boot proper.
Are there plans for addressing this? I'm inclined to revive my patch that allows to augment dtb-y from the board's config.mk. Better suggestions?
Hi
i hang also on this part, in my case i build the dtbos for the vendor and try to use fdtoverlay to merge base-dt with the defined overlays.
see commits till July 11th
https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/
this fails because the target for fdtoverlays needs targets for the dtbos (have used the fdtoverlay target from linux)... but i build then without dedicated target (while building the basedt).
maybe you can help solving the "small" problem in makefile.
This is close but not quite the same scenario because I only need "our" dtbos, and there is no need to create dtbs with them applied (they will be used during dt fixup in our case).
Where do you apply the dtbos? In my case it is necessary to build the dtb with overlay as we have no way to detect which overlay needs to be applied.
We have overlays for different mmc (sdmmc/emmc) and spi (nand/ nor) settings which cannot be probed at runtime (or at least we have not found a way to do this).
Maybe someone can help getting ftdoverlay target working in uboot with the dtbo list.
What I've now done is this:
diff --git a/dts/Kconfig b/dts/Kconfig index 569d4be338e..7ea4fd5a79b 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -226,11 +226,11 @@ config OF_LIST
config OF_OVERLAY_LIST string "List of device tree overlays to include for DT control"
depends on SPL_LOAD_FIT_APPLY_OVERLAY help This option specifies a list of device tree overlays to use for DT control. This option can then be used by a FIT generator to includethe overlays in the FIT image.
the overlays in the FIT image or by binman when assembling an imagethat uses overlays during DT fixup.choice prompt "OF LIST compression" diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts index 790f3c508f1..dc181240a21 100644 --- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) +dtb-y += $(patsubst %,%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) ifeq ($(CONFIG_ARM64),y)
Yeah that's all you need to build DT overlays from dts/upstream subtree. Care to send a proper patch for this?
Can do if you already want this [1]. Our tree [2] where it is currently included still has to wait for upstream 6.12, possibly even 6.13 as we need one more overlay now.
I will also provide a patch to enhance the machinery in dts/upstream /Makefile. This apparently plays no role when building U-Boot, but it would still be useful for validation purposes to have overlay support there.
As you mentioned we don't use Makefile for U-Boot builds. So it's better to directly send that patch for inclusion in the DT rebasing tree.
No, this is about our shadow Makefiles, see [3].
Jan
[1] https://github.com/siemens/u-boot/commit/2be0393b1718990abf2feb0b13dbaf79629... [2] https://github.com/siemens/u-boot/commits/jan/iot2050 [3] https://github.com/siemens/u-boot/commit/de3df1fed47d2075bb3f9ecccfaa93a368b...
regards Frank
On 10.09.24 14:36, Frank Wunderlich wrote:
Am 10. September 2024 14:08:07 MESZ schrieb Jan Kiszka jan.kiszka@siemens.com:
On 10.09.24 08:38, Sumit Garg wrote:
Hi Jan,
On Thu, 5 Sept 2024 at 12:08, Jan Kiszka jan.kiszka@siemens.com wrote:
On 04.09.24 19:29, Frank Wunderlich wrote:
Gesendet: Mittwoch, 04. September 2024 um 19:16 Uhr Von: "Jan Kiszka" jan.kiszka@siemens.com OK, our overlay sources are on their way into mainline, will only take until 6.12-rc1 to get them here.
Glad to hear that.
To accelerate the preparation, I ported that change to a local branch - just to find out that OF_UPSTREAM has no clue about DT overlays so far. And it is not just that there are no build rules for them (that was quickly fixed). It's also that there is no way to trigger their build for your u-boot proper.
Are there plans for addressing this? I'm inclined to revive my patch that allows to augment dtb-y from the board's config.mk. Better suggestions?
Hi
i hang also on this part, in my case i build the dtbos for the vendor and try to use fdtoverlay to merge base-dt with the defined overlays.
see commits till July 11th
https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/
this fails because the target for fdtoverlays needs targets for the dtbos (have used the fdtoverlay target from linux)... but i build then without dedicated target (while building the basedt).
maybe you can help solving the "small" problem in makefile.
This is close but not quite the same scenario because I only need "our" dtbos, and there is no need to create dtbs with them applied (they will be used during dt fixup in our case).
Where do you apply the dtbos? In my case it is necessary to build the dtb with overlay as we have no way to detect which overlay needs to be applied.
In our case, during ft_board_setup, thus dynamically:
https://source.denx.de/u-boot/u-boot/-/blob/7b2d4ecd7f6593771dd3118c8bab525d...
We have overlays for different mmc (sdmmc/emmc) and spi (nand/ nor) settings which cannot be probed at runtime (or at least we have not found a way to do this).
Maybe someone can help getting ftdoverlay target working in uboot with the dtbo list.
Yeah, that would be another path that requires additional work. Sorry, I'm not familiar with those details myself.
Jan
Hi Sumit,
On 2024-08-26 08:44, Sumit Garg wrote:
Hi,
On Wed, 14 Aug 2024 at 22:14, Jan Kiszka jan.kiszka@siemens.com wrote:
On 14.08.24 11:41, Jan Kiszka wrote:
On 13.08.24 14:52, Nishanth Menon wrote:
On 11:16-20240813, Jan Kiszka wrote:
Hi all,
I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm facing issues because I need to still build the u-boot-only overlays. It is also a bit weird (but works) having to specify
CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
Actually, this does NOT work: I just had a long morning debugging SPL which no longer started because it picked the non-filtered dtb. The filtered one ended up in a folder outside of the u-boot sources because of all those ../ and hard-wiring to dts/upstream.
for our spl dtb.
Are there means to still build certain dtb[o] files in arch/<arch>/dts? I'm a bit lost in the Makefile forest.
Sumit: Any suggestions?
Apologies for the delayed reply. I was a bit busy with other high priority stuff.
I would really like to hear some better proposals than my local workarounds to far. They don't converge although I already patched some core Makefile (overlays are building now).
OK, I side-stepped the spl issue by using one of our variant DTBs for spl as well - happens to work.
That's good to know.
For the overlays, I need to add
--- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/config.mk
dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
in order to then be able to do
--- a/board/siemens/iot2050/config.mk +++ b/board/siemens/iot2050/config.mk @@ -5,4 +5,12 @@ # Authors: # Jan Kiszka jan.kiszka@siemens.com
+ifneq ($(CONFIG_SPL_BUILD),y) +dtbo-list = \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay+dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list)) +endif
flash.bin: all
Does that make sense?
A switch to OF_UPSTREAM means that we build all the DT artifacts from dts/upstream/src/ directory with the only exception that we include U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In case of overlays, is there any reason for IOT2050 board overlays not being pushed into Linux kernel repo? AFAIU, overlays are also describing puggable hardware so they shouldn't be referred to as "u-boot-only" overlays.
I have a related issue where I would like to build board DT from dts/upstream, however there is also a need for a limited U-Boot specific DT that only is intended for initial boot so that U-Boot at runtime can determine what hw revision is booting and select correct DT to use for U-Boot proper and OS.
For now I have just set the board target to use OF_UPSTREAM=n and instead created minimal .dts-files in arch/<arch>/dts that include the full .dts-file from dts/upstream.
Any suggestion on how we better can support having a U-Boot only .dts-file together with OF_UPSTREAM=y ?
Please see following for more details: https://source.denx.de/u-boot/u-boot/-/commit/a52099b4a2ae9e8cafc79268325249... https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3566-orang... https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3566-orang... https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3566-orang...
Regards, Jonas
-Sumit
Jan
-- Siemens AG, Technology Linux Expert Center
participants (5)
-
Frank Wunderlich -
Jan Kiszka -
Jonas Karlman -
Nishanth Menon -
Sumit Garg