[PATCH] fdtgrep: Add option to reserve free space in the output FDT

[Quentin Schulz]

On 5/4/26 3:02 PM, Simon Glass wrote:
> Hi Quentin,
> 
> On Mon, 4 May 2026 at 06:59, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>>
>> Hi Simon,
>>
>> On 5/4/26 2:49 PM, Simon Glass wrote:
>>> Hi Quentin,
>>>
>>> On Mon, 27 Apr 2026 at 03:14, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>>>>
>>>> Hi Simon, Marek,
>>>>
>>>> On 4/22/26 4:31 AM, Simon Glass wrote:
>>>>> When producing a DTB from fdtgrep, there is no way to reserve extra
>>>>> space so that more nodes/properties can be added at runtime without
>>>>> growing totalsize first.
>>>>>
>>>>
>>>> Ok but why is that an issue? What is the actual usecase? What I'm afraid
>>>> of is that you pad enough and you hit random bugs because you forget
>>>> that adding enough properties can now hit the size limit and you forgot
>>>> to add the logic to resize/grow the fdt when it's too small to fit new
>>>> properties.
>>>
>>> I'm going to leave this question to Marek :-)
>>>
>>>>
>>>>> Add a -B/--pad option that appends a caller-specified number of free
>>>>> bytes after the strings section and grows totalsize accordingly. The
>>>>> padding is applied after fdt_pack(), so it is not reclaimed when -r is
>>>>> used.
>>>>>
>>>>> Suggested-by: Marek Vasut <marek.vasut at mailbox.org>
>>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>>> ---
>>>>>
>>>>>     tools/binman/btool/fdtgrep.py |  3 ++-
>>>>>     tools/fdtgrep.c               | 31 ++++++++++++++++++++++++++++++-
>>>>>     2 files changed, 32 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/tools/binman/btool/fdtgrep.py b/tools/binman/btool/fdtgrep.py
>>>>> index 446b2f4144b..7b393241878 100644
>>>>> --- a/tools/binman/btool/fdtgrep.py
>>>>> +++ b/tools/binman/btool/fdtgrep.py
>>>>> @@ -16,9 +16,10 @@ Output formats are:
>>>>>         dtb - device tree blob (sets -Hmt automatically)
>>>>>         bin - device tree fragment (may not be a valid .dtb)
>>>>>
>>>>> -Options: -[haAc:b:C:defg:G:HIlLmn:N:o:O:p:P:rRsStTvhV]
>>>>> +Options: -[haAB:c:b:C:defg:G:HIlLmn:N:o:O:p:P:rRsStTvhV]
>>>>>       -a, --show-address                 Display address
>>>>>       -A, --colour                       Show all nodes/tags, colour those that match
>>>>> +  -B, --pad <arg>                    Append free space to the output FDT, for later growth
>>>>>       -b, --include-node-with-prop <arg> Include contains containing property
>>>>>       -c, --include-compat <arg>         Compatible nodes to include in grep
>>>>>       -C, --exclude-compat <arg>         Compatible nodes to exclude in grep
>>>>
>>>> I'm tempted to remove this and just tell people to look at the
>>>> documentation in tools/fdtgrep.c. Especially since we don't actually
>>>> allow the user to pass any of those parameters themselves via the
>>>> bintool, so it isn't actually useful.
>>>
>>> I would like fdtgrep to give useful help, though. It is a tool which
>>> can stand alone.
>>>
>>
>> Yes, but this here is docstring for the fdtgrep *Bintool* module which
>> actually doesn't support most of the arguments specified here. So I
>> would say it's more confusing to have it there than not have anything.
>> For sure we want to keep documentation of fdtgrep, the tool as in
>> tools/fdtgrep.c, complete and up-to-date!
> 
> Ah yes, I just generated it directly from fdtgrep. So perhaps we
> should have no argument docs here and just mention what the bintool
> actually supports / uses?
> 

It only matters what the bintool exposes as API, create_for_phase() is 
one for example. I'm assuming you *could* call run_cmd() on the bintool 
and provide a list of arguments yourself but then there's no point 
documenting this in the bintool as it'll only be a thin wrapper around 
fdtgrep itself? See what we have for mkimage bintool for example?

Cheers,
Quentin