On Tue Jun 10, 2025 at 8:14 PM IST, Tom Rini wrote:
> On Tue, Jun 10, 2025 at 02:01:59PM +0530, Anshul Dalal wrote:
>> On Mon Jun 9, 2025 at 8:29 PM IST, Tom Rini wrote:
>> > On Mon, Jun 09, 2025 at 05:38:37PM +0530, Anshul Dalal wrote:
>> >> On Sat Jun 7, 2025 at 12:36 AM IST, Tom Rini wrote:
>> >> > On Tue, Jun 03, 2025 at 07:54:41PM +0530, Anshul Dalal wrote:
>> >> >
>> >> >> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>> >> >> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>> >> >> HS devices and can be enabled on K3 devices.
>> >> >>
>> >> >> For secure boot, the kernel with x509 headers can be packaged in a fit
>> >> >> container (fitImage) signed with TIFS keys for authentication.
>> >> >>
>> >> >> Signed-off-by: Anshul Dalal <ansh...@ti.com>
>> >> >> ---
>> >> >> common/spl/Kconfig | 2 +-
>> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> >> >> index 77cf04d38ed..bc5a334a1c5 100644
>> >> >> --- a/common/spl/Kconfig
>> >> >> +++ b/common/spl/Kconfig
>> >> >> @@ -1190,7 +1190,7 @@ config SPL_ONENAND_SUPPORT
>> >> >>
>> >> >> config SPL_OS_BOOT
>> >> >> bool "Activate Falcon Mode"
>> >> >> - depends on !TI_SECURE_DEVICE
>> >> >> + depends on !TI_SECURE_DEVICE || ARCH_K3
>> >> >> help
>> >> >> Enable booting directly to an OS from SPL.
>> >> >> for more info read doc/README.falcon
>> >> >
>> >> > I wonder if overloading ARCH_K3 like this isn't a great idea. Or perhaps
>> >> > TI_SECURE_DEVICE is too generic a name. I kind of want to introduce
>> >> > something that means TI Secure Boot is supported but also Falcon is
>> >> > supported, and then use that as how we disable in Kconfig various
>> >> > insecure options. And I assume that it's a matter of effort not
>> >> > technical restrictions for supporting falcon mode on older HS parts?
>> >>
>> >> I second your opinion here, the falcon boot flow we do have in K3
>> >> devices is quite different from existing platforms but still enabled by
>> >> the same SPL_OS_BOOT config. Perhaps adding a config like K3_FALCON
>> >> makes sense here.
>> >>
>> >> And yes, older HS *K3* parts should be able to support a similar falcon
>> >> style boot flow with not much changes to the k3_falcon_prep function.
>> >
>> > Maybe we need a common symbol for things that are common to all TI
>> > secure devices, and other symbols for K3 or AM33xx (or whatever is most
>> > appropriate for that overall era of parts).
>>
>> I was thinking of adding TI_SECURE_DEVICE_(LEGACY|K3) hidden config
>> symbols which TI_SECURE_DEVICE selects as below:
>>
>> config TI_SECURE_DEVICE
>> bool "HS Device Type Support"
>> depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
>> select TI_SECURE_DEVICE_LEGACY if ARCH_KEYSTONE || ARCH_OMAP2PLUS
>> select TI_SECURE_DEVICE_K3 if ARCH_K3
>>
>> We can then use TI_SECURE_DEVICE_LEGACY to disable OS_BOOT for older non
>> K3 platforms instead.
>
> The current tech today is the legacy tech tomorrow, so I think a better
> symbol name is needed for ARCH_KEYSTONE || ARCH_OMAP2PLUS, especially
> since the next question is how much do they in fact share in terms of
Agreed, I will update the names to be more descriptive of specific device.
> tooling and features. But I was also thinking that TI_SECURE_DEVICE
> should be a hidden symbol too, and used for the common-if-any parts, and
> so SPL_OS_BOOT would depend on !TI_SECURE_DEVICE_K2_OMAP2PLUS or
> whatever.
I don't think we should make TI_SECURE_DEVICE hidden since iot2050 is a
defconfig that disables TI_SECURE_DEVICE while being ARCH_K3, it's also
useful to expose it as a config to users in cases of GP devices for
example.
If we are in agreement here, I can post v8 with the suggested changes ;)
