OF_UPSTREAM vs. additional dtbs

[Jan Kiszka]

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.

Jan

-- 
Siemens AG, Technology
Linux Expert Center