On Wed, Jun 04 2025, Tom Rini <tr...@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
