Hi,
On Thu, 26 Feb 2026 at 09:21, Quentin Schulz <[email protected]> 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?
>
> 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.
>From memory, we had a discussion about incrementing the size by a
calculated amount in one of the patches for adding signatures in the C
code. I favoured doing the calculation but the author felt this was
too complex.
A better place to fix this is (sadly) in pylibfdt:
def property(self, name, val):
"""Add a property
Write a new property with the given value to the device tree. The value
is taken as is and is not nul-terminated
Args:
name: Name of property to add
val: Value of property
quiet: Errors to ignore (empty to raise on all errors)
Raises:
FdtException on any error
"""
while self.check_space(fdt_property_stub(self._fdt, name, val,
len(val))):
pass
i.e. pass len(val) to check_space() and have it increase size by at
least that much (but a multiple of INC_SIZE).
Regards,
Simon
