On 5/6/2025 8:38 PM, Andrew Davis wrote:
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?
HSM firmwares are loaded by TIFS (in non-GP) flow, and TIFS does not
have elf parser.
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-pa...@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(-)
