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

[Anshul Dalal]

On Mon Jun 9, 2025 at 8:53 PM IST, Andrew Davis wrote:
> 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?
>

I don't see much value to such a config fragment, we already create
unsigned binaries without having a conditional build for it. Existing
customers can continue using tispl as usual and ignore the tifalcon.bin
file just like any other binaries binman produces.

>> 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`.
>

I agree that A53 build is just an overly complicated way to package
binaries for falcon boot if you only consider OS_BOOT use case but I
expect most users would have built A53 at least once from where they can
directly use the tifalcon binary.

Having tifalcon be part of A53 build also keep the clean separation
between R5 binaries (tiboot3) and **mostly** A53 ones (optee and atf).