[PATCH v7 00/10] Add falcon support for am62a, 62p and 62x

[PATCH v7 00/10] Add falcon support for am62a, 62p and 62x

[Anshul Dalal]

This patch set adds support for falcon boot on AM62a, 62p and 62x by
bypassing A53 SPL and U-boot.

Existing Boot flow:
R5 SPL -> ATF -> A53 SPL -> U-Boot -> Linux Kernel

Updated flow:
R5 SPL -> ATF -> Linux Kernel

U-boot's falcon flow expects the jump from SPL to kernel to happen on
the same core which is not directly applicable for our heterogeneous
platforms since ATF, OPTEE and other non SPL binaries from tispl.bin
should be loaded before the kernel by the R5 SPL.

So we have to use a non std flow to bypass A53 SPL and U-Boot, we first
load the newly added tispl_falcon.bin instead of tispl.bin which lacks
u-boot-spl.bin (A53's SPL) and the corresponding fdt. This sets up dm,
tifs, optee and atf. Once loaded, we load the kernel and the dtb (with
fixups) at ATF's PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE.

NOTE:
Since we're now using the SPL to load the kernel and kernel expects a
2MiB aligned load address, the existing PRELOADED_BL33_BASE has to be
changed for ATF to 0x82000000 with K3_HW_CONFIG_BASE set to
0x88000000 for the DTB.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
Changes in v7:
 * Replaced AM62a/p documentation with a hyperlink to AM62x's docs
 * Made CMD_BOOTZ disabled for TI_SECURE_DEVICE
v6: https://lore.kernel.org/u-boot/20250428141235.1734014-1-anshuld@ti.com/
Changes in v6:
 * Added A53 build steps in docs
 * Had git add SVGs as text instead of blob
 * Added memory map for standard boot flow
v5: https://lore.kernel.org/u-boot/20250425145644.2228186-1-anshuld@ti.com/
Changes in v5:
 * Added documentation
 * Moved address for kernel and dtb to 0x82000000 and 0x88000000 respectively
v4: https://lore.kernel.org/u-boot/20250416074515.1452854-1-anshuld@ti.com/
Changes in v4:
 * Move emmc boot fixes to saperate patch
 * Update load address for kernel to 0x82200000
 * Add jump_stub config
v3: https://lore.kernel.org/u-boot/20250403215910.1292922-1-anshuld@ti.com/
Changes in v3:
 * Make tifs load and entry address consistent with tispl for am62a and 62p
 * Update loadables order to be same as tispl.bin
 * Use rootfs for boot instead of boot partition
 * Disable SPL_HAS_BOOTZ to save space
 * Add default dtbs for each board in Kconfig
 * Fix fdt totalsize in the header before applying fixups
 * Update Makefile to clean tispl_falcon.bin on `make clean`
v2: https://lore.kernel.org/u-boot/20250311095758.3383047-1-anshuld@ti.com/
Changes in v2:
 * Move to CONFIG_SYS_SPI_*
 * Remove the need for CMD_BOOTI
v1: https://lore.kernel.org/u-boot/20250307075541.2571104-1-anshuld@ti.com/
---

Anshul Dalal (10):
  spl: Kconfig: allow K3 devices to use falcon mode
  spl: make CMD_BOOTZ exclusive with TI_SECURE_DEVICE
  mach-k3: fix reading size and addr from fdt on R5
  arch: arm: k3-binman: add fit for falcon boot
  mach-k3: sysfw-loader: update img_hdr for falcon
  config: add falcon boot config fragment for am62x
  board: ti: add default dtb for am62 in falcon mode
  mach-k3: common: enable falcon mode for 62 platform
  Makefile: update tispl regex to also clean falcon spl
  doc: ti: am62: add falcon mode documentation

 Makefile                                      |   2 +-
 arch/arm/dts/k3-am625-sk-binman.dtsi          |  64 ++++
 arch/arm/dts/k3-am62a-sk-binman.dtsi          |  64 ++++
 arch/arm/dts/k3-am62p-sk-binman.dtsi          |  51 ++++
 arch/arm/dts/k3-binman.dtsi                   |  54 ++++
 arch/arm/mach-k3/common.c                     | 107 +++++++
 arch/arm/mach-k3/common_fdt.c                 |   4 +-
 arch/arm/mach-k3/r5/sysfw-loader.c            |   6 +-
 board/ti/am62ax/Kconfig                       |   3 +
 board/ti/am62px/Kconfig                       |   3 +
 board/ti/am62x/Kconfig                        |   3 +
 cmd/Kconfig                                   |   1 +
 common/spl/Kconfig                            |   2 +-
 configs/am62x_r5_falcon.config                |  38 +++
 doc/board/ti/am62ax_sk.rst                    |   7 +
 doc/board/ti/am62px_sk.rst                    |   7 +
 doc/board/ti/am62x_sk.rst                     | 289 ++++++++++++++++++
 doc/board/ti/img/fitImage_falcon.svg          | 180 +++++++++++
 .../ti/img/tifsstub_dm_tispl_falcon.bin.svg   | 285 +++++++++++++++++
 19 files changed, 1166 insertions(+), 4 deletions(-)
 create mode 100644 configs/am62x_r5_falcon.config
 create mode 100644 doc/board/ti/img/fitImage_falcon.svg
 create mode 100644 doc/board/ti/img/tifsstub_dm_tispl_falcon.bin.svg

-- 
2.49.0

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

[Anshul Dalal]

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

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

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?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Anshul Dalal]

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.

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

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

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Anshul Dalal]

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.

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3401 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Anshul Dalal]

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 ;)

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4305 bytes --]

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?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Anshul Dalal]

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.

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5309 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[PATCH v7 02/10] spl: make CMD_BOOTZ exclusive with TI_SECURE_DEVICE

[Anshul Dalal]

In the secure OS_BOOT spl execution code path, CMD_BOOTZ enables loading
of a zImage which might allow an attacker to bypass the authenticated
boot with fitImage by replacing it with a malicious image with header
identical to zImage.

Disabling CMD_BOOTZ ensures this code path is never hit inside
spl_parse_image_header.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 cmd/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index f21d27cb27f..4c23f04c699 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -353,6 +353,7 @@ config BOOTM_ELF
 
 config CMD_BOOTZ
 	bool "bootz"
+	depends on !TI_SECURE_DEVICE
 	help
 	  Boot the Linux zImage
 
-- 
2.49.0

Re: [PATCH v7 02/10] spl: make CMD_BOOTZ exclusive with TI_SECURE_DEVICE

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Tue, Jun 03, 2025 at 07:54:42PM +0530, Anshul Dalal wrote:

> In the secure OS_BOOT spl execution code path, CMD_BOOTZ enables loading
> of a zImage which might allow an attacker to bypass the authenticated
> boot with fitImage by replacing it with a malicious image with header
> identical to zImage.
> 
> Disabling CMD_BOOTZ ensures this code path is never hit inside
> spl_parse_image_header.
> 
> Signed-off-by: Anshul Dalal <anshuld@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[PATCH v7 03/10] mach-k3: fix reading size and addr from fdt on R5

[Anshul Dalal]

fdtdec_get_addr_size uses architecture dependent datatypes which causes
the 32-bit R5 to fail when reading the 64-bit size and addr fields of
reg nodes from the fdt.

This changes it to a common api for both 64 and 32 bit platforms.
Now fdt fixups can be applied to the fdt from R5.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 arch/arm/mach-k3/common_fdt.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/common_fdt.c b/arch/arm/mach-k3/common_fdt.c
index 867ed173142..4824650ac76 100644
--- a/arch/arm/mach-k3/common_fdt.c
+++ b/arch/arm/mach-k3/common_fdt.c
@@ -140,7 +140,9 @@ int fdt_fixup_reserved(void *blob, const char *name,
 			return -EINVAL;
 		if (!strncmp(node_name, name, strlen(name))) {
 			/* Read out old size first */
-			addr = fdtdec_get_addr_size(blob, subnode, "reg", &size);
+			addr = fdtdec_get_addr_size_fixed(
+				blob, subnode, "reg", 0, 8 / sizeof(fdt32_t),
+				8 / sizeof(fdt32_t), &size, false);
 			if (addr == FDT_ADDR_T_NONE)
 				return -EINVAL;
 			new_size = size;
-- 
2.49.0

[PATCH v7 04/10] arch: arm: k3-binman: add fit for falcon boot

[Anshul Dalal]

This adds creation of tispl_falcon.bin for the am62a, 62p and 62x.

The contents are the same as the existing tispl.bin but A53's spl and
the fdt have been removed as they are not needed in falcon boot.

This reduces boot time since the payload size is smaller and we also
aren't authenticating the spl and fdt in secure boot.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 arch/arm/dts/k3-am625-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
 arch/arm/dts/k3-am62a-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
 arch/arm/dts/k3-am62p-sk-binman.dtsi | 51 ++++++++++++++++++++++
 arch/arm/dts/k3-binman.dtsi          | 54 +++++++++++++++++++++++
 4 files changed, 233 insertions(+)

diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi b/arch/arm/dts/k3-am625-sk-binman.dtsi
index cc619f5920e..9544b9d1134 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -211,6 +211,70 @@
 		};
 	};
 
+	ti-falcon {
+		insert-template = <&ti_falcon_template>;
+
+		fit {
+			images {
+				tifsstub-hs {
+					description = "TIFSSTUB";
+					type = "firmware";
+					arch = "arm32";
+					compression = "none";
+					os = "tifsstub-hs";
+					load = <0x9dc00000>;
+					entry = <0x9dc00000>;
+					blob-ext {
+						filename = "tifsstub.bin_hs";
+					};
+				};
+				tifsstub-fs {
+					description = "TIFSSTUB";
+					type = "firmware";
+					arch = "arm32";
+					compression = "none";
+					os = "tifsstub-fs";
+					load = <0x9dc00000>;
+					entry = <0x9dc00000>;
+					blob-ext {
+						filename = "tifsstub.bin_fs";
+					};
+				};
+				tifsstub-gp {
+					description = "TIFSSTUB";
+					type = "firmware";
+					arch = "arm32";
+					compression = "none";
+					os = "tifsstub-gp";
+					load = <0x9dc00000>;
+					entry = <0x9dc00000>;
+					blob-ext {
+						filename = "tifsstub.bin_gp";
+					};
+				};
+				dm {
+					ti-secure {
+						content = <&dm_falcon>;
+						keyfile = "custMpk.pem";
+					};
+					dm_falcon: ti-dm {
+						filename = "ti-dm.bin";
+					};
+				};
+			};
+
+			configurations {
+				default = "conf-0";
+				conf-0 {
+					description = "k3-am625-sk-falcon";
+					firmware = "atf";
+					loadables = "tee", "tifsstub-hs", "tifsstub-fs",
+					"tifsstub-gp", "dm";
+				};
+			};
+		};
+	};
+
 	ti-spl {
 		insert-template = <&ti_spl_template>;
 
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi b/arch/arm/dts/k3-am62a-sk-binman.dtsi
index ed973541fff..810907e8417 100644
--- a/arch/arm/dts/k3-am62a-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -203,6 +203,70 @@
 		};
 	};
 
+	ti-falcon {
+		insert-template = <&ti_falcon_template>;
+
+		fit {
+			images {
+				tifsstub-hs {
+					description = "TIFSSTUB";
+					type = "firmware";
+					arch = "arm32";
+					compression = "none";
+					os = "tifsstub-hs";
+					load = <0x9ca00000>;
+					entry = <0x9ca00000>;
+					blob-ext {
+						filename = "tifsstub.bin_hs";
+					};
+				};
+				tifsstub-fs {
+					description = "TIFSSTUB";
+					type = "firmware";
+					arch = "arm32";
+					compression = "none";
+					os = "tifsstub-fs";
+					load = <0x9ca00000>;
+					entry = <0x9ca00000>;
+					blob-ext {
+						filename = "tifsstub.bin_fs";
+					};
+				};
+				tifsstub-gp {
+					description = "TIFSSTUB";
+					type = "firmware";
+					arch = "arm32";
+					compression = "none";
+					os = "tifsstub-gp";
+					load = <0x9ca00000>;
+					entry = <0x9ca00000>;
+					blob-ext {
+						filename = "tifsstub.bin_gp";
+					};
+				};
+				dm {
+					ti-secure {
+						content = <&dm_falcon>;
+						keyfile = "custMpk.pem";
+					};
+					dm_falcon: ti-dm {
+						filename = "ti-dm.bin";
+					};
+				};
+			};
+
+			configurations {
+				default = "conf-0";
+				conf-0 {
+					description = "k3-am62a7-sk-falcon";
+					firmware = "atf";
+					loadables = "tee", "dm", "tifsstub-hs", "tifsstub-fs",
+					"tifsstub-gp";
+				};
+			};
+		};
+	};
+
 	ti-spl {
 		insert-template = <&ti_spl_template>;
 
diff --git a/arch/arm/dts/k3-am62p-sk-binman.dtsi b/arch/arm/dts/k3-am62p-sk-binman.dtsi
index 8216add3498..7b8f0dff50d 100644
--- a/arch/arm/dts/k3-am62p-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62p-sk-binman.dtsi
@@ -165,6 +165,57 @@
 
 	};
 
