Hi Quentin, On Mon, 4 May 2026 at 07:10, Quentin Schulz <[email protected]> wrote: > > On 5/4/26 3:02 PM, Simon Glass wrote: > > Hi Quentin, > > > > On Mon, 4 May 2026 at 06:59, Quentin Schulz <[email protected]> > > 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 <[email protected]> > >>> 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 <[email protected]> > >>>>> Signed-off-by: Simon Glass <[email protected]> > >>>>> --- > >>>>> > >>>>> 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?
i.e. very little :-) Yes that seems fine. I'll keep an eye on this thread and send v2 when you and Marek have resolved the other questions. Regards, Simon
