Hi Quentin,
On Thu, 2026-02-26 at 17:21 +0100, Quentin Schulz wrote:
> Hi Nikita,
>
> On 2/26/26 2:52 PM, Nikita Shubin wrote:
> > [You don't often get email from [email protected]. Learn
> > why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > The hardcoded 64KB FDT increment size causes excessive
> > reallocations
> > when building FIT images with large artifacts (e.g., 250+ MB
> > rootfs):
> >
> > ```
> > ncalls tottime percall cumtime percall
> > filename:lineno(function)
> > 16118 297.130 0.018 305.189 0.019
> > libfdt.py:947(resize)
> > 870 9.876 0.011 15.211 0.017
> > fdt.py:56(BytesToValue)
> > 16118 8.024 0.000 8.024 0.000 {built-in method
> > _libfdt.fdt_resize}
> > ```
> >
> > Add support for configurable increment size via --fdt-inc-size
> > option,
> > with recommended value at least equal to total binary artifacts
> > size
> > to minimize resize operations and reduce build time.
> >
>
> Does it *need* to be configurable though?
>
> After all, we kinda know what we're going to put into the device tree
> right before inserting it no?
Well we do, kind of...
>
> I'm wondering if we cannot simply set the INC_SIZE based on the size
I think we can.
> of
> the data we're going to include (+ size for the property name and
> some
> overhead I guess). I'm assuming changing it before using
> fsw.property()
> and reverting it to the default value after the method is called? I'm
> assuming we may want to cap this such that we don't need to worry
> about
> OOM with very big artifacts.
AFAIK it won't save us from OOM, cause it's not a limiter of some kind,
but a hint used for resize increment:
```
if check_err(val, QUIET_NOSPACE) < 0:
self.resize(len(self._fdt) + self.INC_SIZE)
return True
```
So we simply increase it chunk by chunk with limited size of INC_SIZE
until we hit required size. That's why we end up iterating so much,
i.e.:
```
$ time venv/bin/binman -T 32 build [...]
real 5m2.764s
user 0m55.798s
sys 4m5.155s
$ time venv/bin/binman -T 32 build -s 268435456 [...]
real 0m24.858s
user 0m9.166s
sys 0m3.509
```
So setting size_hint drastically reduces build time.
>
> I"m also wondering... is this code path also used when you put the
> data
> external to the FIT? fit,external-offset (can be 0, the case for most
> platforms except NXP). Maybe this is what you want? I'm not too verse
> into fit generation and quickly reading tools/fit_image.c, it seems
> like
> it expects an FDT with data properties and then relocate them outside
> the FDT and set a data-offset property in lieu of the data
> properties...
> That seems pretty inefficient to me, why insert the data inside the
> FDT
> in the first place?
Can't tell precisely - i should study it. May be you are right.
>
> The next question is how exactly you're planning to set this size.
> Because as I see it now, this is only configurable when calling
> binman
> manually and passing it an argument. Which means, this won't be used
> by
> default when building U-Boot with make.
Well, i use "binman" as a last stage, not as a part of U-Boot build,
something like this:
```
$ python -m venv venv
$ pip install tools/binman tools/patman # (along with other deps)
$ venv/bin/binman -T 32 build -s 268435456 -d u-boot.dtb -O build-fit -
I bsp -a of-list=my-board -a opensbi-path=fw_dynamic.bin" -a default-
dt="" -a spl-bss-pad=1 -a tpl-bss-pad=1 -a spl-dtb=y
```
And i think binman should be "U-Boot agnostic" just like mkimage.
As well as i am using external DTB not part of U-Boot or Linux,
complied separately.
But you right about "building U-Boot with make" - I missed this moment
entirely.
>
> This also will trip the coverage test though I'm not sure how we want
> to
> test this feature to be honest.
>
> Cheers,
> Quentin