+	ti-falcon {
+		insert-template = <&ti_falcon_template>;
+
+		fit {
+			images {
+				tifsstub-hs {
+					description = "TIFSSTUB";
+					type = "firmware";
+					arch = "arm32";
+					compression = "none";
+					os = "tifsstub-hs";
+					load = <0x9ca00000>;
+					entry = <0x9ca00000>;
+					blob-ext {
+						filename = "tifsstub.bin_hs";
+					};
+				};
+				tifsstub-fs {
+					description = "TIFSSTUB";
+					type = "firmware";
+					arch = "arm32";
+					compression = "none";
+					os = "tifsstub-fs";
+					load = <0x9ca00000>;
+					entry = <0x9ca00000>;
+					blob-ext {
+						filename = "tifsstub.bin_fs";
+					};
+				};
+				dm {
+					ti-secure {
+						content = <&dm_falcon>;
+						keyfile = "custMpk.pem";
+					};
+					dm_falcon: ti-dm {
+						filename = "ti-dm.bin";
+					};
+				};
+			};
+
+			configurations {
+				default = "conf-0";
+				conf-0 {
+					description = "k3-am62p5-sk-falcon";
+					firmware = "atf";
+					loadables = "tee", "dm", "tifsstub-hs", "tifsstub-fs";
+				};
+			};
+		};
+	};
+
 	ti-spl {
 		insert-template = <&ti_spl_template>;
 
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 5163161b94d..a678379dae9 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -489,6 +489,60 @@
 		end_address = <0x0 0x9fffffff>;
 	};
 
+	ti_falcon_template: template-9 {
+		filename = "tispl_falcon.bin";
+		pad-byte = <0xff>;
+
+		fit {
+			description = "Configuration without SPL and FDT";
+			#address-cells = <1>;
+
+			images {
+				atf {
+					description = "ARM Trusted Firmware";
+					type = "firmware";
+					arch = "arm64";
+					compression = "none";
+					os = "arm-trusted-firmware";
+					load = <CONFIG_K3_ATF_LOAD_ADDR>;
+					entry = <CONFIG_K3_ATF_LOAD_ADDR>;
+					ti-secure {
+						content = <&atf_falcon>;
+						keyfile = "custMpk.pem";
+					};
+					atf_falcon: atf-bl31 {
+					};
+				};
+				tee {
+					description = "OP-TEE";
+					type = "tee";
+					arch = "arm64";
+					compression = "none";
+					os = "tee";
+					load = <CONFIG_K3_OPTEE_LOAD_ADDR>;
+					entry = <CONFIG_K3_OPTEE_LOAD_ADDR>;
+					ti-secure {
+						content = <&tee_falcon>;
+						keyfile = "custMpk.pem";
+					};
+					tee_falcon: tee-os {
+						optional;
+					};
+				};
+				dm {
+					description = "DM binary";
+					type = "firmware";
+					arch = "arm32";
+					compression = "none";
+					os = "DM";
+					load = <0x89000000>;
+					entry = <0x89000000>;
+				};
+
+			};
+		};
+	};
+
 };
 
 #endif
-- 
2.49.0

Re: [PATCH v7 04/10] arch: arm: k3-binman: add fit for falcon boot

[Bryan Brattlof]

On June  3, 2025 thus sayeth Anshul Dalal:
> This adds creation of tispl_falcon.bin for the am62a, 62p and 62x.
> 
> The contents are the same as the existing tispl.bin but A53's spl and
> the fdt have been removed as they are not needed in falcon boot.
> 
> This reduces boot time since the payload size is smaller and we also
> aren't authenticating the spl and fdt in secure boot.
> 
> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> ---
>  arch/arm/dts/k3-am625-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>  arch/arm/dts/k3-am62a-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>  arch/arm/dts/k3-am62p-sk-binman.dtsi | 51 ++++++++++++++++++++++
>  arch/arm/dts/k3-binman.dtsi          | 54 +++++++++++++++++++++++
>  4 files changed, 233 insertions(+)
> 
> diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi b/arch/arm/dts/k3-am625-sk-binman.dtsi
> index cc619f5920e..9544b9d1134 100644
> --- a/arch/arm/dts/k3-am625-sk-binman.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-binman.dtsi

...

> +				dm {
> +					ti-secure {
> +						content = <&dm_falcon>;
> +						keyfile = "custMpk.pem";
> +					};
> +					dm_falcon: ti-dm {
> +						filename = "ti-dm.bin";
> +					};

When you build this are you using the TI_DM argument? Or are you using 
BINMAN_INDIRS to point to all the firmware? I think this will only look 
for "${BINMAN_INDIRS}/ti-dm.bin" and error out now that DM is mandatory 
unless you use TI_DM which will break a few distro builders' recipes

...

> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
> index 5163161b94d..a678379dae9 100644
> --- a/arch/arm/dts/k3-binman.dtsi
> +++ b/arch/arm/dts/k3-binman.dtsi
> @@ -489,6 +489,60 @@
>  		end_address = <0x0 0x9fffffff>;
>  	};
>  
> +	ti_falcon_template: template-9 {
> +		filename = "tispl_falcon.bin";

Small nitpick: We could probably just call this tifalcon.bin or 
something shorter. It's not really an SPL now.

The bigger issue here (in my mind) is this requires our falcon.config 
fragment to work properly. I don't think it is wise of use to produce 
this image if that fragment isn't applied. It would be a debugging 
nightmare for others outside of the U-Boot space.

> +		pad-byte = <0xff>;
> +
> +		fit {
> +			description = "Configuration without SPL and FDT";
> +			#address-cells = <1>;
> +
> +			images {
> +				atf {
> +					description = "ARM Trusted Firmware";
> +					type = "firmware";
> +					arch = "arm64";
> +					compression = "none";
> +					os = "arm-trusted-firmware";
> +					load = <CONFIG_K3_ATF_LOAD_ADDR>;
> +					entry = <CONFIG_K3_ATF_LOAD_ADDR>;
> +					ti-secure {
> +						content = <&atf_falcon>;
> +						keyfile = "custMpk.pem";
> +					};
> +					atf_falcon: atf-bl31 {
> +					};
> +				};
> +				tee {
> +					description = "OP-TEE";
> +					type = "tee";
> +					arch = "arm64";
> +					compression = "none";
> +					os = "tee";
> +					load = <CONFIG_K3_OPTEE_LOAD_ADDR>;
> +					entry = <CONFIG_K3_OPTEE_LOAD_ADDR>;
> +					ti-secure {
> +						content = <&tee_falcon>;
> +						keyfile = "custMpk.pem";
> +					};
> +					tee_falcon: tee-os {
> +						optional;
> +					};
> +				};
> +				dm {
> +					description = "DM binary";
> +					type = "firmware";
> +					arch = "arm32";
> +					compression = "none";
> +					os = "DM";
> +					load = <0x89000000>;
> +					entry = <0x89000000>;
> +				};
> +
> +			};
> +		};
> +	};
> +
>  };
>  
>  #endif
> -- 
> 2.49.0
> 

Re: [PATCH v7 04/10] arch: arm: k3-binman: add fit for falcon boot

[Anshul Dalal]

