[RFC][PATCH] kbuild: Produce diff between base DT and U-Boot augmented DT if DEVICE_TREE_DEBUG=1

[Marek Vasut]

On 11/10/25 5:47 PM, Tom Rini wrote:
> On Mon, Nov 10, 2025 at 12:44:31AM +0100, Marek Vasut wrote:
>> On 11/7/25 5:44 PM, Marek Vasut wrote:
>>> On 11/7/25 4:56 PM, Tom Rini wrote:
>>>> On Fri, Nov 07, 2025 at 03:06:47PM +0100, Marek Vasut wrote:
>>>>> On 11/7/25 10:12 AM, Heinrich Schuchardt wrote:
>>>>>> On 11/6/25 22:08, Marek Vasut wrote:
>>>>>>> In case DEVICE_TREE_DEBUG is set, produce a diff between
>>>>>>> the base DT and
>>>>>>> DT with U-Boot extras, to show how much does the U-Boot DT differ from
>>>>>>> the base DT. This is particularly useful together with OF_UPSTREAM, to
>>>>>>> minimize the diff between upstream DTs and U-Boot DTs.
>>>>>>>
>>>>>>> Example usage:
>>>>>>> $ make r8a779g3_sparrowhawk_defconfig && make DEVICE_TREE_DEBUG=1
>>>>>>> $ cat ./dts/upstream/src/arm64/renesas/r8a779g3-sparrow-hawk.dtb.diff
>>>>>>>
>>>>>>> This still has a downside. Even 'dtc -I dts -O dts ...' applied on
>>>>>>> base DT and U-Boot augmented DT can produce different phandle IDs
>>>>>>> for the same node in those two DTs, which results in a lot of noise
>>>>>>> in the resulting diff. The only way I can think of is to patch DTC
>>>>>>> to emit full paths in those phandles instead, something like a
>>>>>>> phandle = <&{/full/path/to/remote/end} ...>;
>>>>>
>>>>> What bothers me is ^ this part.
>>>>>
>>>>> Hello Heinrich,
>>>>>
>>>>>> Without documentation developers will not know about the new feature.
>>>>>> Could you, please, add a doc/build/ change in the next iteration.
>>>>> Sure, although I am not convinced it should go in in its current form.
>>>>> Please see my first line of comment.
>>>>
>>>> Maybe we put it in the u-boot-extras repo for now as a standalone
>>>> script, so people can be asked to run it and look at the output?
>>> I'd say no, because the output is full of noise unless the phandle non-
>>> resolution gets somehow improved.
>>
>> If I run this with "DTC=/usr/bin/dtc make ..." , then the phandles are
>> correctly retained. This uses system DTC 1.7.2 instead of in-tree DTC 1.4.6+
>> .
>>
>> Is there still any reason for us to carry our own copy of DTC ?
> 
> I think the answers last time came down to needing to first re-sync the
> dtc flags with upstream kernel again (to ignore new things that won't be
> fixed), then possibly fixing at least any big scary warnings that do
> exist, and then we can just document and use host dtc. Dealing with
> pylibfdt may have been its own issue as well.
Let's see if I can get anywhere with DTC 1.7.2 full sync, I already have 
a prototype.