On 26.08.24 09:10, Sumit Garg wrote: > On Mon, 26 Aug 2024 at 12:19, Jan Kiszka <jan.kis...@siemens.com> wrote: >> >> On 26.08.24 08:44, Sumit Garg wrote: >>> Hi, >>> >>> On Wed, 14 Aug 2024 at 22:14, Jan Kiszka <jan.kis...@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.kis...@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 -- Siemens AG, Technology Linux Expert Center