On Fri Jun 6, 2025 at 5:27 PM IST, Bryan Brattlof wrote:
> On June  3, 2025 thus sayeth Anshul Dalal:
>> This adds creation of tispl_falcon.bin for the am62a, 62p and 62x.
>> 
>> The contents are the same as the existing tispl.bin but A53's spl and
>> the fdt have been removed as they are not needed in falcon boot.
>> 
>> This reduces boot time since the payload size is smaller and we also
>> aren't authenticating the spl and fdt in secure boot.
>> 
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> ---
>>  arch/arm/dts/k3-am625-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>>  arch/arm/dts/k3-am62a-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>>  arch/arm/dts/k3-am62p-sk-binman.dtsi | 51 ++++++++++++++++++++++
>>  arch/arm/dts/k3-binman.dtsi          | 54 +++++++++++++++++++++++
>>  4 files changed, 233 insertions(+)
>> 
>> diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi b/arch/arm/dts/k3-am625-sk-binman.dtsi
>> index cc619f5920e..9544b9d1134 100644
>> --- a/arch/arm/dts/k3-am625-sk-binman.dtsi
>> +++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
>
> ...
>
>> +				dm {
>> +					ti-secure {
>> +						content = <&dm_falcon>;
>> +						keyfile = "custMpk.pem";
>> +					};
>> +					dm_falcon: ti-dm {
>> +						filename = "ti-dm.bin";
>> +					};
>
> When you build this are you using the TI_DM argument? Or are you using 
> BINMAN_INDIRS to point to all the firmware? I think this will only look 
> for "${BINMAN_INDIRS}/ti-dm.bin" and error out now that DM is mandatory 
> unless you use TI_DM which will break a few distro builders' recipes
>

It relies on BINMAN_INDIRS still and I hadn't updated the dm node since
c492a55fe4 ("arm: dts: k3: binman: Fix DM firmware selection"). I will
fix this in the next revision. Thanks for bringing it to my attention.

>
>> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
>> index 5163161b94d..a678379dae9 100644
>> --- a/arch/arm/dts/k3-binman.dtsi
>> +++ b/arch/arm/dts/k3-binman.dtsi
>> @@ -489,6 +489,60 @@
>>  		end_address = <0x0 0x9fffffff>;
>>  	};
>>  
>> +	ti_falcon_template: template-9 {
>> +		filename = "tispl_falcon.bin";
>
> Small nitpick: We could probably just call this tifalcon.bin or 
> something shorter. It's not really an SPL now.
>
> The bigger issue here (in my mind) is this requires our falcon.config 
> fragment to work properly. I don't think it is wise of use to produce 
> this image if that fragment isn't applied. It would be a debugging 
> nightmare for others outside of the U-Boot space.
>

The fragment applies to r5's defconfig which prevents us from doing a
conditional build of tispl or tifalcon at the a53 stage.

Either we move the tifalcon.bin generation to r5 stage which would
require not only changes to the build arguments as we would now have to
pass OPTEE/ATF and DM's path at r5 stage but considerable changes to the
SDK recipes as we would now have to deploy a binary from r5's build
output to rootfs.

Binman already produces a lot of binaries during the A-core build most
of which the end users doesn't care about. I don't see how adding
tifalcon could become a "debugging nightmare".

Regards,
Anshul

Re: [PATCH v7 04/10] arch: arm: k3-binman: add fit for falcon boot

[Andrew Davis]

On 6/9/25 2:28 AM, Anshul Dalal wrote:
> On Fri Jun 6, 2025 at 5:27 PM IST, Bryan Brattlof wrote:
>> On June  3, 2025 thus sayeth Anshul Dalal:
>>> This adds creation of tispl_falcon.bin for the am62a, 62p and 62x.
>>>
>>> The contents are the same as the existing tispl.bin but A53's spl and
>>> the fdt have been removed as they are not needed in falcon boot.
>>>
>>> This reduces boot time since the payload size is smaller and we also
>>> aren't authenticating the spl and fdt in secure boot.
>>>
>>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>>> ---
>>>   arch/arm/dts/k3-am625-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>>>   arch/arm/dts/k3-am62a-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>>>   arch/arm/dts/k3-am62p-sk-binman.dtsi | 51 ++++++++++++++++++++++
>>>   arch/arm/dts/k3-binman.dtsi          | 54 +++++++++++++++++++++++
>>>   4 files changed, 233 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi b/arch/arm/dts/k3-am625-sk-binman.dtsi
>>> index cc619f5920e..9544b9d1134 100644
>>> --- a/arch/arm/dts/k3-am625-sk-binman.dtsi
>>> +++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
>>
>> ...
>>
>>> +				dm {
>>> +					ti-secure {
>>> +						content = <&dm_falcon>;
>>> +						keyfile = "custMpk.pem";
>>> +					};
>>> +					dm_falcon: ti-dm {
>>> +						filename = "ti-dm.bin";
>>> +					};
>>
>> When you build this are you using the TI_DM argument? Or are you using
>> BINMAN_INDIRS to point to all the firmware? I think this will only look
>> for "${BINMAN_INDIRS}/ti-dm.bin" and error out now that DM is mandatory
>> unless you use TI_DM which will break a few distro builders' recipes
>>
> 
> It relies on BINMAN_INDIRS still and I hadn't updated the dm node since
> c492a55fe4 ("arm: dts: k3: binman: Fix DM firmware selection"). I will
> fix this in the next revision. Thanks for bringing it to my attention.
> 
>>
>>> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
>>> index 5163161b94d..a678379dae9 100644
>>> --- a/arch/arm/dts/k3-binman.dtsi
>>> +++ b/arch/arm/dts/k3-binman.dtsi
>>> @@ -489,6 +489,60 @@
>>>   		end_address = <0x0 0x9fffffff>;
>>>   	};
>>>   
>>> +	ti_falcon_template: template-9 {
>>> +		filename = "tispl_falcon.bin";
>>
>> Small nitpick: We could probably just call this tifalcon.bin or
>> something shorter. It's not really an SPL now.
>>
>> The bigger issue here (in my mind) is this requires our falcon.config
>> fragment to work properly. I don't think it is wise of use to produce
>> this image if that fragment isn't applied. It would be a debugging
>> nightmare for others outside of the U-Boot space.
>>
> 
> The fragment applies to r5's defconfig which prevents us from doing a
> conditional build of tispl or tifalcon at the a53 stage.
> 

You might also be able to add a config fragment that would be applied
to the A53 stage. It would only be used for this one binman task,
but isn't that all the A53 build does in the falcon boot case anyway?

> Either we move the tifalcon.bin generation to r5 stage which would
> require not only changes to the build arguments as we would now have to
> pass OPTEE/ATF and DM's path at r5 stage but considerable changes to the
> SDK recipes as we would now have to deploy a binary from r5's build
> output to rootfs.
> 

I wouldn't worry too much about the SDK, that is something we control
and is not the only user of U-Boot.

Why do we do the A53 build at all in the falcon case? If we move the
tifalcon.bin generation to R5 stage we can skip the second build,
which might be something worth doing just for that reason. Side benefit
is it would fix the above issue with non-functional `tispl_falcon.bin`.

Andrew

> Binman already produces a lot of binaries during the A-core build most
> of which the end users doesn't care about. I don't see how adding
> tifalcon could become a "debugging nightmare".
> 
> Regards,
> Anshul

Re: [PATCH v7 04/10] arch: arm: k3-binman: add fit for falcon boot

[Anshul Dalal]

On Mon Jun 9, 2025 at 8:53 PM IST, Andrew Davis wrote:
> On 6/9/25 2:28 AM, Anshul Dalal wrote:
>> On Fri Jun 6, 2025 at 5:27 PM IST, Bryan Brattlof wrote:
>>> On June  3, 2025 thus sayeth Anshul Dalal:
>>>> This adds creation of tispl_falcon.bin for the am62a, 62p and 62x.
>>>>
>>>> The contents are the same as the existing tispl.bin but A53's spl and
>>>> the fdt have been removed as they are not needed in falcon boot.
>>>>
>>>> This reduces boot time since the payload size is smaller and we also
>>>> aren't authenticating the spl and fdt in secure boot.
>>>>
>>>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>>>> ---
>>>>   arch/arm/dts/k3-am625-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>>>>   arch/arm/dts/k3-am62a-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
>>>>   arch/arm/dts/k3-am62p-sk-binman.dtsi | 51 ++++++++++++++++++++++
>>>>   arch/arm/dts/k3-binman.dtsi          | 54 +++++++++++++++++++++++
>>>>   4 files changed, 233 insertions(+)
>>>>
>>>> diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi b/arch/arm/dts/k3-am625-sk-binman.dtsi
>>>> index cc619f5920e..9544b9d1134 100644
>>>> --- a/arch/arm/dts/k3-am625-sk-binman.dtsi
>>>> +++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
>>>
>>> ...
>>>
>>>> +				dm {
>>>> +					ti-secure {
>>>> +						content = <&dm_falcon>;
>>>> +						keyfile = "custMpk.pem";
>>>> +					};
>>>> +					dm_falcon: ti-dm {
>>>> +						filename = "ti-dm.bin";
>>>> +					};
>>>
>>> When you build this are you using the TI_DM argument? Or are you using
>>> BINMAN_INDIRS to point to all the firmware? I think this will only look
>>> for "${BINMAN_INDIRS}/ti-dm.bin" and error out now that DM is mandatory
>>> unless you use TI_DM which will break a few distro builders' recipes
>>>
>> 
>> It relies on BINMAN_INDIRS still and I hadn't updated the dm node since
>> c492a55fe4 ("arm: dts: k3: binman: Fix DM firmware selection"). I will
>> fix this in the next revision. Thanks for bringing it to my attention.
>> 
>>>
>>>> diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
>>>> index 5163161b94d..a678379dae9 100644
>>>> --- a/arch/arm/dts/k3-binman.dtsi
>>>> +++ b/arch/arm/dts/k3-binman.dtsi
>>>> @@ -489,6 +489,60 @@
>>>>   		end_address = <0x0 0x9fffffff>;
>>>>   	};
>>>>   
>>>> +	ti_falcon_template: template-9 {
>>>> +		filename = "tispl_falcon.bin";
>>>
>>> Small nitpick: We could probably just call this tifalcon.bin or
>>> something shorter. It's not really an SPL now.
>>>
>>> The bigger issue here (in my mind) is this requires our falcon.config
>>> fragment to work properly. I don't think it is wise of use to produce
>>> this image if that fragment isn't applied. It would be a debugging
>>> nightmare for others outside of the U-Boot space.
>>>
>> 
>> The fragment applies to r5's defconfig which prevents us from doing a
>> conditional build of tispl or tifalcon at the a53 stage.
>> 
>
> You might also be able to add a config fragment that would be applied
> to the A53 stage. It would only be used for this one binman task,
> but isn't that all the A53 build does in the falcon boot case anyway?
>

I don't see much value to such a config fragment, we already create
unsigned binaries without having a conditional build for it. Existing
customers can continue using tispl as usual and ignore the tifalcon.bin
file just like any other binaries binman produces.

>> Either we move the tifalcon.bin generation to r5 stage which would
>> require not only changes to the build arguments as we would now have to
>> pass OPTEE/ATF and DM's path at r5 stage but considerable changes to the
>> SDK recipes as we would now have to deploy a binary from r5's build
>> output to rootfs.
>> 
>
> I wouldn't worry too much about the SDK, that is something we control
> and is not the only user of U-Boot.
>
> Why do we do the A53 build at all in the falcon case? If we move the
> tifalcon.bin generation to R5 stage we can skip the second build,
> which might be something worth doing just for that reason. Side benefit
> is it would fix the above issue with non-functional `tispl_falcon.bin`.
>

I agree that A53 build is just an overly complicated way to package
binaries for falcon boot if you only consider OS_BOOT use case but I
expect most users would have built A53 at least once from where they can
directly use the tifalcon binary.

Having tifalcon be part of A53 build also keep the clean separation
between R5 binaries (tiboot3) and **mostly** A53 ones (optee and atf).

[PATCH v7 05/10] mach-k3: sysfw-loader: update img_hdr for falcon

[Anshul Dalal]

The returned legacy_img_hdr is used by booti_setup to compute the load
address for the kernel image.

This change ensures the kernel load address is CONFIG_SYS_LOAD_ADDR in
falcon boot.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 arch/arm/mach-k3/r5/sysfw-loader.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/r5/sysfw-loader.c b/arch/arm/mach-k3/r5/sysfw-loader.c
index 188731e673d..19607606965 100644
--- a/arch/arm/mach-k3/r5/sysfw-loader.c
+++ b/arch/arm/mach-k3/r5/sysfw-loader.c
@@ -89,7 +89,11 @@ static void *sysfw_load_address;
 struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
 {
 	if (sysfw_loaded)
-		return (struct legacy_img_hdr *)(CONFIG_TEXT_BASE + offset);
+		if (IS_ENABLED(CONFIG_SPL_OS_BOOT))
+			return (struct legacy_img_hdr *)CONFIG_SYS_LOAD_ADDR;
+		else
+			return (struct legacy_img_hdr *)(CONFIG_TEXT_BASE +
+							 offset);
 	else if (sysfw_load_address)
 		return sysfw_load_address;
 	else
-- 
2.49.0

[PATCH v7 06/10] config: add falcon boot config fragment for am62x

[Anshul Dalal]

This fragment enables falcon boot for the am62x, 62a and 62p.

To have enough stack and heap space for loading kernel image as
FIT the memory map was modified by expanding stack + heap size, the
PRELOADED_BL33_BASE in ATF has to also be updated to 0x82000000 since
the kernel requires to be loaded at 2MiB aligned address along with
change changing K3_HW_CONFIG_BASE to 0x88000000 for the DT passed to
kernel.

Modified memory map for R5 SPL (modified addresses marked with *):

0x80000000 +-------------------------------+ Start of DDR
  512KiB   |   ATF reserved memory space   | CONFIG_K3_ATF_LOAD_ADDR*
0x80080000 +-------------------------------+
 31.5MiB   |            Unused             |
0x82000000 +-------------------------------+ PRELOADED_BL33_BASE* in ATF
           |                               | CONFIG_SYS_LOAD_ADDR*
   57MiB   |   Kernel + initramfs Image    | CONFIG_SPL_LOAD_FIT_ADDRESS*
           |                               |
0x85900000 +-------------------------------+
           |                               |
           |  R5 U-Boot SPL Stack + Heap   |
   39MiB   |       (size defined by        |
           |SPL_STACK_R_MALLOC_SIMPLE_LEN*)|
           |                               |
0x88000000 +-------------------------------+ CONFIG_SPL_STACK_R_ADDR*
           |                               | K3_HW_CONFIG_BASE* in ATF
   16MiB   |          Kernel DTB           | CONFIG_SPL_PAYLOAD_ARGS_ADDR*
           |                               |
0x89000000 +-------------------------------+
  331MiB   | Device Manager (DM) Load Addr |
0x9db00000 +-------------------------------+
   12MiB   |          DM Reserved          |
0x9e700000 +-------------------------------+
    1MiB   |            Unused             |
0x9e800000 +-------------------------------+ BL32_BASE in ATF
   24MiB   |             OPTEE             |
0xa0000000 +-------------------------------+ End of DDR (512MiB)

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 configs/am62x_r5_falcon.config | 38 ++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 configs/am62x_r5_falcon.config

diff --git a/configs/am62x_r5_falcon.config b/configs/am62x_r5_falcon.config
new file mode 100644
index 00000000000..c9bb8d68505
--- /dev/null
+++ b/configs/am62x_r5_falcon.config
@@ -0,0 +1,38 @@
+# Enable falcon mode
+CONFIG_SPL_OS_BOOT=y
+
+# We use envs for setting bootargs and optionally for `falcon_(image|args)_file`
+CONFIG_SPL_ENV_SUPPORT=y
+
+# Perform FDT fixups from SPL
+CONFIG_OF_SYSTEM_SETUP=y
+
+# Enabling this causes issues with EMMC FS boot,
+# When enabled the SPL tries to detect FS on boot[01] hw partition which fails
+# since we need the raw tiboot3.bin there for the board to boot instead
+CONFIG_SUPPORT_EMMC_BOOT=n
+
+# Used as the 2MiB aligned load address for kernel
+CONFIG_SYS_LOAD_ADDR=0x82000000
+CONFIG_SPL_PAYLOAD_ARGS_ADDR=0x88000000
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x82000000
+CONFIG_SPL_STACK_R_ADDR=0x88000000
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2700000
+
+# We use the rootfs (i.e partition 2) for booting which is ext4 not FAT
+CONFIG_SYS_MMCSD_FS_BOOT_PARTITION=2
+CONFIG_SPL_FS_EXT4=y
+CONFIG_SPL_FS_FAT=n
+
+# Loading tispl_falcon instead of tispl which has fdt and A53 spl saves time
+CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="boot/tispl_falcon.bin"
+CONFIG_SPL_FS_LOAD_KERNEL_NAME="boot/fitImage"
+
+# Disabled to save space on the spl
+CONFIG_TI_K3_NAVSS_UDMA=n
+
+# During SPI boot, kernel and args are loaded from the eMMC or SD and not SPI,
+# therefore we don't actually make use of these config values.
+CONFIG_SYS_SPI_KERNEL_OFFS=0
+CONFIG_SYS_SPI_ARGS_OFFS=0
+CONFIG_SYS_SPI_ARGS_SIZE=0
-- 
2.49.0

[PATCH v7 07/10] board: ti: add default dtb for am62 in falcon mode

[Anshul Dalal]

The SPL_FS_LOAD_ARGS_NAME config is used for the arguments to the kernel
(dtb in our case) in falcon boot.

Setting it in board specific Kconfig allows us to reuse the same config
fragment 'am62x_r5_falcon.config' for all 3 platforms for enabling
falcon boot.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 board/ti/am62ax/Kconfig | 3 +++
 board/ti/am62px/Kconfig | 3 +++
 board/ti/am62x/Kconfig  | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/board/ti/am62ax/Kconfig b/board/ti/am62ax/Kconfig
index 51e7b3e0eab..187e9e5c9cd 100644
--- a/board/ti/am62ax/Kconfig
+++ b/board/ti/am62ax/Kconfig
@@ -23,4 +23,7 @@ if TARGET_AM62A7_R5_EVM
 config SPL_LDSCRIPT
 	default "arch/arm/mach-omap2/u-boot-spl.lds"
 
+config SPL_FS_LOAD_ARGS_NAME
+	default "boot/dtb/ti/k3-am62a7-sk.dtb"
+
 endif
diff --git a/board/ti/am62px/Kconfig b/board/ti/am62px/Kconfig
index 9d95ffd9b29..5f7252d7b19 100644
--- a/board/ti/am62px/Kconfig
+++ b/board/ti/am62px/Kconfig
@@ -23,4 +23,7 @@ if TARGET_AM62P5_R5_EVM
 config SPL_LDSCRIPT
 	default "arch/arm/mach-omap2/u-boot-spl.lds"
 
+config SPL_FS_LOAD_ARGS_NAME
+	default "boot/dtb/ti/k3-am62p5-sk.dtb"
+
 endif
diff --git a/board/ti/am62x/Kconfig b/board/ti/am62x/Kconfig
index 610dacfdc08..1564913096c 100644
--- a/board/ti/am62x/Kconfig
+++ b/board/ti/am62x/Kconfig
@@ -32,6 +32,9 @@ config SYS_CONFIG_NAME
 config SPL_LDSCRIPT
 	default "arch/arm/mach-omap2/u-boot-spl.lds"
 
+config SPL_FS_LOAD_ARGS_NAME
+	default "boot/dtb/ti/k3-am625-sk.dtb"
+
 source "board/ti/common/Kconfig"
 
 endif
-- 
2.49.0

Re: [PATCH v7 07/10] board: ti: add default dtb for am62 in falcon mode

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Tue, Jun 03, 2025 at 07:54:47PM +0530, Anshul Dalal wrote:

> The SPL_FS_LOAD_ARGS_NAME config is used for the arguments to the kernel
> (dtb in our case) in falcon boot.
> 
> Setting it in board specific Kconfig allows us to reuse the same config
> fragment 'am62x_r5_falcon.config' for all 3 platforms for enabling
> falcon boot.
> 
> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> ---
>  board/ti/am62ax/Kconfig | 3 +++
>  board/ti/am62px/Kconfig | 3 +++
>  board/ti/am62x/Kconfig  | 3 +++
>  3 files changed, 9 insertions(+)

Why can't whatever is using the fragment also set this? Is it because
you're only using this as part of say:
make am62ax_evm_r5_defconfig am62x_falcon.config
?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v7 07/10] board: ti: add default dtb for am62 in falcon mode

[Anshul Dalal]

On Sat Jun 7, 2025 at 12:39 AM IST, Tom Rini wrote:
> On Tue, Jun 03, 2025 at 07:54:47PM +0530, Anshul Dalal wrote:
>
>> The SPL_FS_LOAD_ARGS_NAME config is used for the arguments to the kernel
>> (dtb in our case) in falcon boot.
>> 
>> Setting it in board specific Kconfig allows us to reuse the same config
>> fragment 'am62x_r5_falcon.config' for all 3 platforms for enabling
>> falcon boot.
>> 
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> ---
>>  board/ti/am62ax/Kconfig | 3 +++
>>  board/ti/am62px/Kconfig | 3 +++
>>  board/ti/am62x/Kconfig  | 3 +++
>>  3 files changed, 9 insertions(+)
>
> Why can't whatever is using the fragment also set this? Is it because
> you're only using this as part of say:
> make am62ax_evm_r5_defconfig am62x_falcon.config
> ?

Correct, having three different config fragments with only changes to the
dtb path doesn't seem very useful imo.

Re: [PATCH v7 07/10] board: ti: add default dtb for am62 in falcon mode

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

On Mon, Jun 09, 2025 at 01:05:36PM +0530, Anshul Dalal wrote:
> On Sat Jun 7, 2025 at 12:39 AM IST, Tom Rini wrote:
> > On Tue, Jun 03, 2025 at 07:54:47PM +0530, Anshul Dalal wrote:
> >
> >> The SPL_FS_LOAD_ARGS_NAME config is used for the arguments to the kernel
> >> (dtb in our case) in falcon boot.
> >> 
> >> Setting it in board specific Kconfig allows us to reuse the same config
> >> fragment 'am62x_r5_falcon.config' for all 3 platforms for enabling
> >> falcon boot.
> >> 
> >> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> >> ---
> >>  board/ti/am62ax/Kconfig | 3 +++
> >>  board/ti/am62px/Kconfig | 3 +++
> >>  board/ti/am62x/Kconfig  | 3 +++
> >>  3 files changed, 9 insertions(+)
> >
> > Why can't whatever is using the fragment also set this? Is it because
> > you're only using this as part of say:
> > make am62ax_evm_r5_defconfig am62x_falcon.config
> > ?
> 
> Correct, having three different config fragments with only changes to the
> dtb path doesn't seem very useful imo.

Then these belong back in the main defconfig itself I think.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v7 07/10] board: ti: add default dtb for am62 in falcon mode

[Anshul Dalal]

On Mon Jun 9, 2025 at 8:27 PM IST, Tom Rini wrote:
> On Mon, Jun 09, 2025 at 01:05:36PM +0530, Anshul Dalal wrote:
>> On Sat Jun 7, 2025 at 12:39 AM IST, Tom Rini wrote:
>> > On Tue, Jun 03, 2025 at 07:54:47PM +0530, Anshul Dalal wrote:
>> >
>> >> The SPL_FS_LOAD_ARGS_NAME config is used for the arguments to the kernel
>> >> (dtb in our case) in falcon boot.
>> >> 
>> >> Setting it in board specific Kconfig allows us to reuse the same config
>> >> fragment 'am62x_r5_falcon.config' for all 3 platforms for enabling
>> >> falcon boot.
>> >> 
>> >> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> >> ---
>> >>  board/ti/am62ax/Kconfig | 3 +++
>> >>  board/ti/am62px/Kconfig | 3 +++
>> >>  board/ti/am62x/Kconfig  | 3 +++
>> >>  3 files changed, 9 insertions(+)
>> >
>> > Why can't whatever is using the fragment also set this? Is it because
>> > you're only using this as part of say:
>> > make am62ax_evm_r5_defconfig am62x_falcon.config
>> > ?
>> 
>> Correct, having three different config fragments with only changes to the
>> dtb path doesn't seem very useful imo.
>
> Then these belong back in the main defconfig itself I think.

That's not an option since SPL_FS_LOAD_ARGS_NAME depends on
SPL_OS_BOOT[1] and due to the way config fragments are applied. Since we
only set OS_BOOT to y inside of the fragment, we can not define any
configs that depend on it before that in the defconfig like
SPL_FS_LOAD_ARGS_NAME, it would just default to "args" instead.

[1]: common/spl/Kconfig:794
config SPL_FS_LOAD_ARGS_NAME
	string "File to load for the OS kernel argument parameters from the filesystem"
	depends on (SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS) && SPL_OS_BOOT
	default "args"

Re: [PATCH v7 07/10] board: ti: add default dtb for am62 in falcon mode

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]

On Tue, Jun 10, 2025 at 03:41:21PM +0530, Anshul Dalal wrote:
> On Mon Jun 9, 2025 at 8:27 PM IST, Tom Rini wrote:
> > On Mon, Jun 09, 2025 at 01:05:36PM +0530, Anshul Dalal wrote:
> >> On Sat Jun 7, 2025 at 12:39 AM IST, Tom Rini wrote:
> >> > On Tue, Jun 03, 2025 at 07:54:47PM +0530, Anshul Dalal wrote:
> >> >
> >> >> The SPL_FS_LOAD_ARGS_NAME config is used for the arguments to the kernel
> >> >> (dtb in our case) in falcon boot.
> >> >> 
> >> >> Setting it in board specific Kconfig allows us to reuse the same config
> >> >> fragment 'am62x_r5_falcon.config' for all 3 platforms for enabling
> >> >> falcon boot.
> >> >> 
> >> >> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> >> >> ---
> >> >>  board/ti/am62ax/Kconfig | 3 +++
> >> >>  board/ti/am62px/Kconfig | 3 +++
> >> >>  board/ti/am62x/Kconfig  | 3 +++
> >> >>  3 files changed, 9 insertions(+)
> >> >
> >> > Why can't whatever is using the fragment also set this? Is it because
> >> > you're only using this as part of say:
> >> > make am62ax_evm_r5_defconfig am62x_falcon.config
> >> > ?
> >> 
> >> Correct, having three different config fragments with only changes to the
> >> dtb path doesn't seem very useful imo.
> >
> > Then these belong back in the main defconfig itself I think.
> 
> That's not an option since SPL_FS_LOAD_ARGS_NAME depends on
> SPL_OS_BOOT[1] and due to the way config fragments are applied. Since we
> only set OS_BOOT to y inside of the fragment, we can not define any
> configs that depend on it before that in the defconfig like
> SPL_FS_LOAD_ARGS_NAME, it would just default to "args" instead.
> 
> [1]: common/spl/Kconfig:794
> config SPL_FS_LOAD_ARGS_NAME
> 	string "File to load for the OS kernel argument parameters from the filesystem"
> 	depends on (SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS) && SPL_OS_BOOT
> 	default "args"

Config fragments can be nested, so maybe the falcon variant will need to
include the main defconfig, the falcon fragment and then set the args to
the dtb.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v7 07/10] board: ti: add default dtb for am62 in falcon mode

