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

[Tom Rini]

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
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.

-- 
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/20250610/0c4c703f/attachment.sig>