Re: [PATCH v1 0/3] dts: build the DTS from a directory outside the tree

[E Shattow <e@freeshell.de>]

Hi Vincent,

On 11/8/26 12:50, Vincent Jardin wrote:
> Hi,
> 
>>>> Upstream your hardware support and you won't need external DTs.
>>>
>>> Even upstream, how does it solve the Yocto's and Buildroot's related
>>> issues ? Both did try to workaround despite they are all upstream.
>> Could you apply a patch which contains the custom DT instead ?
>> (using SRC_URI:append = " file://0001-your-dt.patch" or similar)
> 
> the patch has to be redone, again and again. That is what Buildroot went
> through: see [1] or [3]
> 
> For Yocto see [4][5][6]
> 
> Both do hand copy ! config/git management is not convenient neither.
> 
>>
>> What is the use case of custom DT injection like this ?
> 
> For example,
> 
>  - Bring-up. The board needs U-Boot to boot before its device tree is
>    anywhere near upstream, and the .dts changes several times a day.
>    Pointing the build at the directory beats a patch per iteration !
> 
>  - Linux sync. A DT that is upstream in Linux but not yet in U-Boot.
>    dts/upstream follows a kernel release, so a board whose .dts landed
>    in the kernel waits for the next sync.
> 
>  - Board variants. A carrier or a memory variant of a supported board,
>    like the VisionFive 2 8GiB report [7], needs its own DTB but is not
>    something U-Boot wants a defconfig for. The variant .dts lives with
>    the product and builds against the SoC .dtsi of the U-Boot release.
> 
> How to handle those cases + Buildroot and Yocto without such proposal
> for uboot ?
> 
> best regards,
>   Vincent

I've mentioned previously on list and in IRC discussion this topic of
dts source tree names being hard-coded. It would be very useful to have
LINUX_SOURCE_TREE=/path/to/source/tree/linux.git and a Kconfig option
activated to pass to the build for local development substituting
in-place of the 'dts' sub-tree. This is RFC do-not-merge territory and
to prevent abuse no patch users of code depending on this Kconfig option
should be accepted to merge.

I think that it is too fragile to make support for an external DTS tree
as a supported dependency of in-tree boards. There is a concern that
vendors would normalize this and make the situation even more
fragmented, contrary to the intent of having Linux as the device tree
upstream in-tree as a 'dts' sub-tree.

There are two overall topics here though:

1. Everywhere, all over, it is assumed "dts/upstream/src" literal is the
devicetree-rebasing tree location. The hard coded use of paths in U-Boot
build system is technical debt for when we would want to extend this
substituting an alternative location of the 'dts' git subtree.

2. devicetree-rebasing subtree does not share the same directory layout
structure as Linux kernel source tree, and the need for substituting
this with Linux source tree locally is not possible to provide for at
the moment;  temporary hacks to remove and replace the subtree directory
with symlink to local linux source tree are not sufficient due to the
differences in directory layout and missing or conflicting header files
referenced by dts and dtsi inputs.

The motivation to resolve [1] is moot if, as has been confirmed
previously, 'dts' directory name is the permanent location of
devicetree-rebasing sub tree in U-Boot source tree.

However, [2] depends on [1], and this touches a lot of code to abstract
the devicetree-rebasing subtree handling.

I'd like to see this realized but is it worth the effort?

-E