[Anshul Dalal]

On Tue Jun 10, 2025 at 8:16 PM IST, Tom Rini wrote:
> On Tue, Jun 10, 2025 at 03:41:21PM +0530, Anshul Dalal wrote:
>> On Mon Jun 9, 2025 at 8:27 PM IST, Tom Rini wrote:
>> > On Mon, Jun 09, 2025 at 01:05:36PM +0530, Anshul Dalal wrote:
>> >> On Sat Jun 7, 2025 at 12:39 AM IST, Tom Rini wrote:
>> >> > On Tue, Jun 03, 2025 at 07:54:47PM +0530, Anshul Dalal wrote:
>> >> >
>> >> >> The SPL_FS_LOAD_ARGS_NAME config is used for the arguments to the kernel
>> >> >> (dtb in our case) in falcon boot.
>> >> >> 
>> >> >> Setting it in board specific Kconfig allows us to reuse the same config
>> >> >> fragment 'am62x_r5_falcon.config' for all 3 platforms for enabling
>> >> >> falcon boot.
>> >> >> 
>> >> >> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> >> >> ---
>> >> >>  board/ti/am62ax/Kconfig | 3 +++
>> >> >>  board/ti/am62px/Kconfig | 3 +++
>> >> >>  board/ti/am62x/Kconfig  | 3 +++
>> >> >>  3 files changed, 9 insertions(+)
>> >> >
>> >> > Why can't whatever is using the fragment also set this? Is it because
>> >> > you're only using this as part of say:
>> >> > make am62ax_evm_r5_defconfig am62x_falcon.config
>> >> > ?
>> >> 
>> >> Correct, having three different config fragments with only changes to the
>> >> dtb path doesn't seem very useful imo.
>> >
>> > Then these belong back in the main defconfig itself I think.
>> 
>> That's not an option since SPL_FS_LOAD_ARGS_NAME depends on
>> SPL_OS_BOOT[1] and due to the way config fragments are applied. Since we
>> only set OS_BOOT to y inside of the fragment, we can not define any
>> configs that depend on it before that in the defconfig like
>> SPL_FS_LOAD_ARGS_NAME, it would just default to "args" instead.
>> 
>> [1]: common/spl/Kconfig:794
>> config SPL_FS_LOAD_ARGS_NAME
>> 	string "File to load for the OS kernel argument parameters from the filesystem"
>> 	depends on (SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS) && SPL_OS_BOOT
>> 	default "args"
>
> Config fragments can be nested, so maybe the falcon variant will need to
> include the main defconfig, the falcon fragment and then set the args to
> the dtb.

So we add 3 new defconfigs for each platforms that include their
respective defconfigs and the fragment with only the dtb changes?

That sounds good to me though why not modify the Kconfig's directly like
I did in the patch originally?

Re: [PATCH v7 07/10] board: ti: add default dtb for am62 in falcon mode

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

