[PATCH v2 2/8] spl: Kconfig: allow K3 devices to use falcon mode

[Andrew Davis]

On 9/24/25 7:55 AM, Anshul Dalal wrote:
> On Tue Sep 23, 2025 at 9:48 PM IST, Andrew Davis wrote:
>> On 9/23/25 8:08 AM, 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 but can now be enabled with the addition of
>>> OS_BOOT_SECURE.
>>>
>>> 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 7e87e50f693..ab780da9e1c 100644
>>> --- a/common/spl/Kconfig
>>> +++ b/common/spl/Kconfig
>>> @@ -1201,7 +1201,7 @@ config SPL_ONENAND_SUPPORT
>>>    
>>>    config SPL_OS_BOOT
>>>    	bool "Activate Falcon Mode"
>>> -	depends on !TI_SECURE_DEVICE
>>> +	select SPL_OS_BOOT_SECURE if TI_SECURE_DEVICE
>>>    	help
>>>    	  Enable booting directly to an OS from SPL.
>>>    	  for more info read doc/README.falcon
>>
>> The subject doesn't need to include "K3", this is for all
>> TI secure devices.
>>
> 
> Oh yeah, will fix in the next revision.
> 
>> This patch should also go last in the series. Not that it
>> causes any break, but feels like a "security bisectability"
>> problem to allow something and then after make it secure.
>>
> 
> I was more looking at it from the ability to test the subsequent patches
> in the series on any TI platform which would depend on this [2/8] patch.
> 
> Though your concern is valid too but there are still a few things
> remaining from this series that would need to be implemented to make
> falcon mode truly secure on TI_SECURE_DEVICE. Perhaps we should drop
> this patch until everything's in place?
> 
Yeah, I'd save this to the very end of all your series here, that way
it signals that we now think SPL_OS_BOOT_SECURE is functional and secure.

Andrew