On 10/1/24 3:35 PM, Sumit Garg wrote:
Hi,
On Sat, 28 Sept 2024 at 03:20, Marek Vasut <ma...@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.
