U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <ravi@prevas.dk>
To: Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de,  Simon Glass <sjg@chromium.org>
Subject: Re: [PATCH] mkimage: do a rough estimate for the size needed for hashes/signatures
Date: Wed, 04 Jun 2025 22:19:41 +0200	[thread overview]
Message-ID: <87qzzz1cpu.fsf@prevas.dk> (raw)
In-Reply-To: <20250604142510.GA1922573@bill-the-cat> (Tom Rini's message of "Wed, 4 Jun 2025 08:25:10 -0600")

On Wed, Jun 04 2025, Tom Rini <trini@konsulko.com> wrote:

> On Fri, May 16, 2025 at 02:54:30PM +0200, Rasmus Villemoes wrote:
>
>> 
>> While not perfect, we can give a reasonable estimate of an upper bound
>> on the necessary extra size by simply counting the number of hash and
>> signature nodes in the FIT image.
>> 
>> As indicated in the comments, one could probably make it even more
>> precise, and if there would ever be signatures larger than 512 bytes,
>> probably one would have to do that. But this works well enough in
>> practice for now, and is in fact an improvement in the normal case:
>> Currently, starting with size_inc of 0 is guaranteed to fail, so we
>> always enter the loop at least twice, even when not doing any signing
>> but merely filling hash values.
>> 
>> Just in case I've missed anything, keep the loop incrementing 1024
>> bytes at a time, and also, in case the estimate turns out to be over
>> 64K, ensure that we do at least one attempt by changing to a do-while
>> loop.
>> 
>> ---
>>  tools/fit_image.c | 80 +++++++++++++++++++++++++++++++++++++++++------
>>  1 file changed, 70 insertions(+), 10 deletions(-)
>
> I think some tests need to be updated now:
> https://source.denx.de/u-boot/u-boot/-/jobs/1156824

Hm, yes.

I don't like blindly just updating such numbers so they match, but in
this case I think I can at least explain the delta: The fit image
described in 161_fit.dts has four hash nodes, so with my estimate we
first try with an increment of 4*128=512, while previously we'd first
try 0 and then 1024. Since 512 is enough, the fit image ends up 512
bytes smaller, and that is exactly the delta seen in fit:size and the
other numbers affected by that.

Should I fold in those changes and resend, or is a separate followup
patch better/ok?

Rasmus

  reply	other threads:[~2025-06-04 20:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-16 12:54 [PATCH] mkimage: do a rough estimate for the size needed for hashes/signatures Rasmus Villemoes
2025-05-16 15:39 ` Simon Glass
2025-05-19 10:27   ` Rasmus Villemoes
2025-05-23 20:20     ` Simon Glass
2025-06-04 14:25 ` Tom Rini
2025-06-04 20:19   ` Rasmus Villemoes [this message]
2025-06-04 23:08     ` Tom Rini

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=87qzzz1cpu.fsf@prevas.dk \
    --to=ravi@prevas.dk \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.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