From: Marek Vasut <marek.vasut@mailbox.org>
To: Tom Rini <trini@konsulko.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
Adriano Cordova <adrianox@gmail.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Peter Robinson <pbrobinson@gmail.com>,
Sam Edwards <cfsworks@gmail.com>,
u-boot@lists.denx.de
Subject: Re: [RFC][PATCH] kbuild: Produce diff between base DT and U-Boot augmented DT if DEVICE_TREE_DEBUG=1
Date: Fri, 7 Nov 2025 17:44:37 +0100 [thread overview]
Message-ID: <4b14ce54-6ba0-4e35-abad-6787b2d994fb@mailbox.org> (raw)
In-Reply-To: <20251107155650.GE6688@bill-the-cat>
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.
next prev parent reply other threads:[~2025-11-07 16:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-06 21:08 [RFC][PATCH] kbuild: Produce diff between base DT and U-Boot augmented DT if DEVICE_TREE_DEBUG=1 Marek Vasut
2025-11-07 9:00 ` Fwd: " Heinrich Schuchardt
2025-11-07 10:21 ` E Shattow
2025-11-07 9:12 ` Heinrich Schuchardt
2025-11-07 14:06 ` Marek Vasut
2025-11-07 15:56 ` Tom Rini
2025-11-07 16:44 ` Marek Vasut [this message]
2025-11-09 23:44 ` Marek Vasut
2025-11-10 16:47 ` Tom Rini
2025-11-11 3:21 ` Marek Vasut
2025-11-11 12:38 ` Simon Glass
2025-11-11 13:50 ` Marek Vasut
2025-11-14 13:46 ` Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b14ce54-6ba0-4e35-abad-6787b2d994fb@mailbox.org \
--to=marek.vasut@mailbox.org \
--cc=adrianox@gmail.com \
--cc=cfsworks@gmail.com \
--cc=ilias.apalodimas@linaro.org \
--cc=pbrobinson@gmail.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.