[PATCH 1/2] arm: mach-k3: am625: copy bootindex to OCRAM for main domain SPL
Raghavendra, Vignesh
vigneshr at ti.com
Thu Mar 7 05:04:34 CET 2024
Hi,
On 3/6/2024 7:14 PM, Wadim Egorov wrote:
> Hi Vignesh,
>
> Am 04.03.24 um 06:06 schrieb Vignesh Raghavendra:
>> Hi Wadim,
>>
>> On 26/02/24 19:00, Wadim Egorov wrote:
>>> Texas Instruments has begun enabling security settings on the SoCs it
>>> produces to instruct ROM and TIFS to begin protecting the Security
>>> Management Subsystem (SMS) from other binaries we load into the chip by
>>> default.
>>>
>>> One way ROM and TIFS do this is by enabling firewalls to protect the
>>> OCSRAM and HSM RAM regions they're using during bootup.
>>>
>>> The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect
>>> itself from the main domain applications. This means the 'bootindex'
>>> value in HSM RAM, left by ROM to indicate if we're using the primary
>>> or secondary boot-method, must be moved to OCSRAM (that TIFS has open
>>> for us) before we make the jump to the main domain so the main domain's
>>> bootloaders can keep access to this information.
>>>
>>> Based on commit
>>> b672e8581070 ("arm: mach-k3: copy bootindex to OCRAM for main
>>> domain SPL")
>>>
>> FYI, this is mostly a problem in non SPL flow (TI prosperity SBL for
>> example) where HSM RAM would be used by HSM firmware. This should be a
>> issue in R5 SPL flow. Do you see any issues today? If so, whats the
>> TIFS firmware being used?
>
> I remember I was losing the bootindex using ti/downstream u-boot.
> But can't figure out the exact version anymore.
> Just did a bit of testing and I can not see the Issue with the current
> u-boot.
> Boot index in 0x43c3f290 stays intact.
>
> Would it be okay to drop this patch and keep only the 2nd patch that
> factors out into get_boot_device()?
>
yeah... 2/2 is still relevant irrespective of this patch.
[...]
More information about the U-Boot
mailing list