On 27.08.24 09:13, Sumit Garg wrote: > On Mon, 26 Aug 2024 at 18:02, Jan Kiszka <[email protected]> wrote: >> >> On 26.08.24 09:10, Sumit Garg wrote: >>> On Mon, 26 Aug 2024 at 12:19, Jan Kiszka <[email protected]> wrote: >>>> >>>> On 26.08.24 08:44, Sumit Garg wrote: >>>>> Hi, >>>>> >>>>> On Wed, 14 Aug 2024 at 22:14, Jan Kiszka <[email protected]> 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 <[email protected]> >>>>>> >>>>>> +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 -- Siemens AG, Technology Linux Expert Center
