Re: [PATCH v7 01/10] spl: Kconfig: allow K3 devices to use falcon mode

[Anshul Dalal <anshuld@ti.com>]

On Thu Jun 12, 2025 at 8:35 PM IST, Tom Rini wrote:
> On Thu, Jun 12, 2025 at 10:05:38AM +0530, Anshul Dalal wrote:
>> 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 <anshuld@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 ;)
>
> Well, with TI_SECURE_DEVICE hidden but TI_SECURE_DEVICE_K3 not, iot2050
> can be migrated easily. That should also cover the legacy-within-K3 GP
> parts too, yes?

Yes, that would work but why expose two symbols (TI_SECURE_DEVICE_K3 and
non K3) which essentially mean the same thing "disable insecure features
on this TI device" whatever the device be. We can handle the distinction
between K3 and non K3 device without exposing it to the defconfigs by
keeping the two device specific options hidden. The end user just unsets
the TI_SECURE_DEIVCE if they need to regardless of the underlying
platform.