On Tue, Jun 10, 2025 at 09:37:54PM +0530, Anshul Dalal wrote:
> On Tue Jun 10, 2025 at 8:16 PM IST, Tom Rini wrote:
> > On Tue, Jun 10, 2025 at 03:41:21PM +0530, Anshul Dalal wrote:
> >> On Mon Jun 9, 2025 at 8:27 PM IST, Tom Rini wrote:
> >> > On Mon, Jun 09, 2025 at 01:05:36PM +0530, Anshul Dalal wrote:
> >> >> On Sat Jun 7, 2025 at 12:39 AM IST, Tom Rini wrote:
> >> >> > On Tue, Jun 03, 2025 at 07:54:47PM +0530, Anshul Dalal wrote:
> >> >> >
> >> >> >> The SPL_FS_LOAD_ARGS_NAME config is used for the arguments to the kernel
> >> >> >> (dtb in our case) in falcon boot.
> >> >> >> 
> >> >> >> Setting it in board specific Kconfig allows us to reuse the same config
> >> >> >> fragment 'am62x_r5_falcon.config' for all 3 platforms for enabling
> >> >> >> falcon boot.
> >> >> >> 
> >> >> >> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> >> >> >> ---
> >> >> >>  board/ti/am62ax/Kconfig | 3 +++
> >> >> >>  board/ti/am62px/Kconfig | 3 +++
> >> >> >>  board/ti/am62x/Kconfig  | 3 +++
> >> >> >>  3 files changed, 9 insertions(+)
> >> >> >
> >> >> > Why can't whatever is using the fragment also set this? Is it because
> >> >> > you're only using this as part of say:
> >> >> > make am62ax_evm_r5_defconfig am62x_falcon.config
> >> >> > ?
> >> >> 
> >> >> Correct, having three different config fragments with only changes to the
> >> >> dtb path doesn't seem very useful imo.
> >> >
> >> > Then these belong back in the main defconfig itself I think.
> >> 
> >> That's not an option since SPL_FS_LOAD_ARGS_NAME depends on
> >> SPL_OS_BOOT[1] and due to the way config fragments are applied. Since we
> >> only set OS_BOOT to y inside of the fragment, we can not define any
> >> configs that depend on it before that in the defconfig like
> >> SPL_FS_LOAD_ARGS_NAME, it would just default to "args" instead.
> >> 
> >> [1]: common/spl/Kconfig:794
> >> config SPL_FS_LOAD_ARGS_NAME
> >> 	string "File to load for the OS kernel argument parameters from the filesystem"
> >> 	depends on (SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS) && SPL_OS_BOOT
> >> 	default "args"
> >
> > Config fragments can be nested, so maybe the falcon variant will need to
> > include the main defconfig, the falcon fragment and then set the args to
> > the dtb.
> 
> So we add 3 new defconfigs for each platforms that include their
> respective defconfigs and the fragment with only the dtb changes?
> 
> That sounds good to me though why not modify the Kconfig's directly like
> I did in the patch originally?

The problem is that just because we can put values in a Kconfig file,
and are much more relaxed about it than the linux kernel is, does not
mean it's the right place for values used on a single platform. We do
have a few anti-pattern examples of this, but they should be fixed and
not expanded upon.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[PATCH v7 08/10] mach-k3: common: enable falcon mode for 62 platform

[Anshul Dalal]

We use the spl_board_prepare_for_boot hook to call k3_falcon_prep which
is ran after tispl is loaded but before jump_to_image.

In here, we find the boot media and load the image just as std falcon
flow (since spl_start_uboot returns 0 now). Once the kernel and args are
loaded, we perform fdt fixups on the fdt accompanying the kernel (if
loaded as FIT) or the loaded up args and return.

Now when the flow goes to jump_to_image, we do the regular pre-jump
procedure and jump to ATF which jumps to the kernel directly since we
have already loaded the kernel and dtb at their respective addresses
(PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE).

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 arch/arm/mach-k3/common.c | 107 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index fc230f180d0..70317fec19c 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -259,8 +259,115 @@ static __maybe_unused void k3_dma_remove(void)
 		pr_warn("DMA Device not found (err=%d)\n", rc);
 }
 
+#if IS_ENABLED(CONFIG_SPL_OS_BOOT) && !IS_ENABLED(CONFIG_ARM64)
+static bool tispl_loaded;
+
+int spl_start_uboot(void)
+{
+	if (!tispl_loaded)
+		return 1;
+	return 0;
+}
+
+static int k3_falcon_fdt_fixup(void *fdt)
+{
+	struct disk_partition info;
+	struct blk_desc *dev_desc;
+	char bootmedia[32];
+	char bootpart[32];
+	char str[256];
+	int ret;
+
+	strcpy(bootmedia, env_get("boot"));
+	strcpy(bootpart, env_get("bootpart"));
+	ret = blk_get_device_part_str(bootmedia, bootpart, &dev_desc, &info, 0);
+	if (ret < 0)
+		printf("Failed to get part details for %s %s [%d]\n", bootmedia,
+		       bootpart, ret);
+	sprintf(str, "console=%s root=PARTUUID=%s rootwait", env_get("console"),
+		info.uuid);
+
+	fdt_set_totalsize(fdt, fdt_totalsize(fdt) + CONFIG_SYS_FDT_PAD);
+	ret = fdt_find_and_setprop(fdt, "/chosen", "bootargs", str,
+				   strlen(str) + 1, 1);
+	if (ret) {
+		printf("Could not set bootargs: %s\n", fdt_strerror(ret));
+		return ret;
+	}
+	debug("Set bootargs to: %s\n", str);
+
+#ifdef CONFIG_OF_BOARD_SETUP
+	ret = ft_board_setup(fdt, gd->bd);
+	if (ret) {
+		printf("Failed in board fdt fixups: %s\n", fdt_strerror(ret));
+		return ret;
+	}
+#endif
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+	ret = ft_system_setup(fdt, gd->bd);
+	if (ret) {
+		printf("Failed in system fdt fixups: %s\n", fdt_strerror(ret));
+		return ret;
+	}
+#endif
+
+	return 0;
+}
+
+static int k3_falcon_prep(void)
+{
+	struct spl_image_loader *loader, *drv;
+	struct spl_image_info kernel_image;
+	struct spl_boot_device bootdev;
+	int ret = -ENXIO, n_ents;
+	void *fdt;
+
+	tispl_loaded = true;
+	memset(&kernel_image, '\0', sizeof(kernel_image));
+	drv = ll_entry_start(struct spl_image_loader, spl_image_loader);
+	n_ents = ll_entry_count(struct spl_image_loader, spl_image_loader);
+	bootdev.boot_device = spl_boot_device();
+	if (bootdev.boot_device == BOOT_DEVICE_SPI) {
+		if (strcmp(env_get("mmcdev"), "1") == 0)
+			bootdev.boot_device = BOOT_DEVICE_MMC;
+		else
+			bootdev.boot_device = BOOT_DEVICE_EMMC;
+	}
+	bootdev.boot_device_name = NULL;
+
+	for (loader = drv; loader != drv + n_ents; loader++) {
+		if (bootdev.boot_device != loader->boot_device)
+			continue;
+		if (loader) {
+			printf("Loading falcon payload from %s\n",
+			       spl_loader_name(loader));
+			ret = loader->load_image(&kernel_image, &bootdev);
+			if (ret)
+				continue;
+
+			fdt = spl_image_fdt_addr(&kernel_image);
+			if (!fdt)
+				fdt = (void *)CONFIG_SPL_PAYLOAD_ARGS_ADDR;
+			ret = k3_falcon_fdt_fixup(fdt);
+			if (ret) {
+				printf("Failed performing fdt fixups in falcon flow: [%d]\n",
+				       ret);
+				return ret;
+			}
+			return 0;
+		}
+	}
+
+	return ret;
+}
+#endif
+
 void spl_board_prepare_for_boot(void)
 {
+#if IS_ENABLED(CONFIG_SPL_OS_BOOT) && !IS_ENABLED(CONFIG_ARM64)
+	k3_falcon_prep();
+#endif
 #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
 	dcache_disable();
 #endif
-- 
2.49.0

Re: [PATCH v7 08/10] mach-k3: common: enable falcon mode for 62 platform

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2361 bytes --]

