[PATCH 2/4] arm: dts: k3-binman: Add template for packing HSM firmware

[Andrew Davis]

On 4/24/25 12:21 AM, Beleswar Prasad Padhi wrote:
> Hi Andrew,
> 
> On 22/04/25 20:04, Andrew Davis wrote:
>> On 4/22/25 4:54 AM, Beleswar Padhi wrote:
>>> The HSM M4 core needs to be booted at R5 SPL stage so that it can be
>>> used for further Authentication and security services. Therefore, the
>>> firmware for the HSM core needs to be packed in tispl.bin fit image so
>>> that it can be used by R5 SPL to boot the HSM core.
>>>
>>> Add a template for packing the HSM firmware in tispl.bin. The size of
>>> HSM firmware is padded upto 256 KB. The HSM binaries are unloaded at a
>>> temporary DDR address.
>>>
>>> Signed-off-by: Beleswar Padhi <b-padhi at ti.com>
>>> ---
>>>    arch/arm/dts/k3-binman.dtsi | 11 +++++++++++
>>>    1 file changed, 11 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
>>> index 5163161b94d..c2b8388b06e 100644
>>> --- a/arch/arm/dts/k3-binman.dtsi
>>> +++ b/arch/arm/dts/k3-binman.dtsi
>>> @@ -297,6 +297,17 @@
>>>                        };
>>>                    };
>>>    +#ifdef CONFIG_K3_HSM_FW
>>> +                hsm {
>>> +                    description = "HSM binary";
>>> +                    type = "standalone";
>>> +                    compression = "none";
>>> +                    os = "hsm";
>>> +                    load = <0x82000000>;
>>> +                    entry = <0x82000000>;
>>
>> These addresses might already be in use. Why do you need an `entry`
>> address here?
> 
> 
> SPL parses the FIT image and assigns the `image_start` based on this `entry` address.
> 
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-k3/r5/common.c?ref_type=heads#L317
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-k3/r5/common.c?ref_type=heads#L165
> 

And that `image_start` only matters for images we will be starting, what
does it do in this case? HSM is a remote core, and the actual start address
is not 0x82000000, that is the load address, it does not run from there.

The only place `image_start` for HSM is used in is in code you add in
patch [4/4], and you use it to populate `hsm_image_addr`. That is
the load address, not the start address.

> 
>> Or a `load` address?, if one isn't given then U-Boot
>> should pick a safe spot for you, or even do the operation in-place.
> 
> 
> Looks like that's not the case. When I skipped `load` section, U-Boot complains with following error:
> 

This works for other images, maybe it is not functional for SPL I'm not
sure, if not that is a bug and should be fixed.

Looking over the code, I see no reason you need to copy it to another
location before working on the image. It is an extra copy before it is
copied by rproc to the real final location.

Andrew


> ```
> U-Boot SPL 2025.04-01182-gaa96051c7f78-dirty (Apr 24 2025 - 10:42:17 +0530)
> SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)')
> Initialized 4 DRAM controllers
> SPL initial stack usage: 13456 bytes
> Trying to boot from MMC2
> Skipping authentication on GP device
> Can't load hsm: No load address and no buffer
> spl_load_simple_fit: can't load image loadables index 0 (ret = -105)
> spl_load_image_fat: error reading image tispl.bin, err - -105
> spl_load_image_ext: ext4fs mount err - 0
> Error: -2
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> ```
> 
> Thanks,
> Beleswar
> 
>>
>> Andrew
>>
>>> +                };
>>> +#endif
>>> +
>>>                    dm {
>>>                        description = "DM binary";
>>>                        type = "firmware";