On Tue, 1 Oct 2024 at 20:57, Marek Vasut <ma...@denx.de> wrote: > > 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.
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
