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?
I'm wondering if we cannot simply set the INC_SIZE based on the size 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.
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?
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.
This also will trip the coverage test though I'm not sure how we want to
test this feature to be honest.
Cheers,
Quentin
