U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Marek Vasut <marek.vasut@mailbox.org>
Cc: u-boot@lists.denx.de, Adriano Cordova <adrianox@gmail.com>,
	Andrew Goodbody <andrew.goodbody@linaro.org>,
	Christian Marangi <ansuelsmth@gmail.com>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Patrice Chotard <patrice.chotard@foss.st.com>,
	Sam Edwards <cfsworks@gmail.com>, Simon Glass <sjg@chromium.org>
Subject: Re: [PATCH 0/3] Synchronize DTC to 1.7.2
Date: Thu, 13 Nov 2025 12:49:17 -0600	[thread overview]
Message-ID: <20251113184917.GN6688@bill-the-cat> (raw)
In-Reply-To: <63d6a47c-99cc-48d1-9d71-869c58e2eb69@mailbox.org>

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2025-11-13 18:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-13 12:21 [PATCH 0/3] Synchronize DTC to 1.7.2 Marek Vasut
2025-11-13 12:21 ` [PATCH 1/3] dm: core: Check ofnode_to_offset() return value Marek Vasut
2025-11-13 19:33   ` Simon Glass
2025-11-13 21:51     ` Marek Vasut
2025-11-13 22:46       ` Simon Glass
2025-11-14  5:17         ` Marek Vasut
2025-11-14 14:36           ` Tom Rini
2025-11-16  0:16             ` Marek Vasut
2025-11-16 14:13               ` Tom Rini
2025-11-16 21:28                 ` Marek Vasut
2025-11-17 14:14                   ` Tom Rini
2025-11-13 12:21 ` [PATCH 2/3] scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c Marek Vasut
2025-11-13 12:21 ` [PATCH 3/3] libfdt: Check fdt_offset_ptr() return value unconditionally Marek Vasut
2025-11-13 19:33   ` Simon Glass
2025-11-13 21:48     ` Marek Vasut
2025-11-13 23:34       ` Simon Glass
2025-11-20  4:20         ` Marek Vasut
2025-11-13 17:57 ` [PATCH 0/3] Synchronize DTC to 1.7.2 Tom Rini
2025-11-13 18:40   ` Marek Vasut
2025-11-13 18:49     ` Tom Rini [this message]
2025-11-13 19:32       ` Simon Glass
2025-11-15 23:23       ` Marek Vasut
2025-11-16 14:11         ` Tom Rini
2025-11-16 21:48           ` Marek Vasut
2025-11-17 18:40             ` Tom Rini
2025-11-19 21:31               ` Marek Vasut
2025-11-20 15:54                 ` Tom Rini
2025-11-20 20:14                   ` Marek Vasut
2025-11-21 19:55   ` Tom Rini
2025-12-02 17:46     ` Marek Vasut
2025-12-02 18:06       ` Tom Rini
2025-12-02 18:35         ` Marek Vasut

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=20251113184917.GN6688@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=adrianox@gmail.com \
    --cc=andrew.goodbody@linaro.org \
    --cc=ansuelsmth@gmail.com \
    --cc=cfsworks@gmail.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=marek.vasut@mailbox.org \
    --cc=patrice.chotard@foss.st.com \
    --cc=sjg@chromium.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox