OF_UPSTREAM vs. additional dtbs

[Sumit Garg]

On Tue, 27 Aug 2024 at 15:05, Jan Kiszka <jan.kiszka at siemens.com> wrote:
>
> On 27.08.24 09:13, Sumit Garg wrote:
> > On Mon, 26 Aug 2024 at 18:02, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> >>
> >> On 26.08.24 09:10, Sumit Garg wrote:
> >>> On Mon, 26 Aug 2024 at 12:19, Jan Kiszka <jan.kiszka at 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 at 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 at 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-with-devicetree-rebasing

-Sumit

>
> Jan
>
> --
> Siemens AG, Technology
> Linux Expert Center
>