Hi Anshul,
On 8/27/26 9:59 AM, Anshul Dalal wrote:
On Fri Aug 21, 2026 at 11:44 PM IST, Quentin Schulz wrote:
On 8/10/26 2:06 PM, Anshul Dalal wrote:
On Wed Jul 29, 2026 at 4:12 PM IST, Quentin Schulz wrote:
Hi Anshul,
On 7/29/26 12:24 PM, Anshul Dalal wrote:
The phandles used inside a template are not copied to the node inserting
the template, leading to a missing phandle error.
The following example can be used to reproduce the issue:
&binman {
some_template: template-0 {
ti-secure-rom {
content = <&some_data>;
keyfile = "some_key";
};
some_data: blob-ext {
optional;
};
};
output-bin {
insert-template = <&some_template>;
};
};
What happens if you insert the template *twice*.
e.g. have:
&binman {
some_template: template-0 {
ti-secure-rom {
content = <&some_data>;
keyfile = "some_key";
};
some_data: blob-ext {
optional;
};
};
output-bin {
insert-template = <&some_template>;
};
output-bin2 {
insert-template = <&some_template>;
};
};
? Gut feeling is that this will fail to build because we now have the
same label for two different nodes.
Yes, it will cause a failure due to duplicated phandles. And as per the
docs[1], it seems to be an expected qwirk of how templates work.
What's the point of a template if we can only have it once?
Couldn't we simply have
We could have it that way but from what I see, templates are mostly used
only once per DTS in the source.
With the most common use case being where the template is defined for a
SoC family in a dtsi (such as k3-binman.dtsi for TI) and each SoC then
using the respective templates only once.
I think this fix is justified here since we don't expect users to have
multiple template insertions anyways.
&binman {
some_template: template-0 {
ti-secure-rom {
keyfile = "some_key";
};
blob-ext {
optional;
};
};
output-bin {
insert-template = <&some_template>;
ti-secure-rom {
content = <&{/binman/output-bin/blob-ext}>;
};
};
output-bin2 {
insert-template = <&some_template>;
ti-secure-rom {
content = <&{/binman/output-bin2/blob-ext}>;
};
};
or
&binman {
some_template: template-0 {
ti-secure-rom {
keyfile = "some_key";
};
blob-ext {
optional;
};
};
output-bin {
insert-template = <&some_template>;
ti-secure-rom {
content = <&output_bin_some_data>;
};
output_bin_some_data: blob-ext {};
};
output-bin2 {
insert-template = <&some_template>;
ti-secure-rom {
content = <&output_bin2_some_data>;
};
output_bin2_some_data: blob-ext {};
};
We could support that but since nobody is using duplicated templates,
should we really enforce this verbosity?
arch/arm/dts/rockchip-u-boot.dtsi uses a template twice, so that's not
nobody.
I honestly don't the see the appeal for templates if you don't actually
reuse them multiple times, but you make extensive use of it for the k3
family so maybe I'm missing something.
In any case, it's not restricting anything, so i guess it's fine and I
won't block this.
I was about to complain that we need an update to the documentation of
the binman template but this is actually already documented, so that
would be an even stronger reason to accept your patch: we documented the
template to behave that way but never implemented it to behave that way.
I'm wondering whether we should add an additional test to make sure that
a template, with a phandle, inserted twice results in a failure, to make
sure we aren't somehow generating an unexpected DTS with mixed phandles
for example.
I'm currently going through tools/binman/ftest.py and adding a msg to
each assert*() call so we have a message more explicit than the too
often encountered "<number> != <number2>" which is very unhelpful. Can
you add a msg to your assertEquals to explain what went wrong, obviously
a different one for each so it's easy to know which one's triggered the
error? see
https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertEqual
To the custodian in charge of this patch: I don't have any blocker here
anymore.
Cheers,
Quentin
