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

[Anshul Dalal]

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.

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.

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