[PATCH 0/3] Synchronize DTC to 1.7.2

[Simon Glass]

Hi Tom, Marek,

On Thu, 13 Nov 2025 at 11:49, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Nov 13, 2025 at 07:40:29PM +0100, Marek Vasut wrote:
> > On 11/13/25 6:57 PM, Tom Rini wrote:
> >
> > Hello Tom,
> >
> > > So, taking a look at the test branch you pointed me at, my big concern
> > > is size growth. On imx8mp_dhcom_drc02 (where we're already LTO'ing),
> > > with the CI gcc-14.2.0 toolchain full U-Boot grows by more than 6KiB and
> > > SPL by a bit more than 2KiB. This is a bit of a worst-case, imx8mp_navqp
> > > is a bit more than 3KiB / 548 bytes, with the average feeling like
> > > ~4KiB/1KiB for aarch64.
> >
> > Do you know why this growth happened ? Is that in libfdt ? How did you find
> > it ?
>
> Using buildman. To make it easier I put my wrapper around it at:
> https://source.denx.de/u-boot/u-boot-extras/-/blob/master/contrib/trini/u-boot-size-test.sh?ref_type=heads
> a while ago. I can also send you off-list the world build comparison
> (it's 446KiB gzip'd).
>
> > [...]
> >
> > > Rather than a full-resync for the last time we needed a feature found
> > > upstream.
> >
> > I really don't want to do partial resync, it will only make it harder to
> > maintain obsolete code base going forward. Even this resync was hard due to
> > that exact current divergence.
> >
> > > There are things we *need* like to be 8-byte aligned and also the
> > > phandle resolution thing I believe inspired your investigations here,
> > > but I don't know if we can take the whole sync. Or maybe needing to work
> > > with upstream to shrink down some parts, I'm unsure.
> >
> > CI does show that no boards went oversize . If there is some growth on
> > existing devices, maybe we can shrink that, but maintaining obsolete DTC
> > code base going forward and picking random updates into it, that will only
> > lead to increasing maintenance pain, so I don't want to do that.
>
> Yeah, it's not an easy spot. But I'm really not happy with growing main
> U-Boot almost everywhere by 2KiB - 4KiB, and SPL by ~512 bytes or more
> just to keep up. I do see that integratorcp_cm1136 barely grows at all,
> so maybe there's something that can be done more widely and just wasn't
> clear at first. m68k only grows an average of 500 bytes and MIPS is
> ~1KiB. PowerPC grows a lot. RISC-V a little.

FDT_ASSUME_MASK was my attempt to handle this upstream. It is likely
that people have not been using that very much upstream and some more
of the code needs to check fdt_chk_extra() before address/value
checks, etc.

Regards,
Simon