On Thu Aug 27, 2026 at 8:23 PM IST, Quentin Schulz wrote:
> 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.
They are reused across an SoC family but never within the same DTS.
Example for TI's K3, all our board DTS include the k3-binman.dtsi which
defines the templates.
So the reuse is done by the means of #includes in the dts and not
inserting the same template multiple times in the same dts.
>
> 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
Yeah, this would be a good addition. I can take it up in a later patch.
>
> To the custodian in charge of this patch: I don't have any blocker here
> anymore.
Thanks Quentin, appreciate your inputs!
Regards,
Anshul
