[PATCH 2/3] dts: Add ability to build DTOs only from arch/$(ARCH)/dts

[Marek Vasut]

On 10/1/24 3:35 PM, Sumit Garg wrote:

Hi,

>>> On Sat, 28 Sept 2024 at 03:20, Marek Vasut <marex at denx.de> wrote:
>>>>
>>>> Currently the enablement of OF_UPSTREAM results on the build system
>>>> searching for DTs only in dts/upstream/ . There are platforms which
>>>> use U-Boot specific DTBOs applied on top of U-Boot control DT during
>>>> SPL stage, and source DTs for these are located in arch/$(ARCH)/dtb.
>>>
>>> I would like to understand the need to maintain DTBOs separately from
>>> DTBs. Why aren't we pushing DTBOs to Linux kernel sources as we do for
>>> DTBs?
>>
>> This is a stopgap measure, I would like to start reducing the amount of
>> U-Boot DTs for iMX platforms, but the DTBOs are still in U-Boot only, so
>> I would like to have some middle-of-the-road solution until the DTOs get
>> upstreamed to Linux too.
>>
>>> Jan recently pushed those so-called U-Boot specific DTBOs for a
>>> TI platform which were accepted in the Linux kernel upstream. This
>>> patch will just deny the ability to build those DTBOs from dts
>>> upstream tree. IMHO, this takes a step backwards on the whole notion
>>> of OF_UPSTREAM.
>>
>> I don't think this will deny building those DTOs which are already
>> upstream. With OF_UPSTREAM enabled, this will build:
>> - Upstream DTBs
>> - Upstream DTBOs
>> - U-Boot local DTBOs (and NOT U-Boot local DTBs)
>> The DTs that are bundled into u-boot.itb are searched exactly in that
>> order too, upstream ones first, upstream DTBOs second and finally the
>> U-Boot local DTBOs. The upstream content should always get higher
>> priority if there are any leftover DTBOs in U-Boot which are also upstream.
>>
>>> If we really want a middle ground solution to allow migration to
>>> OF_UPSTREAM easier then we need to find a way to build DTBOs from both
>>> directories (local and upstream dts). I would imagine that will likely
>>> complicate building and packaging DTBOs.
>>
>> I believe this is exactly what this commit does ?
> 
> Okay I see, probably the commit subject was too confusing for me:
> 
> "dts: Add ability to build DTOs only from arch/$(ARCH)/dts"
> 
> I can see the benefit that it provides to people migrating to
> OF_UPSTREAM. The negative part can be people just not pushing the
> DTBOs upstream which should rather be easier as we have seen Jan
> pushing DTBOs upstream.

That (push your stuff upstream, reduce the duplication in U-Boot) is up 
to maintainers to request.

Strictly enforcing either/or means setting the entry bar to OF_UPSTREAM 
higher than the entry bar to Linux kernel, which is not gonna work.

Giving contributors some middle-of-the-road solution might in fact 
expedite the switch to OF_UPSTREAM, even if it may not happen all at once.

> There is also magic added by this patch
> regarding which DTBO is actually being used (local or upstream one),
> the packaging ordering can be magic to someone debugging a boot issue
> on a particular platform.

See discussion above, the ordering is well defined.

> IMHO, the OF_UPSTREAM migration can wait until all the required DT
> sources (.dts and .dtso) are present upstream. If we start to mix and
> match DT sources then it is going to turn into maintainers' hardship
> again. However, I am still open to further convincing arguments for
> this.
With some Linux kernel architectures, it takes months to get a singular 
patch review out of the maintainers. For systems which already have DTs 
upstream and only have DTOs left, the OF_UPSTREAM conversion and DTO 
upstreaming can be done in parallel, hence expedite the process.