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

[Tom Rini]

On Thu, Jun 12, 2025 at 09:01:27PM +0530, Anshul Dalal wrote:
> 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 at 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.

I worry that'll end up being more complicated than the two arch symbols
and a hidden common symbol. But lets see your suggestion in
implementation. Thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250612/55cbb06a/attachment.sig>