On Tue, Jun 03, 2025 at 07:54:48PM +0530, Anshul Dalal wrote:
> We use the spl_board_prepare_for_boot hook to call k3_falcon_prep which
> is ran after tispl is loaded but before jump_to_image.
> 
> In here, we find the boot media and load the image just as std falcon
> flow (since spl_start_uboot returns 0 now). Once the kernel and args are
> loaded, we perform fdt fixups on the fdt accompanying the kernel (if
> loaded as FIT) or the loaded up args and return.
> 
> Now when the flow goes to jump_to_image, we do the regular pre-jump
> procedure and jump to ATF which jumps to the kernel directly since we
> have already loaded the kernel and dtb at their respective addresses
> (PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE).
> 
> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> ---
>  arch/arm/mach-k3/common.c | 107 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 107 insertions(+)
> 
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index fc230f180d0..70317fec19c 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -259,8 +259,115 @@ static __maybe_unused void k3_dma_remove(void)
>  		pr_warn("DMA Device not found (err=%d)\n", rc);
>  }
>  
> +#if IS_ENABLED(CONFIG_SPL_OS_BOOT) && !IS_ENABLED(CONFIG_ARM64)
> +static bool tispl_loaded;
> +
> +int spl_start_uboot(void)
> +{
> +	if (!tispl_loaded)
> +		return 1;
> +	return 0;
> +}
> +
> +static int k3_falcon_fdt_fixup(void *fdt)
> +{
> +	struct disk_partition info;
> +	struct blk_desc *dev_desc;
> +	char bootmedia[32];
> +	char bootpart[32];
> +	char str[256];
> +	int ret;
> +
> +	strcpy(bootmedia, env_get("boot"));
> +	strcpy(bootpart, env_get("bootpart"));

Since we're talking secure parts, strncpy is even more important, and
being aware of:
 * Note that unlike userspace strncpy, this does not %NUL-pad the buffer.
 * However, the result is not %NUL-terminated if the source exceeds
 * @count bytes.
from lib/string.c

> +	ret = blk_get_device_part_str(bootmedia, bootpart, &dev_desc, &info, 0);
> +	if (ret < 0)
> +		printf("Failed to get part details for %s %s [%d]\n", bootmedia,
> +		       bootpart, ret);

... and bail out?

I feel like all the changes here need a read with "and on failure in secure
mode what can someone abuse this to do" in mind.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v7 08/10] mach-k3: common: enable falcon mode for 62 platform

[Anshul Dalal]

On Sat Jun 7, 2025 at 12:45 AM IST, Tom Rini wrote:
> On Tue, Jun 03, 2025 at 07:54:48PM +0530, Anshul Dalal wrote:
>> We use the spl_board_prepare_for_boot hook to call k3_falcon_prep which
>> is ran after tispl is loaded but before jump_to_image.
>> 
>> In here, we find the boot media and load the image just as std falcon
>> flow (since spl_start_uboot returns 0 now). Once the kernel and args are
>> loaded, we perform fdt fixups on the fdt accompanying the kernel (if
>> loaded as FIT) or the loaded up args and return.
>> 
>> Now when the flow goes to jump_to_image, we do the regular pre-jump
>> procedure and jump to ATF which jumps to the kernel directly since we
>> have already loaded the kernel and dtb at their respective addresses
>> (PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE).
>> 
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> ---
>>  arch/arm/mach-k3/common.c | 107 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 107 insertions(+)
>> 
>> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
>> index fc230f180d0..70317fec19c 100644
>> --- a/arch/arm/mach-k3/common.c
>> +++ b/arch/arm/mach-k3/common.c
>> @@ -259,8 +259,115 @@ static __maybe_unused void k3_dma_remove(void)
>>  		pr_warn("DMA Device not found (err=%d)\n", rc);
>>  }
>>  
>> +#if IS_ENABLED(CONFIG_SPL_OS_BOOT) && !IS_ENABLED(CONFIG_ARM64)
>> +static bool tispl_loaded;
>> +
>> +int spl_start_uboot(void)
>> +{
>> +	if (!tispl_loaded)
>> +		return 1;
>> +	return 0;
>> +}
>> +
>> +static int k3_falcon_fdt_fixup(void *fdt)
>> +{
>> +	struct disk_partition info;
>> +	struct blk_desc *dev_desc;
>> +	char bootmedia[32];
>> +	char bootpart[32];
>> +	char str[256];
>> +	int ret;
>> +
>> +	strcpy(bootmedia, env_get("boot"));
>> +	strcpy(bootpart, env_get("bootpart"));
>
> Since we're talking secure parts, strncpy is even more important, and
> being aware of:
>  * Note that unlike userspace strncpy, this does not %NUL-pad the buffer.
>  * However, the result is not %NUL-terminated if the source exceeds
>  * @count bytes.
> from lib/string.c
>

Got it, I'll update the call to strncpy(bootmedia, env_get("boot"), 32)
in the next revision.

>> +	ret = blk_get_device_part_str(bootmedia, bootpart, &dev_desc, &info, 0);
>> +	if (ret < 0)
>> +		printf("Failed to get part details for %s %s [%d]\n", bootmedia,
>> +		       bootpart, ret);
>
> ... and bail out?
>

That makes sense, in secure world we should not be proceeding in such a
case regardless. I'll propogate the error to the top and hang at
spl_prepare_for_boot if anything fails.

> I feel like all the changes here need a read with "and on failure in secure
> mode what can someone abuse this to do" in mind.

[PATCH v7 09/10] Makefile: update tispl regex to also clean falcon spl

[Anshul Dalal]

Build for A53 on am62 platforms now generates tispl_falcon.bin alongside
tispl.bin, edit the regex for `make clean` so that both files are
removed.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index f88684947ee..af53e4fa6bb 100644
--- a/Makefile
+++ b/Makefile
@@ -2225,7 +2225,7 @@ CLEAN_FILES += include/autoconf.mk* include/bmp_logo.h include/bmp_logo_data.h \
 	       include/config.h include/generated/env.* drivers/video/u_boot_logo.S \
 	       tools/version.h u-boot* MLO* SPL System.map fit-dtb.blob* \
 	       u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log \
-	       lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \
+	       lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl*.bin* \
 	       idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \
 	       mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
 	       itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
-- 
2.49.0

[PATCH v7 10/10] doc: ti: am62: add falcon mode documentation

[Anshul Dalal]

This patch adds user documentation for falcon boot for am62 platforms.
The main section is added to am62x_sk.rst and other documents just
include the section. Steps to build falcon support, usage and the
modified R5 memory map have been documented.

Two svg images have also been added for reference, one for the modified
tispl_falcon.bin and other for the falcon specific fitImage format.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 doc/board/ti/am62ax_sk.rst                    |   7 +
 doc/board/ti/am62px_sk.rst                    |   7 +
 doc/board/ti/am62x_sk.rst                     | 289 ++++++++++++++++++
 doc/board/ti/img/fitImage_falcon.svg          | 180 +++++++++++
 .../ti/img/tifsstub_dm_tispl_falcon.bin.svg   | 285 +++++++++++++++++
 5 files changed, 768 insertions(+)
 create mode 100644 doc/board/ti/img/fitImage_falcon.svg
 create mode 100644 doc/board/ti/img/tifsstub_dm_tispl_falcon.bin.svg

diff --git a/doc/board/ti/am62ax_sk.rst b/doc/board/ti/am62ax_sk.rst
index 43a1db68873..01e252ed1b9 100644
--- a/doc/board/ti/am62ax_sk.rst
+++ b/doc/board/ti/am62ax_sk.rst
@@ -192,6 +192,13 @@ https://www.ti.com/lit/pdf/spruj16 under the `Boot Mode Pins` section.
 
 For SW2 and SW1, the switch state in the "ON" position = 1.
 
+Falcon Mode
+-----------
+
+AM62A platforms support falcon mode, bypassing A-core SPL and u-boot to reduce
+boot times. See :ref:`falcon mode<am62x_evm_falcon_mode_start>` section on AM62 platforms page for detailed build
+information.
+
 Debugging U-Boot
 ----------------
 
diff --git a/doc/board/ti/am62px_sk.rst b/doc/board/ti/am62px_sk.rst
index a07d6a4da45..917e3b904a0 100644
--- a/doc/board/ti/am62px_sk.rst
+++ b/doc/board/ti/am62px_sk.rst
@@ -290,6 +290,13 @@ https://www.ti.com/lit/pdf/spruj83 under the `Boot Mode Pins` section.
 
 For SW2 and SW1, the switch state in the "ON" position = 1.
 
+Falcon Mode
+-----------
+
+AM62P platforms support falcon mode, bypassing A-core SPL and u-boot to reduce
+boot times. See :ref:`falcon mode<am62x_evm_falcon_mode_start>` section on AM62 platforms page for detailed build
+information.
+
 Debugging U-Boot
 ----------------
 
diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst
index dab2970a85c..49c5fc8e06d 100644
--- a/doc/board/ti/am62x_sk.rst
+++ b/doc/board/ti/am62x_sk.rst
@@ -526,6 +526,295 @@ Next, based on NET_VCI_STRING string mentioned in respective defconfig file `tib
 fetches `tispl.bin` and then `tispl.bin` fetches `u-boot.img` from TFTP server which
 completes Ethernet boot on the device.
 
+.. _am62x_evm_falcon_mode_start:
+
+Falcon Mode
+-----------
+
+Falcon boot flow on am62 platforms bypasses the A-core SPL and u-boot with the
+overall boot flow as below:
+
+**Normal boot flow:**
+
+* R5 SPL -> ATF -> OP-TEE -> Cortex-A SPL -> U-Boot -> Kernel
+
+**With falcon mode:**
+
+* R5 SPL -> ATF -> OP-TEE -> Kernel
+
+Build Process
+^^^^^^^^^^^^^
+
+Enabling falcon mode requires re-building ATF, U-boot and the kernel fitImage
+as follows:
+
+0. Setup environment variables:
+"""""""""""""""""""""""""""""""
+
+Refer to the :ref:`build procedure<Build Procedure>` above for setting up the
+environment variables.
+
+1. Trusted Firmware-A:
+""""""""""""""""""""""
+
+The R5 SPL in falcon mode loads the kernel at ``0x82000000`` and the
+corresponding DTB at ``0x88000000``. Therefore ATF needs to be rebuild with
+changes to the respective addresses.
+
+.. prompt:: bash $
+
+ # Change load addresses for the kernel and DTB
+ export TFA_EXTRA_ARGS="PRELOADED_BL33_BASE=0x82000000 K3_HW_CONFIG_BASE=0x88000000"
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_build_steps_tfa
+    :end-before: .. k3_rst_include_end_build_steps_tfa
+
+2. U-Boot:
+""""""""""
+
+* **2.1 R5:**
+
+.. prompt:: bash $
+
+ # use the common falcon config fragment for am62 platforms
+ export $UBOOT_FALCON_CFG_FRAGMENTR="am62x_r5_falcon.config"
+ export UBOOT_CFG_CORTEXR="${UBOOT_CFG_CORTEXR} ${UBOOT_FALCON_CFG_FRAGMENTR}"
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_build_steps_spl_r5
+    :end-before: .. k3_rst_include_end_build_steps_spl_r5
+
+* **2.2 A53:**
+
+After rebuilding ATF, the binary needs to be repackaged inside the tispl
+binaries:
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_build_steps_uboot
+    :end-before: .. k3_rst_include_end_build_steps_uboot
+
+3. fitImage:
+""""""""""""
+
+.. warning::
+
+    The ``fitImage`` available by default under ``boot/fitImage`` in rootfs of
+    the standard SDK release is not compatible with falcon mode.
+
+For secure boot in falcon mode, the compute heavy authentication required for
+the ``fitImage`` is offloaded from the slower R5 core to TIFS. This requires
+``fitImage`` to package the necessary binaries (kernel and dtb) with a
+pre-signed x509 certificate.
+
+**fitImage for falcon mode:**
+
+.. image:: img/fitImage_falcon.svg
+  :alt: fitImage for falcon boot image format
+
+* **Sources**
+
+  * **Core Secdev K3**
+
+    | **source:** https://git.ti.com/cgit/security-development-tools/core-secdev-k3
+    | **branch:** master
+
+**Follow the steps below to create a falcon compatible fitImage:**
+
+**3.1 Environment setup**
+
+.. prompt:: bash $
+
+  export DTB=path/to/dtb
+  export IMAGE=path/to/kernel-image
+
+**3.2 fitImage creation**
+
+  An Image tree source (*its*) file describes the structure and contents of the
+  final image produced by the mkimage tool.
+
+  To create the ``fitImage`` for falcon mode, create a file ``fitImage.its``
+  with the following contents inside the ``core-secdev-k3`` source directory,:
+
+.. code-block:: dts
+
+    /dts-v1/;
+
+    / {
+        description = "Kernel fitImage for falcon mode";
+        #address-cells = <1>;
+
+        images {
+            kernel-1 {
+                description = "Linux kernel";
+                data = /incbin/("Image.sec");
+                type = "kernel";
+                arch = "arm64";
+                os = "linux";
+                compression = "none";
+                load = <0x82000000>;
+                entry = <0x82000000>;
+            };
+            falcon.dtb {
+                description = "Flattened Device Tree blob";
+                data = /incbin/("falcon.dtb.sec");
+                type = "flat_dt";
+                arch = "arm64";
+                compression = "none";
+                load = <0x88000000>;
+                entry = <0x88000000>;
+            };
+        };
+
+        configurations {
+            default = "conf-falcon";
+            conf-falcon {
+                description = "Pre-signed Kernel and DTB";
+                kernel = "kernel-1";
+                fdt = "falcon.dtb";
+            };
+        };
+    };
+
+Sign the kernel and dtb using ``secure-binary-image.sh`` and create the
+``fitImage`` using mkimage:
+
+.. prompt:: bash $
+
+  # inside core-secdev-k3 source
+  cp $IMAGE Image
+  cp $DTB falcon.dtb
+  ./scripts/secure-binary-image.sh Image Image.sec
+  ./scripts/secure-binary-image.sh falcon.dtb falcon.dtb.sec
+  mkimage -f fitImage.its fitImage
+
+Usage
+^^^^^
+
+Falcon mode makes use of a cut down variant of the tispl binary called
+``tispl_falcon.bin`` with the Cortex-A SPL and it's corresponding DTBs removed.
+This file should be present alongside the existing ``tispl.bin`` after building
+U-Boot for the Cortex-A cores.
+
+- **tispl_falcon.bin**
+
+.. image:: img/tifsstub_dm_tispl_falcon.bin.svg
+  :alt: tispl_falcon.bin image format
+
+1. eMMC/SD Boot:
+""""""""""""""""
+
+Falcon mode for K3 devices only supports SD and eMMC in FS boot. The R5 SPL
+once loaded from the ``tiboot3.bin`` file from the boot partition looks for
+``tispl_falcon.bin``, the DTB and fitImage (or kernel image for unauthenticated
+boot) inside the boot directory of the second partition (rootfs).
+
+.. list-table::
+   :widths: 8 8 8 25
+   :header-rows: 1
+
+   * - File
+     - Copy path on SD/eMMC
+     - Partition
+     - Description
+
+   * - ``tiboot3.bin``
+     - ``/tiboot3.bin``
+     - boot (fat)
+     - R5 SPL with falcon support
+
+   * - ``tispl_falcon.bin``
+     - ``/boot/tispl_falcon.bin``
+     - rootfs (ext4)
+     - tispl binary without SPL for the A core and DTB
+
+   * - ``fitImage``
+     - ``/boot/fitImage``
+     - rootfs (ext4)
+     - kernel and dtb fitImage with pre-signed binaries
+
+2. OSPI Boot:
+"""""""""""""
+
+For OSPI boot, the ``tiboot3.bin`` and ``tispl_falcon.bin`` files should be
+flashed to the same addresses in flash as regular boot flow but the DTB and the
+fitImage (or kernel image for unauthenticated boot) are read from the rootfs's
+boot directory.
+
+Below commands can be used to download ``tiboot3.bin`` and ``tispl_falcon.bin``
+over tftp and then flash those to OSPI at their respective addresses.
+
+.. prompt:: bash =>
+
+  sf probe
+  tftp ${loadaddr} tiboot3.bin
+  sf update $loadaddr 0x0 $filesize
+  tftp ${loadaddr} tispl_falcon.bin
+  sf update $loadaddr 0x80000 $filesize
+
+R5 SPL Memory Map:
+^^^^^^^^^^^^^^^^^^
+
+Standard boot:
+""""""""""""""
+
+.. code-block::
+
+    0x80000000 +-------------------------------+ Start of DDR
+      512KiB   |   ATF reserved memory space   | CONFIG_K3_ATF_LOAD_ADDR
+               |                               |
+    0x80080000 +-------------------------------+ PRELOADED_BL33_BASE in ATF
+     29.5MiB   |         A53 SPL + DTB +       | CONFIG_SPL_LOAD_FIT_ADDRESS
+               | Download region for FIT in DFU|
+    0x81e00000 +-------------------------------+
+               |  R5 U-Boot SPL Stack + Heap   |
+        2MiB   |       (size defined by        |
+               | SPL_STACK_R_MALLOC_SIMPLE_LEN)|
+    0x82000000 +-------------------------------+ CONFIG_SPL_STACK_R_ADDR
+      112MiB   |            Unused             |
+    0x89000000 +-------------------------------+
+      331MiB   | Device Manager (DM) Load Addr |
+    0x9db00000 +-------------------------------+
+       12MiB   |          DM Reserved          |
+    0x9e700000 +-------------------------------+
+        1MiB   |            Unused             |
+    0x9e800000 +-------------------------------+ BL32_BASE in ATF
+       24MiB   |             OPTEE             |
+    0xa0000000 +-------------------------------+ End of DDR (512MiB)
+
+Falcon mode:
+""""""""""""
+
+.. code-block::
+
+    0x80000000 +-------------------------------+ Start of DDR
+      512KiB   |   ATF reserved memory space   | CONFIG_K3_ATF_LOAD_ADDR
+    0x80080000 +-------------------------------+
+     31.5MiB   |            Unused             |
+    0x82000000 +-------------------------------+ PRELOADED_BL33_BASE in ATF
+               |                               | CONFIG_SYS_LOAD_ADDR
+       57MiB   |   Kernel + initramfs Image    | CONFIG_SPL_LOAD_FIT_ADDRESS
+               |                               |
+    0x85900000 +-------------------------------+
+               |                               |
+               |  R5 U-Boot SPL Stack + Heap   |
+       39MiB   |       (size defined by        |
+               | SPL_STACK_R_MALLOC_SIMPLE_LEN)|
+               |                               |
+    0x88000000 +-------------------------------+ CONFIG_SPL_STACK_R_ADDR
+               |                               | K3_HW_CONFIG_BASE in ATF
+       16MiB   |          Kernel DTB           | CONFIG_SPL_PAYLOAD_ARGS_ADDR
+               |                               |
+    0x89000000 +-------------------------------+
+      331MiB   | Device Manager (DM) Load Addr |
+    0x9db00000 +-------------------------------+
+       12MiB   |          DM Reserved          |
+    0x9e700000 +-------------------------------+
+        1MiB   |            Unused             |
+    0x9e800000 +-------------------------------+ BL32_BASE in ATF
+       24MiB   |             OPTEE             |
+    0xa0000000 +-------------------------------+ End of DDR (512MiB)
+
 Debugging U-Boot
 ----------------
 
diff --git a/doc/board/ti/img/fitImage_falcon.svg b/doc/board/ti/img/fitImage_falcon.svg
new file mode 100644
index 00000000000..a22e0f6564e
--- /dev/null
+++ b/doc/board/ti/img/fitImage_falcon.svg
@@ -0,0 +1,180 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause -->
+
+<!-- Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/ -->
+
+<svg
+   version="1.1"
+   width="231"
+   height="220"
+   viewBox="-0.5 -0.5 231 220"
+   id="svg72"
+   sodipodi:docname="fitImage_falcon.svg"
+   inkscape:version="1.4.1 (93de688d07, 2025-03-30)"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg">
+  <sodipodi:namedview
+     id="namedview74"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageshadow="2"
+     inkscape:pageopacity="0.0"
+     inkscape:pagecheckerboard="0"
+     showgrid="false"
+     inkscape:zoom="2.9"
+     inkscape:cx="83.62069"
+     inkscape:cy="131.72414"
+     inkscape:window-width="1918"
+     inkscape:window-height="1078"
+     inkscape:window-x="0"
+     inkscape:window-y="0"
+     inkscape:window-maximized="0"
+     inkscape:current-layer="g62"
+     inkscape:showpageshadow="2"
+     inkscape:deskcolor="#d1d1d1" />
+  <defs
+     id="defs2">
+    <inkscape:perspective
+       sodipodi:type="inkscape:persp3d"
+       inkscape:vp_x="0 : 104.5 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_z="231 : 104.5 : 1"
+       inkscape:persp3d-origin="115.5 : 46 : 1"
+       id="perspective1" />
+  </defs>
+  <g
+     id="g62">
+    <rect
+       x="-0.06279549"
+       y="-0.062792346"
+       width="230.12561"
+       height="219.12558"
+       rx="34.518837"
+       ry="27.33382"
+       fill="#d5e8d4"
+       stroke="#82b366"
+       pointer-events="all"
+       id="rect4"
+       style="display:inline;fill:#dbe4f4;fill-opacity:1;stroke:#8166b3;stroke-width:0.888796;stroke-dasharray:none;stroke-opacity:1" />
+    <text
+       x="115.15599"
+       y="156.49472"
+       fill="#000000"
+       font-family="Helvetica"
+       font-size="12px"
+       text-anchor="middle"
+       id="text8-8-7-6-6"
+       style="display:inline"
+       inkscape:label="x509 cert">x509 Certificate</text>
+    <text
+       x="115.15598"
+       y="85.615631"
+       fill="#000000"
+       font-family="Helvetica"
+       font-size="12px"
+       text-anchor="middle"
+       id="text8-8-7-6-6-1"
+       style="display:inline"
+       inkscape:label="x509 cert">x509 Certificate</text>
+    <text
+       x="114.532"
+       y="42.263863"
+       fill="#000000"
+       font-family="Helvetica"
+       font-size="12px"
+       text-anchor="middle"
+       id="text8-8-7-6-6-5"
+       style="display:inline"
+       inkscape:label="x509 cert">Fit Header</text>
+    <text
+       x="114.78398"
+       y="106.884"
+       fill="#000000"
+       font-family="Helvetica"
+       font-size="12px"
+       text-anchor="middle"
+       id="text8-8-7-6-6-5-5"
+       style="display:inline"
+       inkscape:label="x509 cert">Kernel Image</text>
+    <rect
+       style="display:none;fill:#000000;fill-opacity:0;stroke:#000000;stroke-width:1.00157;stroke-dasharray:none;stroke-opacity:1"
+       id="rect1"
+       width="171.46796"
+       height="210.89911"
+       x="36.799908"
+       y="21.652758"
+       transform="translate(-7.533886,15.237117)" />
+    <text
+       xml:space="preserve"
+       style="font-size:21.3333px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#db8c8c;fill-opacity:1;stroke:#000000;stroke-width:1.13386"
+       x="90.327087"
+       y="177.15775"
+       id="text1"><tspan
+         sodipodi:role="line"
+         id="tspan1"
+         x="90.327087"
+         y="177.15775" /></text>
+    <text
+       xml:space="preserve"
+       style="font-size:21.3333px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#db8c8c;fill-opacity:1;stroke:#000000;stroke-width:1.13386"
+       x="106.45526"
+       y="214.93161"
+       id="text2"><tspan
+         sodipodi:role="line"
+         id="tspan2"
+         x="106.45526"
+         y="214.93161" /></text>
+    <g
+       id="g62-6"
+       transform="translate(-5.6022949,-9.676433)">
+      <text
+         x="120.33229"
+         y="188.7475"
+         fill="#000000"
+         font-family="Helvetica"
+         font-size="12px"
+         text-anchor="middle"
+         id="text8-8-7-6-6-5-2"
+         style="display:inline"
+         inkscape:label="x509 cert">DTB</text>
+    </g>
+    <rect
+       style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.13386"
+       id="rect2"
+       width="82.644012"
+       height="17.6518"
+       x="73.677986"
+       y="94.992081" />
+    <rect
+       style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.13386;stroke-dasharray:none"
+       id="rect2-7"
+       width="32.336376"
+       height="18.068098"
+       x="98.83181"
+       y="165.66302" />
+    <rect
+       style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.77036;stroke-dasharray:none"
+       id="rect3"
+       width="152.43475"
+       height="70.500725"
+       x="38.782627"
+       y="127.54861" />
+    <rect
+       style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.77036;stroke-dasharray:none"
+       id="rect3-9"
+       width="152.43475"
+       height="70.500732"
+       x="38.782623"
+       y="56.777336" />
+    <rect
+       style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.78506;stroke-dasharray:none"
+       id="rect5"
+       width="152.41736"
+       height="36.60006"
+       x="38.791306"
+       y="20.211617" />
+  </g>
+</svg>
diff --git a/doc/board/ti/img/tifsstub_dm_tispl_falcon.bin.svg b/doc/board/ti/img/tifsstub_dm_tispl_falcon.bin.svg
new file mode 100644
index 00000000000..7e2793c2ed9
--- /dev/null
+++ b/doc/board/ti/img/tifsstub_dm_tispl_falcon.bin.svg
@@ -0,0 +1,285 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause -->
+
+<!-- Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/ -->
+
+<svg
+   version="1.1"
+   width="231"
+   height="280"
+   viewBox="-0.5 -0.5 231 280"
+   id="svg72"
+   sodipodi:docname="tifsstub_dm_tispl_falcon.bin.svg"
+   inkscape:version="1.4.1 (93de688d07, 2025-03-30)"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:xlink="http://www.w3.org/1999/xlink"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns:xhtml="http://www.w3.org/1999/xhtml">
+  <sodipodi:namedview
+     id="namedview74"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageshadow="2"
+     inkscape:pageopacity="0.0"
+     inkscape:pagecheckerboard="0"
+     showgrid="false"
+     inkscape:zoom="2.3561254"
+     inkscape:cx="175.5"
+     inkscape:cy="151.30774"
+     inkscape:window-width="1920"
+     inkscape:window-height="1080"
+     inkscape:window-x="0"
+     inkscape:window-y="0"
+     inkscape:window-maximized="0"
+     inkscape:current-layer="g62"
+     inkscape:showpageshadow="2"
+     inkscape:deskcolor="#d1d1d1" />
+  <defs
+     id="defs2">
+    <inkscape:perspective
+       sodipodi:type="inkscape:persp3d"
+       inkscape:vp_x="0 : 104.5 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_z="231 : 104.5 : 1"
+       inkscape:persp3d-origin="115.5 : 46 : 1"
+       id="perspective1" />
+  </defs>
+  <g
+     id="g62">
+    <rect
+       x="-0.0064085587"
+       y="-0.0064054145"
+       width="230.01283"
+       height="278.39682"
+       rx="34.501923"
+       ry="34.727341"
+       fill="#d5e8d4"
+       stroke="#82b366"
+       pointer-events="all"
+       id="rect4"
+       style="stroke-width:1.00331" />
+    <rect
+       x="40"
+       y="30"
+       width="160"
+       height="60"
+       fill="none"
+       stroke="#000000"
+       pointer-events="all"
+       id="rect6" />
+    <g
+       transform="translate(-0.5,-0.5)"
+       id="g12">
+      <switch
+         id="switch10">
+        <foreignObject
+           style="overflow: visible; text-align: left;"
+           pointer-events="none"
+           width="100%"
+           height="100%"
+           requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+          <xhtml:div
+             style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 60px; margin-left: 41px;">
+            <xhtml:div
+               style="box-sizing: border-box; font-size: 0px; text-align: center;"
+               data-drawio-colors="color: rgb(0, 0, 0); ">
+              <xhtml:div
+                 style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">FIT Header</xhtml:div>
+            </xhtml:div>
+          </xhtml:div>
+        </foreignObject>
+        <text
+           x="120"
+           y="64"
+           fill="#000000"
+           font-family="Helvetica"
+           font-size="12px"
+           text-anchor="middle"
+           id="text8">FIT Header</text>
+      </switch>
+    </g>
+    <rect
+       x="40"
+       y="160"
+       width="160"
+       height="50"
+       fill="none"
+       stroke="#000000"
+       pointer-events="all"
+       id="rect14" />
+    <g
+       transform="translate(-0.5,-0.5)"
+       id="g20">
+      <switch
+         id="switch18">
+        <foreignObject
+           style="overflow: visible; text-align: left;"
+           pointer-events="none"
+           width="100%"
+           height="100%"
+           requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+          <xhtml:div
+             style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 185px; margin-left: 41px;">
+            <xhtml:div
+               style="box-sizing: border-box; font-size: 0px; text-align: center;"
+               data-drawio-colors="color: rgb(0, 0, 0); ">
+              <xhtml:div
+                 style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">TIFS Stub<xhtml:br />
+
+(GP, HS-FS, HS-SE)</xhtml:div>
+            </xhtml:div>
+          </xhtml:div>
+        </foreignObject>
+        <text
+           x="120"
+           y="189"
+           fill="#000000"
+           font-family="Helvetica"
+           font-size="12px"
+           text-anchor="middle"
+           id="text16">TIFS Stub...</text>
+      </switch>
+    </g>
+    <rect
+       x="40"
+       y="90"
+       width="160"
+       height="30"
+       fill="none"
+       stroke="#000000"
+       pointer-events="all"
+       id="rect22" />
+    <g
+       transform="translate(-0.5,-0.5)"
+       id="g28">
+      <switch
+         id="switch26">
+        <foreignObject
+           style="overflow: visible; text-align: left;"
+           pointer-events="none"
+           width="100%"
+           height="100%"
+           requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+          <xhtml:div
+             style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 105px; margin-left: 41px;">
+            <xhtml:div
+               style="box-sizing: border-box; font-size: 0px; text-align: center;"
+               data-drawio-colors="color: rgb(0, 0, 0); ">
+              <xhtml:div
+                 style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">TF-A</xhtml:div>
+            </xhtml:div>
+          </xhtml:div>
+        </foreignObject>
+        <text
+           x="120"
+           y="109"
+           fill="#000000"
+           font-family="Helvetica"
+           font-size="12px"
+           text-anchor="middle"
+           id="text24">TF-A</text>
+      </switch>
+    </g>
+    <rect
+       x="40"
+       y="120"
+       width="160"
+       height="40"
+       fill="none"
+       stroke="#000000"
+       pointer-events="all"
+       id="rect30" />
+    <g
+       transform="translate(-0.5,-0.5)"
+       id="g36">
+      <switch
+         id="switch34">
+        <foreignObject
+           style="overflow: visible; text-align: left;"
+           pointer-events="none"
+           width="100%"
+           height="100%"
+           requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+          <xhtml:div
+             style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 140px; margin-left: 41px;">
+            <xhtml:div
+               style="box-sizing: border-box; font-size: 0px; text-align: center;"
+               data-drawio-colors="color: rgb(0, 0, 0); ">
+              <xhtml:div
+                 style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">OP-TEE</xhtml:div>
+            </xhtml:div>
+          </xhtml:div>
+        </foreignObject>
+        <text
+           x="120"
+           y="144"
+           fill="#000000"
+           font-family="Helvetica"
+           font-size="12px"
+           text-anchor="middle"
+           id="text32">OP-TEE</text>
+      </switch>
+    </g>
+    <rect
+       x="40"
+       y="210"
+       width="160"
+       height="40"
+       fill="none"
+       stroke="#000000"
+       pointer-events="all"
+       id="rect38" />
+    <g
+       transform="translate(-0.5,-0.5)"
+       id="g44">
+      <switch
+         id="switch42">
+        <foreignObject
+           style="overflow: visible; text-align: left;"
+           pointer-events="none"
+           width="100%"
+           height="100%"
+           requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+          <xhtml:div
+             style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 230px; margin-left: 41px;">
+            <xhtml:div
+               style="box-sizing: border-box; font-size: 0px; text-align: center;"
+               data-drawio-colors="color: rgb(0, 0, 0); ">
+              <xhtml:div
+                 style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">R5 DM FW</xhtml:div>
+            </xhtml:div>
+          </xhtml:div>
+        </foreignObject>
+        <text
+           x="120"
+           y="234"
+           fill="#000000"
+           font-family="Helvetica"
+           font-size="12px"
+           text-anchor="middle"
+           id="text40">R5 DM FW</text>
+      </switch>
+    </g>
+  </g>
+  <switch
+     id="switch70">
+    <g
+       requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"
+       id="g64" />
+    <a
+       transform="translate(0,-5)"
+       xlink:href="https://www.drawio.com/doc/faq/svg-export-text-problems"
+       target="_blank"
+       id="a68">
+      <text
+         text-anchor="middle"
+         font-size="10px"
+         x="50%"
+         y="100%"
+         id="text66">Text is not SVG - cannot display</text>
+    </a>
+  </switch>
+</svg>
-- 
2.49.0

Re: [PATCH v7 00/10] Add falcon support for am62a, 62p and 62x

[Francesco Valla]

Hi Anshul,

On Tuesday, 3 June 2025 at 16:24:40 Anshul Dalal <anshuld@ti.com> wrote:
> This patch set adds support for falcon boot on AM62a, 62p and 62x by
> bypassing A53 SPL and U-boot.
> 
> Existing Boot flow:
> R5 SPL -> ATF -> A53 SPL -> U-Boot -> Linux Kernel
> 
> Updated flow:
> R5 SPL -> ATF -> Linux Kernel
>
> ...

I tried this series on a custom device based on AM62P. While it's working
mostly fine, I noticed that PWM0 is not working after a falcon boot from
R5F, while it was working correctly after a boot through full U-Boot.

After a bit of debugging, I noticed that the epwm_tbclk0 is marked as
disabled in hardware in debugfs's clk_summary even if enabled by software:

 $ head -n 2 /sys/kernel/debug/clk/clk_summary && cat /sys/kernel/debug/clk/clk_summary | grep pwm

                                 enable  prepare  protect                                duty  hardware                            connection
   clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
 clk:86:0                            0       0        0        250000000   0          0     50000      Y   23000000.pwm                    fck                      
 epwm_tbclk2                         0       0        0        0           0          0     50000      N   deviceless                      no_connection_id         
 epwm_tbclk1                         0       0        0        0           0          0     50000      N   deviceless                      no_connection_id         
 epwm_tbclk0                         1       1        0        0           0          0     50000      N   23000000.pwm                    tbclk


Reading the associated register (0x00104130) returns in fact 0x00000000,
while writing to it has no effect (and after a write the register reads
back as 0x00000000).


Do you have any idea on the reason of this behaviour? I don't think it is
directly related to the Falcon boot implementation, but probably a side
effect of it (maybe something that was enabled by A53 SPL?).

Thank you very much for the very valuable work!


Kind regards,
Francesco 

Re: [PATCH v7 00/10] Add falcon support for am62a, 62p and 62x

[Raghavendra, Vignesh]

Hi Francesco

On 6/30/2025 7:35 PM, Francesco Valla wrote:
> Hi Anshul,
> 
> On Tuesday, 3 June 2025 at 16:24:40 Anshul Dalal <anshuld@ti.com> wrote:
>> This patch set adds support for falcon boot on AM62a, 62p and 62x by
>> bypassing A53 SPL and U-boot.
>>
>> Existing Boot flow:
>> R5 SPL -> ATF -> A53 SPL -> U-Boot -> Linux Kernel
>>
>> Updated flow:
>> R5 SPL -> ATF -> Linux Kernel
>>
>> ...
> 
> I tried this series on a custom device based on AM62P. While it's working
> mostly fine, I noticed that PWM0 is not working after a falcon boot from
> R5F, while it was working correctly after a boot through full U-Boot.
> 
> After a bit of debugging, I noticed that the epwm_tbclk0 is marked as
> disabled in hardware in debugfs's clk_summary even if enabled by software:
> 
>  $ head -n 2 /sys/kernel/debug/clk/clk_summary && cat /sys/kernel/debug/clk/clk_summary | grep pwm
> 
>                                  enable  prepare  protect                                duty  hardware                            connection
>    clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
>  clk:86:0                            0       0        0        250000000   0          0     50000      Y   23000000.pwm                    fck                      
>  epwm_tbclk2                         0       0        0        0           0          0     50000      N   deviceless                      no_connection_id         
>  epwm_tbclk1                         0       0        0        0           0          0     50000      N   deviceless                      no_connection_id         
>  epwm_tbclk0                         1       1        0        0           0          0     50000      N   23000000.pwm                    tbclk
> 
> 
> Reading the associated register (0x00104130) returns in fact 0x00000000,
> while writing to it has no effect (and after a write the register reads
> back as 0x00000000).
> 
> 
> Do you have any idea on the reason of this behaviour? I don't think it is
> directly related to the Falcon boot implementation, but probably a side
> effect of it (maybe something that was enabled by A53 SPL?).
> 

My guess is that CTRL_MMR region which hosts TB_CLKEN isn't unlocked. 

We unlock the CTRL_MMR here: 
https://elixir.bootlin.com/u-boot/v2025.04/source/arch/arm/mach-k3/am62px/am62p5_init.c#L156

But its possible that DM firmware that runs after R5 SPL re-locks these
registers and Linux is no longer able to write to those registers. 
So this may need fix in the DM firmware to keep these regions unlocked.

Looking at address of tbclk (0x00104130), it should be under region 4. 
Could you try after running the equivalent of 
mmr_unlock(CTRL_MMR0_BASE, 4); at Linux prompt using devmem2 and then modify the TB_CLKEN? 


[...]

Regards
Vignesh

Re: [PATCH v7 00/10] Add falcon support for am62a, 62p and 62x

[Francesco Valla]

Hi Vignesh,

Il 2025-07-01 09:14 Raghavendra, Vignesh ha scritto:
> Hi Francesco
> 
> On 6/30/2025 7:35 PM, Francesco Valla wrote:
>> Hi Anshul,
>> 
>> On Tuesday, 3 June 2025 at 16:24:40 Anshul Dalal <anshuld@ti.com> 
>> wrote:
>>> This patch set adds support for falcon boot on AM62a, 62p and 62x by
>>> bypassing A53 SPL and U-boot.
>>> 
>>> Existing Boot flow:
>>> R5 SPL -> ATF -> A53 SPL -> U-Boot -> Linux Kernel
>>> 
>>> Updated flow:
>>> R5 SPL -> ATF -> Linux Kernel
>>> 
>>> ...
>> 
>> I tried this series on a custom device based on AM62P. While it's 
>> working
>> mostly fine, I noticed that PWM0 is not working after a falcon boot 
>> from
>> R5F, while it was working correctly after a boot through full U-Boot.
>> 
>> After a bit of debugging, I noticed that the epwm_tbclk0 is marked as
>> disabled in hardware in debugfs's clk_summary even if enabled by 
>> software:
>> 
>>  $ head -n 2 /sys/kernel/debug/clk/clk_summary && cat 
>> /sys/kernel/debug/clk/clk_summary | grep pwm
>> 
>>                                  enable  prepare  protect              
>>                   duty  hardware                            connection
>>    clock                          count    count    count        rate  
>>  accuracy phase  cycle    enable   consumer                         id
>>  clk:86:0                            0       0        0        
>> 250000000   0          0     50000      Y   23000000.pwm               
>>      fck
>>  epwm_tbclk2                         0       0        0        0       
>>     0          0     50000      N   deviceless                      
>> no_connection_id
>>  epwm_tbclk1                         0       0        0        0       
>>     0          0     50000      N   deviceless                      
>> no_connection_id
>>  epwm_tbclk0                         1       1        0        0       
>>     0          0     50000      N   23000000.pwm                    
>> tbclk
>> 
>> 
>> Reading the associated register (0x00104130) returns in fact 
>> 0x00000000,
>> while writing to it has no effect (and after a write the register 
>> reads
>> back as 0x00000000).
>> 
>> 
>> Do you have any idea on the reason of this behaviour? I don't think it 
>> is
>> directly related to the Falcon boot implementation, but probably a 
>> side
>> effect of it (maybe something that was enabled by A53 SPL?).
>> 
> 
> My guess is that CTRL_MMR region which hosts TB_CLKEN isn't unlocked.
> 
> We unlock the CTRL_MMR here:
> https://elixir.bootlin.com/u-boot/v2025.04/source/arch/arm/mach-k3/am62px/am62p5_init.c#L156
> 
> But its possible that DM firmware that runs after R5 SPL re-locks these
> registers and Linux is no longer able to write to those registers.
> So this may need fix in the DM firmware to keep these regions unlocked.
> 
> Looking at address of tbclk (0x00104130), it should be under region 4.
> Could you try after running the equivalent of
> mmr_unlock(CTRL_MMR0_BASE, 4); at Linux prompt using devmem2 and then 
> modify the TB_CLKEN?
> 

that was exactly the issue, after unlocking the CTRL_MMR region the
TB_CLKEN bits wrote correctly and the PWM started working again.
According to TRM, the correct region is number 1.

These were the issued commands to unlock the CTRL_MMR region 1:

  $ devmem2 0x105008 w 0x68EF3490
  $ devmem2 0x10500C w 0xD172BC5A

and then to write TB_CLKEN for PWM channel 0:

  $ devmem2 0x00104130 w 0x1

The clock then is marked as enabled also from a hardware point of view:

  $ head -n 2 /sys/kernel/debug/clk/clk_summary && cat 
/sys/kernel/debug/clk/clk_summary | grep pwm

                                  enable  prepare  protect                
                 duty  hardware                            connection
    clock                          count    count    count        rate   
accuracy phase  cycle    enable   consumer                         id
  epwm_tbclk2                         0       0        0        0         
   0          0     50000      Y   deviceless                      
no_connection_id
  epwm_tbclk1                         0       0        0        0         
   0          0     50000      N   deviceless                      
no_connection_id
  epwm_tbclk0                         1       1        0        0         
   0          0     50000      N   23000000.pwm                    tbclk
  clk:86:0                            0       0        0        250000000 
   0          0     50000      Y   23000000.pwm                    fck


What's the correct path to issue a bug for the DM firmware?

Thank you!

Regards,
Francesco

Re: [PATCH v7 00/10] Add falcon support for am62a, 62p and 62x

[Raghavendra, Vignesh]

Hi,

On 7/1/2025 3:53 PM, Francesco Valla wrote:
[...]

> 
> that was exactly the issue, after unlocking the CTRL_MMR region the
> TB_CLKEN bits wrote correctly and the PWM started working again.
> According to TRM, the correct region is number 1.
> 

Ah yes, sorry for the confusion

> These were the issued commands to unlock the CTRL_MMR region 1:
> 
>  $ devmem2 0x105008 w 0x68EF3490
>  $ devmem2 0x10500C w 0xD172BC5A
> 
> and then to write TB_CLKEN for PWM channel 0:
> 
>  $ devmem2 0x00104130 w 0x1
> 
> The clock then is marked as enabled also from a hardware point of view:
> 
>  $ head -n 2 /sys/kernel/debug/clk/clk_summary && cat /sys/kernel/debug/
> clk/clk_summary | grep pwm
> 
>                                  enable  prepare  protect               
>                 duty  hardware                            connection
>    clock                          count    count    count        rate  
> accuracy phase  cycle    enable   consumer                         id
>  epwm_tbclk2                         0       0        0        0        
>   0          0     50000      Y   deviceless                     
> no_connection_id
>  epwm_tbclk1                         0       0        0        0        
>   0          0     50000      N   deviceless                     
> no_connection_id
>  epwm_tbclk0                         1       1        0        0        
>   0          0     50000      N   23000000.pwm                    tbclk
>  clk:86:0                            0       0        0        250000000
>   0          0     50000      Y   23000000.pwm                    fck
> 
> 
> What's the correct path to issue a bug for the DM firmware?
> 

Thanks for the confirmation. I am tracking this internally with firmware
team. Will let you know once the fix is available.

> Thank you!
> 
> Regards,
> Francesco