[PATCH v2 0/7] Add support to boot TI K3 HSM M4 core

[Andrew Davis]

On 5/6/25 9:51 AM, Beleswar Prasad Padhi wrote:
> Hi Andrew,
> 
> On 5/6/2025 4:38 PM, Andrew Davis wrote:
>> On 5/6/25 5:41 AM, Beleswar Padhi wrote:
>>> Some TI K3 SoCs like J721S2, and J784S4 have a HSM (High Security
>>> Module) M4F core in the Wakeup Voltage Domain which could be used to
>>> run secure services like Authentication. Boot flow for HSM M4 core is
>>> different than the general purpose M4F cores, and is as below:
>>>
>>
>> The below flow looks exactly like the general purpose M4F cores..
>> Why is the HSM core treated differently and this loader not made into
>> a normal remote proc driver?
> 
> 
> Not exactly, HSM core is treated differently because of following exceptions:
> 1. Device operations for HSM core (like reset/reset release) are not handled by DM. TIFS handles that with proc_boot_ctrl TI-SCI calls.

This could be added to the commit message then.

> 2. The HSM firmware is not an ELF image. So we can't use rproc elf loader with it. Manual memcpy has to be done.
> 

Why is the HSM firmware not an ELF image?

> All of that can still be accounted in the existing M4 rproc driver, but it will be a lot of if-else checks, which I don't prefer. Let me know if you prefer that way.
> 

I'm not a fan of if-else checks either, just trying to get an idea
of how many would really be needed. Judging from the below commit
I'd agree keeping it here would be the cleaner option for now.

Andrew

> Patch having HSM support in M4 remoteproc driver:
> https://gist.github.com/3V3RYONE/a15a5c6933bbc83278da9860c25ec21c
> 
>>
>> Andrew
>>
>>> 1. Request control of HSM M4F remote processor.
>>> 2. Assert Reset on the HSM M4F remote processor.
>>> 3. Request Secure Entity to Authenticate and Load HSM firmware into
>>>     core's internal SRAM memory region. For GP device, load the firmware
>>>     manually into core's SRAM region.
>>> 4. Deassert Reset on the HSM M4F remote processor.
>>> 5. Release control of HSM M4F remote processor.
>>>
>>> This series adds support to boot HSM M4 core from R5 SPL stage. The HSM
>>> firmware is packed inside the tispl.bin fit image. The firmware is
>>> unpacked into a temporary DDR address which is then used to load HSM
>>> core. The configs to boot HSM M4 core are disabled by default.
>>>
>>> v2: Changelog:
>>> [Andrew]:
>>>   1. Added support in SPL to load FIT images with no 'load' property.
>>>   2. Removed 'default = n' in CONFIG option.
>>>   3. Used __maybe_unused to decrease preprocessing.
>>>   4. Better error messages with error code.
>>> [Udit]:
>>>   1. Added 'HSM' entries in enum at the last.
>>>   2. Added error condition in if-elseif-else ladder.
>>>   3. Hang System boot when HSM failed to boot properly.
>>>
>>> Link to v1:
>>> https://lore.kernel.org/all/20250422095430.363792-1-b-padhi@ti.com/
>>>
>>> Test logs after enabling HSM boot configs:
>>> https://gist.github.com/3V3RYONE/ad33683652c8c49e4fedab49f0493e79
>>>
>>> Beleswar Padhi (7):
>>>    arm: mach-k3: Add config option for booting HSM core
>>>    spl: Use FIT data address as fallback when 'load' property is absent
>>>    arm: dts: k3-binman: Add template for packing HSM firmware
>>>    arm: dts: k3-{j721s2/j784s4}-binman: Pack HSM firmware inside
>>>      tispl.bin
>>>    arm: mach-k3: Use FIT image data addr as fallback if 'load' prop is
>>>      missing
>>>    arm: mach-k3: Explicitly identify TIFSSTUB images when discarding
>>>      buffers
>>>    arm: mach-k3: r5: common: Add support to boot HSM M4 core
>>>
>>>   arch/arm/dts/k3-binman.dtsi        |   9 +++
>>>   arch/arm/dts/k3-j721s2-binman.dtsi |  12 ++++
>>>   arch/arm/dts/k3-j784s4-binman.dtsi |  14 ++++
>>>   arch/arm/mach-k3/Kconfig           |   7 ++
>>>   arch/arm/mach-k3/r5/common.c       | 111 +++++++++++++++++++++++++++--
>>>   common/spl/spl_fit.c               |  16 ++++-
>>>   6 files changed, 164 insertions(+), 5 deletions(-)
>>>