On 5/7/25 5:28 AM, Beleswar Prasad Padhi wrote:
Hi Andrew,
On 06/05/25 23:42, Andrew Davis wrote:
On 5/6/25 12:19 PM, Tom Rini wrote:
On Tue, May 06, 2025 at 10:47:57PM +0530, Kumar, Udit wrote:
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.
And to be clear, why is that? Since it's preventing the use other
existing workflows...
Even if the firmware is only delivered as a raw blob we should still
be able to use existing workflows and make a proper rproc driver for
this HSM core here.
Sure, so do you wish to see a new HSM rproc driver rather than putting the code
in R5 SPL Common file?
That does seem more clean, it will probably result in more code in total,
but it will be mostly in the rproc driver. And that is better than putting
all the rproc loading directly in the R5 SPL common file.
Andrew
Thanks,
Beleswar
TF-A, TIFS, and PMMC firmware are all raw bins and we have
ti_k3_arm64_rproc.c / k3_system_controller.c / ti_power_proc.c
rproc drivers.
Andrew
