On Tue, 1 Oct 2024 at 20:57, Marek Vasut marex@denx.de wrote:
On 10/1/24 3:35 PM, Sumit Garg wrote:
Hi,
On Sat, 28 Sept 2024 at 03:20, Marek Vasut marex@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.
Okay I see the pain but we already have that rule for .dts files for OF_UPSTREAM switch but having a different rule for .dtso files is going to make maintainability complex. The Linux kernel sub-architecture maintainers remain the same for both .dts and .dtso files.
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.
Fair enough, let's try to find a middle ground to gate the local DTOs behind a config to make the use of local DTOs explicit. How about CONFIG_OF_UPSTREAM_LOCAL_DTOS?
-Sumit