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. -- Tom
signature.asc
Description: PGP signature
