[PATCH v7 04/10] arch: arm: k3-binman: add fit for falcon boot

[Andrew Davis]

On 6/9/25 2:28 AM, Anshul Dalal wrote:
> On Fri Jun 6, 2025 at 5:27 PM IST, Bryan Brattlof wrote:
>> On June  3, 2025 thus sayeth Anshul Dalal:
>>> This adds creation of tispl_falcon.bin for the am62a, 62p and 62x.
>>>
>>> The contents are the same as the existing tispl.bin but A53's spl and
>>> the fdt have been removed as they are not needed in falcon boot.
>>>
>>> This reduces boot time since the payload size is smaller and we also
>>> aren't authenticating the spl and fdt in secure boot.
>>>
>>> Signed-off-by: Anshul Dalal <anshuld at ti.com>
>>> ---
>>>   arch/arm/dts/k3-am625-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>>>   arch/arm/dts/k3-am62a-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>>>   arch/arm/dts/k3-am62p-sk-binman.dtsi | 51 ++++++++++++++++++++++
>>>   arch/arm/dts/k3-binman.dtsi          | 54 +++++++++++++++++++++++
>>>   4 files changed, 233 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi b/arch/arm/dts/k3-am625-sk-binman.dtsi
>>> index cc619f5920e..9544b9d1134 100644
>>> --- a/arch/arm/dts/k3-am625-sk-binman.dtsi
>>> +++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
>>
>> ...
>>
>>> +				dm {
>>> +					ti-secure {
>>> +						content = <&dm_falcon>;
>>> +						keyfile = "custMpk.pem";
>>> +					};
>>> +					dm_falcon: ti-dm {
>>> +						filename = "ti-dm.bin";
>>> +					};
>>
>> When you build this are you using the TI_DM argument? Or are you using
>> BINMAN_INDIRS to point to all the firmware? I think this will only look
>> for "${BINMAN_INDIRS}/ti-dm.bin" and error out now that DM is mandatory
>> unless you use TI_DM which will break a few distro builders' recipes
>>
> 
> It relies on BINMAN_INDIRS still and I hadn't updated the dm node since
> c492a55fe4 ("arm: dts: k3: binman: Fix DM firmware selection"). I will
> fix this in the next revision. Thanks for bringing it to my attention.
> 
>>
>>> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
>>> index 5163161b94d..a678379dae9 100644
>>> --- a/arch/arm/dts/k3-binman.dtsi
>>> +++ b/arch/arm/dts/k3-binman.dtsi
>>> @@ -489,6 +489,60 @@
>>>   		end_address = <0x0 0x9fffffff>;
>>>   	};
>>>   
>>> +	ti_falcon_template: template-9 {
>>> +		filename = "tispl_falcon.bin";
>>
>> Small nitpick: We could probably just call this tifalcon.bin or
>> something shorter. It's not really an SPL now.
>>
>> The bigger issue here (in my mind) is this requires our falcon.config
>> fragment to work properly. I don't think it is wise of use to produce
>> this image if that fragment isn't applied. It would be a debugging
>> nightmare for others outside of the U-Boot space.
>>
> 
> The fragment applies to r5's defconfig which prevents us from doing a
> conditional build of tispl or tifalcon at the a53 stage.
> 

You might also be able to add a config fragment that would be applied
to the A53 stage. It would only be used for this one binman task,
but isn't that all the A53 build does in the falcon boot case anyway?

> Either we move the tifalcon.bin generation to r5 stage which would
> require not only changes to the build arguments as we would now have to
> pass OPTEE/ATF and DM's path at r5 stage but considerable changes to the
> SDK recipes as we would now have to deploy a binary from r5's build
> output to rootfs.
> 

I wouldn't worry too much about the SDK, that is something we control
and is not the only user of U-Boot.

Why do we do the A53 build at all in the falcon case? If we move the
tifalcon.bin generation to R5 stage we can skip the second build,
which might be something worth doing just for that reason. Side benefit
is it would fix the above issue with non-functional `tispl_falcon.bin`.

Andrew

> Binman already produces a lot of binaries during the A-core build most
> of which the end users doesn't care about. I don't see how adding
> tifalcon could become a "debugging nightmare".
> 
> Regards,
> Anshul