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 <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 ;)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? -- Tom
signature.asc
Description: PGP signature
