[PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Shiva Tripathi]

Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
MMC hardware. This provides TPM 2.0 functionality through
Microsoft's fTPM Trusted Application running in OP-TEE secure world,
using eMMC RPMB as persistent storage.

fTPM support in U-Boot provides the foundation for measured boot
and disk encryption use cases.

The ARM64 condition ensures these apply only to A53/A72 cores and the
MMC condition ensures fTPM is enabled only on platforms with eMMC
hardware support.

Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
---
Changes in v2:
- Moved fTPM enablement from per-board defconfig files to common Kconfig
- Added configs to ARCH_K3 (arch/arm/Kconfig) to enable for all K3 platforms
- Added command configs to TI_COMMON_CMD_OPTIONS (board/ti/common/Kconfig)
- Added MMC dependency to address concern about boards without eMMC hardware
- Link to v1: https://lore.kernel.org/all/20260223091314.586968-1-s-tripathi1@ti.com/

---
 arch/arm/Kconfig        | 3 +++
 board/ti/common/Kconfig | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5508fce796a..eb83b5c35f1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -834,6 +834,9 @@ config ARCH_K3
 	imply DM_RNG if ARM64
 	imply TEE if ARM64
 	imply OPTEE if ARM64
+	imply TPM if ARM64 && MMC
+	imply TPM2_FTPM_TEE if ARM64 && MMC
+	imply SUPPORT_EMMC_RPMB if ARM64 && MMC
 
 config ARCH_OMAP2PLUS
 	bool "TI OMAP2+"
diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 409454813f3..149909093b3 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -61,4 +61,6 @@ config TI_COMMON_CMD_OPTIONS
 	imply CMD_SPL
 	imply CMD_TIME
 	imply CMD_USB if USB
+	imply CMD_TPM if TPM
+	imply CMD_OPTEE_RPMB if OPTEE && SUPPORT_EMMC_RPMB
 
-- 
2.34.1

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Andrew Davis]

On 2/25/26 5:24 AM, Shiva Tripathi wrote:
> Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
> MMC hardware. This provides TPM 2.0 functionality through
> Microsoft's fTPM Trusted Application running in OP-TEE secure world,
> using eMMC RPMB as persistent storage.
> 
> fTPM support in U-Boot provides the foundation for measured boot
> and disk encryption use cases.
> 
> The ARM64 condition ensures these apply only to A53/A72 cores and the
> MMC condition ensures fTPM is enabled only on platforms with eMMC
> hardware support.
> 
> Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
> ---
> Changes in v2:
> - Moved fTPM enablement from per-board defconfig files to common Kconfig
> - Added configs to ARCH_K3 (arch/arm/Kconfig) to enable for all K3 platforms
> - Added command configs to TI_COMMON_CMD_OPTIONS (board/ti/common/Kconfig)
> - Added MMC dependency to address concern about boards without eMMC hardware
> - Link to v1: https://lore.kernel.org/all/20260223091314.586968-1-s-tripathi1@ti.com/
> 
> ---
>   arch/arm/Kconfig        | 3 +++
>   board/ti/common/Kconfig | 2 ++
>   2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5508fce796a..eb83b5c35f1 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -834,6 +834,9 @@ config ARCH_K3
>   	imply DM_RNG if ARM64
>   	imply TEE if ARM64
>   	imply OPTEE if ARM64
> +	imply TPM if ARM64 && MMC
> +	imply TPM2_FTPM_TEE if ARM64 && MMC

Although maybe less-so, the fTPM can still be useful outside
of the secure storage bits that require eMMC/RPMB. Anyway,

Acked-by: Andrew Davis <afd@ti.com>

> +	imply SUPPORT_EMMC_RPMB if ARM64 && MMC
>   
>   config ARCH_OMAP2PLUS
>   	bool "TI OMAP2+"
> diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
> index 409454813f3..149909093b3 100644
> --- a/board/ti/common/Kconfig
> +++ b/board/ti/common/Kconfig
> @@ -61,4 +61,6 @@ config TI_COMMON_CMD_OPTIONS
>   	imply CMD_SPL
>   	imply CMD_TIME
>   	imply CMD_USB if USB
> +	imply CMD_TPM if TPM
> +	imply CMD_OPTEE_RPMB if OPTEE && SUPPORT_EMMC_RPMB
>   

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Tom Rini]

On Wed, 25 Feb 2026 16:54:38 +0530, Shiva Tripathi wrote:

> Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
> MMC hardware. This provides TPM 2.0 functionality through
> Microsoft's fTPM Trusted Application running in OP-TEE secure world,
> using eMMC RPMB as persistent storage.
> 
> fTPM support in U-Boot provides the foundation for measured boot
> and disk encryption use cases.
> 
> [...]

Applied to u-boot/next, thanks!

[1/1] arm: k3: Kconfig: Enable fTPM and RPMB support
      commit: 8bc2a5196c1c0bb5dbdaca073323da0015a0de37
-- 
Tom

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Shiva Tripathi]

On 3/11/26 02:15, Tom Rini wrote:
> On Wed, 25 Feb 2026 16:54:38 +0530, Shiva Tripathi wrote:
> 
>> Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
>> MMC hardware. This provides TPM 2.0 functionality through
>> Microsoft's fTPM Trusted Application running in OP-TEE secure world,
>> using eMMC RPMB as persistent storage.
>>
>> fTPM support in U-Boot provides the foundation for measured boot
>> and disk encryption use cases.
>>
>> [...]
> 
> Applied to u-boot/next, thanks!

Hi Tom,

Thanks for applying the patch. Following are the steps to test these
(I'll soon update the relevant docs for this):

a. First step is to generate fTPM TA binary using ms-tpm-20-ref [1] and
optee_ftpm [2]. I have been using yocto to generate this fTPM TA Binary,
for reference, the binary I used [3].

b. Second step is to use above fTPM TA and build optee-os with RPMB and
early TA enabled:
  make -j$(nproc) \
       CROSS_COMPILE=arm-linux-gnueabihf- \
       CROSS_COMPILE64=aarch64-linux-gnu- \
       PLATFORM=k3 \
       PLATFORM_FLAVOR=am62x \
       CFG_ARM64_core=y \
       CFG_RPMB_FS=y \
       CFG_REE_FS=n \
       CFG_EARLY_TA=y \
       CFG_RPMB_ANNOUNCE_PROBE_CAP=n \

EARLY_TA_PATHS=/path/to/bc50d971-d4c9-42c4-82cb-343fb7f37896.stripped.elf

c. The optee binary can then be used to built final u-boot images,
testing logs for reference [4]

[1]: https://github.com/microsoft/ms-tpm-20-ref.git
[2]: https://github.com/OP-TEE/optee_ftpm.git
[3]:
https://github.com/shiva-ti/ftpm-binaries/blob/main/bc50d971-d4c9-42c4-82cb-343fb7f37896.stripped.elf
[4]: https://gist.github.com/shiva-ti/8ac6aded2bf0a3c9bd99627a45b50f6b

Thanks,
Shiva

> 
> [1/1] arm: k3: Kconfig: Enable fTPM and RPMB support
>       commit: 8bc2a5196c1c0bb5dbdaca073323da0015a0de37

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Tom Rini]

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

On Tue, Mar 17, 2026 at 05:04:29PM +0530, Shiva Tripathi wrote:
> 
> 
> On 3/11/26 02:15, Tom Rini wrote:
> > On Wed, 25 Feb 2026 16:54:38 +0530, Shiva Tripathi wrote:
> > 
> >> Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
> >> MMC hardware. This provides TPM 2.0 functionality through
> >> Microsoft's fTPM Trusted Application running in OP-TEE secure world,
> >> using eMMC RPMB as persistent storage.
> >>
> >> fTPM support in U-Boot provides the foundation for measured boot
> >> and disk encryption use cases.
> >>
> >> [...]
> > 
> > Applied to u-boot/next, thanks!
> 
> Hi Tom,
> 
> Thanks for applying the patch. Following are the steps to test these
> (I'll soon update the relevant docs for this):
> 
> a. First step is to generate fTPM TA binary using ms-tpm-20-ref [1] and
> optee_ftpm [2]. I have been using yocto to generate this fTPM TA Binary,
> for reference, the binary I used [3].
> 
> b. Second step is to use above fTPM TA and build optee-os with RPMB and
> early TA enabled:
>   make -j$(nproc) \
>        CROSS_COMPILE=arm-linux-gnueabihf- \
>        CROSS_COMPILE64=aarch64-linux-gnu- \
>        PLATFORM=k3 \
>        PLATFORM_FLAVOR=am62x \
>        CFG_ARM64_core=y \
>        CFG_RPMB_FS=y \
>        CFG_REE_FS=n \
>        CFG_EARLY_TA=y \
>        CFG_RPMB_ANNOUNCE_PROBE_CAP=n \
> 
> EARLY_TA_PATHS=/path/to/bc50d971-d4c9-42c4-82cb-343fb7f37896.stripped.elf
> 
> c. The optee binary can then be used to built final u-boot images,
> testing logs for reference [4]
> 
> [1]: https://github.com/microsoft/ms-tpm-20-ref.git
> [2]: https://github.com/OP-TEE/optee_ftpm.git
> [3]:
> https://github.com/shiva-ti/ftpm-binaries/blob/main/bc50d971-d4c9-42c4-82cb-343fb7f37896.stripped.elf
> [4]: https://gist.github.com/shiva-ti/8ac6aded2bf0a3c9bd99627a45b50f6b

I will try this manually when I have a chance, thanks. Please update the
generic TI K3 documents to include this as well, too.

-- 
Tom

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

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Shiva Tripathi]

On 3/17/26 19:37, Tom Rini wrote:
> On Tue, Mar 17, 2026 at 05:04:29PM +0530, Shiva Tripathi wrote:
>>
>>
>> On 3/11/26 02:15, Tom Rini wrote:
>>> On Wed, 25 Feb 2026 16:54:38 +0530, Shiva Tripathi wrote:
>>>
>>>> Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
>>>> MMC hardware. This provides TPM 2.0 functionality through
>>>> Microsoft's fTPM Trusted Application running in OP-TEE secure world,
>>>> using eMMC RPMB as persistent storage.
>>>>
>>>> fTPM support in U-Boot provides the foundation for measured boot
>>>> and disk encryption use cases.
>>>>
>>>> [...]
>>>
>>> Applied to u-boot/next, thanks!
>>
>> Hi Tom,
>>
>> Thanks for applying the patch. Following are the steps to test these
>> (I'll soon update the relevant docs for this):
>>
>> a. First step is to generate fTPM TA binary using ms-tpm-20-ref [1] and
>> optee_ftpm [2]. I have been using yocto to generate this fTPM TA Binary,
>> for reference, the binary I used [3].
>>
>> b. Second step is to use above fTPM TA and build optee-os with RPMB and
>> early TA enabled:
>>   make -j$(nproc) \
>>        CROSS_COMPILE=arm-linux-gnueabihf- \
>>        CROSS_COMPILE64=aarch64-linux-gnu- \
>>        PLATFORM=k3 \
>>        PLATFORM_FLAVOR=am62x \
>>        CFG_ARM64_core=y \
>>        CFG_RPMB_FS=y \
>>        CFG_REE_FS=n \
>>        CFG_EARLY_TA=y \
>>        CFG_RPMB_ANNOUNCE_PROBE_CAP=n \
>>
>> EARLY_TA_PATHS=/path/to/bc50d971-d4c9-42c4-82cb-343fb7f37896.stripped.elf
>>
>> c. The optee binary can then be used to built final u-boot images,
>> testing logs for reference [4]
>>
>> [1]: https://github.com/microsoft/ms-tpm-20-ref.git
>> [2]: https://github.com/OP-TEE/optee_ftpm.git
>> [3]:
>> https://github.com/shiva-ti/ftpm-binaries/blob/main/bc50d971-d4c9-42c4-82cb-343fb7f37896.stripped.elf
>> [4]: https://gist.github.com/shiva-ti/8ac6aded2bf0a3c9bd99627a45b50f6b
> 
> I will try this manually when I have a chance, thanks. Please update the
> generic TI K3 documents to include this as well, too.
> 

Yes, I'll update the TI K3 docs.

In the above steps, I missed mentioning the eMMC RPMB must have
authenticated keys programmed for fTPM to work since it uses the RPMB
persistence storage. "CFG_RPMB_WRITE_KEY=y" while building optee-os
enables OP-TEE to program the eMMC RPMB with authentication key on first
boot. This key is derived from the HUK (Hardware Unique Key).
Programming the RPMB key is a one-time, non-reversible operation.

Thanks,
Shiva

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Ernest Van Hoecke]

On Wed, Feb 25, 2026 at 04:54:38PM +0530, Shiva Tripathi wrote:
> Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
> MMC hardware. This provides TPM 2.0 functionality through
> Microsoft's fTPM Trusted Application running in OP-TEE secure world,
> using eMMC RPMB as persistent storage.
> 
> fTPM support in U-Boot provides the foundation for measured boot
> and disk encryption use cases.
> 
> The ARM64 condition ensures these apply only to A53/A72 cores and the
> MMC condition ensures fTPM is enabled only on platforms with eMMC
> hardware support.
> 
> Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
> ---
> Changes in v2:
> - Moved fTPM enablement from per-board defconfig files to common Kconfig
> - Added configs to ARCH_K3 (arch/arm/Kconfig) to enable for all K3 platforms
> - Added command configs to TI_COMMON_CMD_OPTIONS (board/ti/common/Kconfig)
> - Added MMC dependency to address concern about boards without eMMC hardware
> - Link to v1: https://lore.kernel.org/all/20260223091314.586968-1-s-tripathi1@ti.com/
> 
> ---
>  arch/arm/Kconfig        | 3 +++
>  board/ti/common/Kconfig | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5508fce796a..eb83b5c35f1 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -834,6 +834,9 @@ config ARCH_K3
>  	imply DM_RNG if ARM64
>  	imply TEE if ARM64
>  	imply OPTEE if ARM64
> +	imply TPM if ARM64 && MMC
> +	imply TPM2_FTPM_TEE if ARM64 && MMC
> +	imply SUPPORT_EMMC_RPMB if ARM64 && MMC
>  
>  config ARCH_OMAP2PLUS
>  	bool "TI OMAP2+"
> diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
> index 409454813f3..149909093b3 100644
> --- a/board/ti/common/Kconfig
> +++ b/board/ti/common/Kconfig
> @@ -61,4 +61,6 @@ config TI_COMMON_CMD_OPTIONS
>  	imply CMD_SPL
>  	imply CMD_TIME
>  	imply CMD_USB if USB
> +	imply CMD_TPM if TPM
> +	imply CMD_OPTEE_RPMB if OPTEE && SUPPORT_EMMC_RPMB
>  
> -- 
> 2.34.1
> 

Hi Shiva,

Do these changes mean you expect any K3-based board to follow by
building OP-TEE with RPMB support (and in production provisioning an
authentication key on first boot) now?

I'm asking because we noticed errors in the below form appeared during
boot of our Verdin AM62P and Aquila AM69 now:
E/LD:  Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896
E/LD:   arch: aarch64
E/LD:  region  0: va 0x40005000 pa 0x9e900000 size 0x002000 flags rw-s (ldelf)
E/LD:  region  1: va 0x40007000 pa 0x9e902000 size 0x008000 flags r-xs (ldelf)
E/LD:  region  2: va 0x4000f000 pa 0x9e90a000 size 0x001000 flags rw-s (ldelf)
E/LD:  region  3: va 0x40010000 pa 0x9e90b000 size 0x004000 flags rw-s (ldelf)
E/LD:  region  4: va 0x40014000 pa 0x9e90f000 size 0x001000 flags r--s
E/LD:  region  5: va 0x40015000 pa 0x9e980000 size 0x011000 flags rw-s (stack)
E/LD:  region  6: va 0x4005a000 pa 0x9e910000 size 0x055000 flags r-xs [0]
E/LD:  region  7: va 0x400af000 pa 0x9e965000 size 0x01b000 flags rw-s [0]
E/LD:   [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x4005a000
E/LD:  Call stack:
E/LD:   0x4005b7b0
E/LD:   0x4008f220
E/LD:   0x40083298

Interestingly this did not appear on our Verdin AM62 SoM.

Of course, we can simply disable the fTPM until our support improves, or
ignore this error if it is harmless, but I wanted to ask about your
intentions before digging much deeper.

Thanks!

Kind regards,
Ernest

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Shiva Tripathi]

On 5/12/26 22:14, Ernest Van Hoecke wrote:
> On Wed, Feb 25, 2026 at 04:54:38PM +0530, Shiva Tripathi wrote:
>> Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
>> MMC hardware. This provides TPM 2.0 functionality through
>> Microsoft's fTPM Trusted Application running in OP-TEE secure world,
>> using eMMC RPMB as persistent storage.
>>
>> fTPM support in U-Boot provides the foundation for measured boot
>> and disk encryption use cases.
>>
>> The ARM64 condition ensures these apply only to A53/A72 cores and the
>> MMC condition ensures fTPM is enabled only on platforms with eMMC
>> hardware support.
>>
>> Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
>> ---
>> Changes in v2:
>> - Moved fTPM enablement from per-board defconfig files to common Kconfig
>> - Added configs to ARCH_K3 (arch/arm/Kconfig) to enable for all K3 platforms
>> - Added command configs to TI_COMMON_CMD_OPTIONS (board/ti/common/Kconfig)
>> - Added MMC dependency to address concern about boards without eMMC hardware
>> - Link to v1: https://lore.kernel.org/all/20260223091314.586968-1-s-tripathi1@ti.com/
>>
>> ---
>>  arch/arm/Kconfig        | 3 +++
>>  board/ti/common/Kconfig | 2 ++
>>  2 files changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 5508fce796a..eb83b5c35f1 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -834,6 +834,9 @@ config ARCH_K3
>>  	imply DM_RNG if ARM64
>>  	imply TEE if ARM64
>>  	imply OPTEE if ARM64
>> +	imply TPM if ARM64 && MMC
>> +	imply TPM2_FTPM_TEE if ARM64 && MMC
>> +	imply SUPPORT_EMMC_RPMB if ARM64 && MMC
>>  
>>  config ARCH_OMAP2PLUS
>>  	bool "TI OMAP2+"
>> diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
>> index 409454813f3..149909093b3 100644
>> --- a/board/ti/common/Kconfig
>> +++ b/board/ti/common/Kconfig
>> @@ -61,4 +61,6 @@ config TI_COMMON_CMD_OPTIONS
>>  	imply CMD_SPL
>>  	imply CMD_TIME
>>  	imply CMD_USB if USB
>> +	imply CMD_TPM if TPM
>> +	imply CMD_OPTEE_RPMB if OPTEE && SUPPORT_EMMC_RPMB
>>  
>> -- 
>> 2.34.1
>>
> 
> Hi Shiva,
> 
> Do these changes mean you expect any K3-based board to follow by
> building OP-TEE with RPMB support (and in production provisioning an
> authentication key on first boot) now?
> 
> I'm asking because we noticed errors in the below form appeared during
> boot of our Verdin AM62P and Aquila AM69 now:
> E/LD:  Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896
> E/LD:   arch: aarch64
> E/LD:  region  0: va 0x40005000 pa 0x9e900000 size 0x002000 flags rw-s (ldelf)
> E/LD:  region  1: va 0x40007000 pa 0x9e902000 size 0x008000 flags r-xs (ldelf)
> E/LD:  region  2: va 0x4000f000 pa 0x9e90a000 size 0x001000 flags rw-s (ldelf)
> E/LD:  region  3: va 0x40010000 pa 0x9e90b000 size 0x004000 flags rw-s (ldelf)
> E/LD:  region  4: va 0x40014000 pa 0x9e90f000 size 0x001000 flags r--s
> E/LD:  region  5: va 0x40015000 pa 0x9e980000 size 0x011000 flags rw-s (stack)
> E/LD:  region  6: va 0x4005a000 pa 0x9e910000 size 0x055000 flags r-xs [0]
> E/LD:  region  7: va 0x400af000 pa 0x9e965000 size 0x01b000 flags rw-s [0]
> E/LD:   [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x4005a000
> E/LD:  Call stack:
> E/LD:   0x4005b7b0
> E/LD:   0x4008f220
> E/LD:   0x40083298
> 
> Interestingly this did not appear on our Verdin AM62 SoM.
> 
> Of course, we can simply disable the fTPM until our support improves, or
> ignore this error if it is harmless, but I wanted to ask about your
> intentions before digging much deeper.
> 
> Thanks!
> 
> Kind regards,
> Ernest

Hi Ernest,

It's not expected for all K3-platforms to build OP-TEE with RPMB
support, some platforms lack eMMC entirely. fTPM is an optional
configuration for users who need measured boot, disk encryption, or
similar TPM related use-cases.

The Yocto SDK we release for K3 platforms includes the fTPM TA embedded
in the OP-TEE, not sure if the same is true in your case.

RPMB provisioning is needed for full functionality, but even without it
you shouldn't see these errors. Maybe the fTPM TA is missing from your
OP-TEE build, or something similar is causing loader error.

Regards,
Shiva

> 

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Andrew Davis]

On 5/13/26 8:06 AM, Shiva Tripathi wrote:
> 
> 
> On 5/12/26 22:14, Ernest Van Hoecke wrote:
>> On Wed, Feb 25, 2026 at 04:54:38PM +0530, Shiva Tripathi wrote:
>>> Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
>>> MMC hardware. This provides TPM 2.0 functionality through
>>> Microsoft's fTPM Trusted Application running in OP-TEE secure world,
>>> using eMMC RPMB as persistent storage.
>>>
>>> fTPM support in U-Boot provides the foundation for measured boot
>>> and disk encryption use cases.
>>>
>>> The ARM64 condition ensures these apply only to A53/A72 cores and the
>>> MMC condition ensures fTPM is enabled only on platforms with eMMC
>>> hardware support.
>>>
>>> Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
>>> ---
>>> Changes in v2:
>>> - Moved fTPM enablement from per-board defconfig files to common Kconfig
>>> - Added configs to ARCH_K3 (arch/arm/Kconfig) to enable for all K3 platforms
>>> - Added command configs to TI_COMMON_CMD_OPTIONS (board/ti/common/Kconfig)
>>> - Added MMC dependency to address concern about boards without eMMC hardware
>>> - Link to v1: https://lore.kernel.org/all/20260223091314.586968-1-s-tripathi1@ti.com/
>>>
>>> ---
>>>   arch/arm/Kconfig        | 3 +++
>>>   board/ti/common/Kconfig | 2 ++
>>>   2 files changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 5508fce796a..eb83b5c35f1 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -834,6 +834,9 @@ config ARCH_K3
>>>   	imply DM_RNG if ARM64
>>>   	imply TEE if ARM64
>>>   	imply OPTEE if ARM64
>>> +	imply TPM if ARM64 && MMC
>>> +	imply TPM2_FTPM_TEE if ARM64 && MMC
>>> +	imply SUPPORT_EMMC_RPMB if ARM64 && MMC
>>>   
>>>   config ARCH_OMAP2PLUS
>>>   	bool "TI OMAP2+"
>>> diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
>>> index 409454813f3..149909093b3 100644
>>> --- a/board/ti/common/Kconfig
>>> +++ b/board/ti/common/Kconfig
>>> @@ -61,4 +61,6 @@ config TI_COMMON_CMD_OPTIONS
>>>   	imply CMD_SPL
>>>   	imply CMD_TIME
>>>   	imply CMD_USB if USB
>>> +	imply CMD_TPM if TPM
>>> +	imply CMD_OPTEE_RPMB if OPTEE && SUPPORT_EMMC_RPMB
>>>   
>>> -- 
>>> 2.34.1
>>>
>>
>> Hi Shiva,
>>
>> Do these changes mean you expect any K3-based board to follow by
>> building OP-TEE with RPMB support (and in production provisioning an
>> authentication key on first boot) now?
>>
>> I'm asking because we noticed errors in the below form appeared during
>> boot of our Verdin AM62P and Aquila AM69 now:
>> E/LD:  Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896
>> E/LD:   arch: aarch64
>> E/LD:  region  0: va 0x40005000 pa 0x9e900000 size 0x002000 flags rw-s (ldelf)
>> E/LD:  region  1: va 0x40007000 pa 0x9e902000 size 0x008000 flags r-xs (ldelf)
>> E/LD:  region  2: va 0x4000f000 pa 0x9e90a000 size 0x001000 flags rw-s (ldelf)
>> E/LD:  region  3: va 0x40010000 pa 0x9e90b000 size 0x004000 flags rw-s (ldelf)
>> E/LD:  region  4: va 0x40014000 pa 0x9e90f000 size 0x001000 flags r--s
>> E/LD:  region  5: va 0x40015000 pa 0x9e980000 size 0x011000 flags rw-s (stack)
>> E/LD:  region  6: va 0x4005a000 pa 0x9e910000 size 0x055000 flags r-xs [0]
>> E/LD:  region  7: va 0x400af000 pa 0x9e965000 size 0x01b000 flags rw-s [0]
>> E/LD:   [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x4005a000
>> E/LD:  Call stack:
>> E/LD:   0x4005b7b0
>> E/LD:   0x4008f220
>> E/LD:   0x40083298
>>
>> Interestingly this did not appear on our Verdin AM62 SoM.
>>
>> Of course, we can simply disable the fTPM until our support improves, or
>> ignore this error if it is harmless, but I wanted to ask about your
>> intentions before digging much deeper.
>>
>> Thanks!
>>
>> Kind regards,
>> Ernest
> 
> Hi Ernest,
> 
> It's not expected for all K3-platforms to build OP-TEE with RPMB
> support, some platforms lack eMMC entirely. fTPM is an optional
> configuration for users who need measured boot, disk encryption, or
> similar TPM related use-cases.
> 
> The Yocto SDK we release for K3 platforms includes the fTPM TA embedded
> in the OP-TEE, not sure if the same is true in your case.
> 
> RPMB provisioning is needed for full functionality, but even without it
> you shouldn't see these errors. Maybe the fTPM TA is missing from your
> OP-TEE build, or something similar is causing loader error.
> 

Given the above log shows the fTPM UUID, the fTPM does look to be
loaded and running in this case. Given a more complete log from
a different thread on this issue I'm seeing:

> Cannot persist EFI variables without system partition
> <error printout above>
> Missing TPMv2 device for EFI_TCG_PROTOCOL

This makes me think we are at the stage in boot where EFI variables
are trying to be persisted to some media, and when trying to use
the fTPM for this it fails (as would be expected without RPMB).
So this should be harmless, but why there is such a large error
printout we need to investigate and try to make it less verbose.

Andrew

> Regards,
> Shiva
> 
>>
> 

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Francesco Dolcini]

Hello Andrew, Shiva

On Wed, May 13, 2026 at 08:49:31AM -0500, Andrew Davis wrote:
> On 5/13/26 8:06 AM, Shiva Tripathi wrote:
> > On 5/12/26 22:14, Ernest Van Hoecke wrote:
> > > On Wed, Feb 25, 2026 at 04:54:38PM +0530, Shiva Tripathi wrote:
> > > > Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
> > > > MMC hardware. This provides TPM 2.0 functionality through
> > > > Microsoft's fTPM Trusted Application running in OP-TEE secure world,
> > > > using eMMC RPMB as persistent storage.
> > > > 
> > > > fTPM support in U-Boot provides the foundation for measured boot
> > > > and disk encryption use cases.
> > > > 
> > > > The ARM64 condition ensures these apply only to A53/A72 cores and the
> > > > MMC condition ensures fTPM is enabled only on platforms with eMMC
> > > > hardware support.

...

> > > Do these changes mean you expect any K3-based board to follow by
> > > building OP-TEE with RPMB support (and in production provisioning an
> > > authentication key on first boot) now?
> > > 
> > > I'm asking because we noticed errors in the below form appeared during
> > > boot of our Verdin AM62P and Aquila AM69 now:
> > > E/LD:  Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896
> > > E/LD:   arch: aarch64
> > > E/LD:  region  0: va 0x40005000 pa 0x9e900000 size 0x002000 flags rw-s (ldelf)
> > > E/LD:  region  1: va 0x40007000 pa 0x9e902000 size 0x008000 flags r-xs (ldelf)
> > > E/LD:  region  2: va 0x4000f000 pa 0x9e90a000 size 0x001000 flags rw-s (ldelf)
> > > E/LD:  region  3: va 0x40010000 pa 0x9e90b000 size 0x004000 flags rw-s (ldelf)
> > > E/LD:  region  4: va 0x40014000 pa 0x9e90f000 size 0x001000 flags r--s
> > > E/LD:  region  5: va 0x40015000 pa 0x9e980000 size 0x011000 flags rw-s (stack)
> > > E/LD:  region  6: va 0x4005a000 pa 0x9e910000 size 0x055000 flags r-xs [0]
> > > E/LD:  region  7: va 0x400af000 pa 0x9e965000 size 0x01b000 flags rw-s [0]
> > > E/LD:   [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x4005a000
> > > E/LD:  Call stack:
> > > E/LD:   0x4005b7b0
> > > E/LD:   0x4008f220
> > > E/LD:   0x40083298
> > > 
> > > Interestingly this did not appear on our Verdin AM62 SoM.
> > > 
> > > Of course, we can simply disable the fTPM until our support improves, or
> > > ignore this error if it is harmless, but I wanted to ask about your
> > > intentions before digging much deeper.
> > 
> > It's not expected for all K3-platforms to build OP-TEE with RPMB
> > support, some platforms lack eMMC entirely. fTPM is an optional
> > configuration for users who need measured boot, disk encryption, or
> > similar TPM related use-cases.
> > 
> > The Yocto SDK we release for K3 platforms includes the fTPM TA embedded
> > in the OP-TEE, not sure if the same is true in your case.
> > 
> > RPMB provisioning is needed for full functionality, but even without it
> > you shouldn't see these errors. Maybe the fTPM TA is missing from your
> > OP-TEE build, or something similar is causing loader error.
> > 
> 
> Given the above log shows the fTPM UUID, the fTPM does look to be
> loaded and running in this case. Given a more complete log from
> a different thread on this issue I'm seeing:

The whole integration / optee and so on is current mainline U-Boot
v2026.07-rcX + meta-ti master branch, built together in OE with this
https://git.toradex.com/meta-toradex-bsp.git/


> So this should be harmless, but why there is such a large error
> printout we need to investigate and try to make it less verbose.

We have the same concern here. It is not clear to us why we do not
see the same on am62.

Francesco

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Francesco Dolcini]

Hello Shiva, Andrew

On Wed, May 13, 2026 at 06:36:40PM +0530, Shiva Tripathi wrote:
> It's not expected for all K3-platforms to build OP-TEE with RPMB
> support, some platforms lack eMMC entirely. fTPM is an optional
> configuration for users who need measured boot, disk encryption, or
> similar TPM related use-cases.
> 
> The Yocto SDK we release for K3 platforms includes the fTPM TA embedded
> in the OP-TEE, not sure if the same is true in your case.
> 
> RPMB provisioning is needed for full functionality, but even without it
> you shouldn't see these errors. Maybe the fTPM TA is missing from your
> OP-TEE build, or something similar is causing loader error.

Any comment on this? We are just integrating current meta-ti master with
latest master U-Boot, as I wrote a few days ago. There is nothing
special going on on our side, and your recent changes are introducing
this unexpected behavior.


On Wed, May 13, 2026 at 08:49:31AM -0500, Andrew Davis wrote:
> This makes me think we are at the stage in boot where EFI variables
> are trying to be persisted to some media, and when trying to use
> the fTPM for this it fails (as would be expected without RPMB).
> So this should be harmless, but why there is such a large error
> printout we need to investigate and try to make it less verbose.

Any chance TI can help on this?


Francesco

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Shiva Tripathi]

On 5/22/26 11:45, Francesco Dolcini wrote:
> 
> Hello Shiva, Andrew
> 
> On Wed, May 13, 2026 at 06:36:40PM +0530, Shiva Tripathi wrote:
>> It's not expected for all K3-platforms to build OP-TEE with RPMB
>> support, some platforms lack eMMC entirely. fTPM is an optional
>> configuration for users who need measured boot, disk encryption, or
>> similar TPM related use-cases.
>>
>> The Yocto SDK we release for K3 platforms includes the fTPM TA embedded
>> in the OP-TEE, not sure if the same is true in your case.
>>
>> RPMB provisioning is needed for full functionality, but even without it
>> you shouldn't see these errors. Maybe the fTPM TA is missing from your
>> OP-TEE build, or something similar is causing loader error.
> 
> Any comment on this? We are just integrating current meta-ti master with
> latest master U-Boot, as I wrote a few days ago. There is nothing
> special going on on our side, and your recent changes are introducing
> this unexpected behavior.
> 
> 
> On Wed, May 13, 2026 at 08:49:31AM -0500, Andrew Davis wrote:
>> This makes me think we are at the stage in boot where EFI variables
>> are trying to be persisted to some media, and when trying to use
>> the fTPM for this it fails (as would be expected without RPMB).
>> So this should be harmless, but why there is such a large error
>> printout we need to investigate and try to make it less verbose.
> 
> Any chance TI can help on this?

Hi Francesco,

Yes, I am looking into it. The logs are showing up as OPTEE's fTPM TA is
failing to load, since the eMMC RPMB isn't provisioned.

I am able to see these dumps on am62x as well following your setup
details i.e. with upstream u-boot, these are briefly flashed before grub
window appears. But with ti-u-boot (part of meta-ti) the logs don't show
up during boot.
The meta-ti already uses "CFG_TEE_CORE_LOG_LEVEL=1" verbosity for
OP-TEE, which doesn't prevent "dump_ta_state" from dumping these loader
errors.

Even though these logs don't affect functionality, you can revert this
patch to avoid confusion. I am checking if there's a cleaner way to
handle this.

Regards,
Shiva

> 
> 
> Francesco
> 

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Francesco Dolcini]

On Fri, May 22, 2026 at 07:49:27PM +0530, Shiva Tripathi wrote:
> On 5/22/26 11:45, Francesco Dolcini wrote:
> > On Wed, May 13, 2026 at 06:36:40PM +0530, Shiva Tripathi wrote:
> > On Wed, May 13, 2026 at 08:49:31AM -0500, Andrew Davis wrote:
> >> This makes me think we are at the stage in boot where EFI variables
> >> are trying to be persisted to some media, and when trying to use
> >> the fTPM for this it fails (as would be expected without RPMB).
> >> So this should be harmless, but why there is such a large error
> >> printout we need to investigate and try to make it less verbose.
> > 
> > Any chance TI can help on this?
> Yes, I am looking into it. The logs are showing up as OPTEE's fTPM TA is
> failing to load, since the eMMC RPMB isn't provisioned.

Thanks for looking into that, and I am glad you can reproduce the issue.

> Even though these logs don't affect functionality, you can revert this
> patch to avoid confusion. I am checking if there's a cleaner way to
> handle this.

I am using mainline U-Boot, if this needs to be reverted, it must be
reverted here. Given the release timeline, and the fact that this is not
breaking the functionality I am fine waiting a little bit to see if it
is possible to fix it, we have some time before the v2026.07 release.

Francesco

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Tom Rini]

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

On Fri, May 22, 2026 at 06:20:48PM +0200, Francesco Dolcini wrote:
> On Fri, May 22, 2026 at 07:49:27PM +0530, Shiva Tripathi wrote:
> > On 5/22/26 11:45, Francesco Dolcini wrote:
> > > On Wed, May 13, 2026 at 06:36:40PM +0530, Shiva Tripathi wrote:
> > > On Wed, May 13, 2026 at 08:49:31AM -0500, Andrew Davis wrote:
> > >> This makes me think we are at the stage in boot where EFI variables
> > >> are trying to be persisted to some media, and when trying to use
> > >> the fTPM for this it fails (as would be expected without RPMB).
> > >> So this should be harmless, but why there is such a large error
> > >> printout we need to investigate and try to make it less verbose.
> > > 
> > > Any chance TI can help on this?
> > Yes, I am looking into it. The logs are showing up as OPTEE's fTPM TA is
> > failing to load, since the eMMC RPMB isn't provisioned.
> 
> Thanks for looking into that, and I am glad you can reproduce the issue.
> 
> > Even though these logs don't affect functionality, you can revert this
> > patch to avoid confusion. I am checking if there's a cleaner way to
> > handle this.
> 
> I am using mainline U-Boot, if this needs to be reverted, it must be
> reverted here. Given the release timeline, and the fact that this is not
> breaking the functionality I am fine waiting a little bit to see if it
> is possible to fix it, we have some time before the v2026.07 release.

And for the release I would like to make sure someone has a clear path
on what changes are needed, if any in the end, on mainline U-Boot by
rc4, which is June 8th. We have the last one on June 22nd but I'd rather
not have to revert then unless things are just unresolved. Thanks!

-- 
Tom

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

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Francesco Dolcini]

Hello Shiva,

On Fri, May 22, 2026 at 11:36:37AM -0600, Tom Rini wrote:
> On Fri, May 22, 2026 at 06:20:48PM +0200, Francesco Dolcini wrote:
> > On Fri, May 22, 2026 at 07:49:27PM +0530, Shiva Tripathi wrote:
> > > On 5/22/26 11:45, Francesco Dolcini wrote:
> > > > On Wed, May 13, 2026 at 06:36:40PM +0530, Shiva Tripathi wrote:
> > > > On Wed, May 13, 2026 at 08:49:31AM -0500, Andrew Davis wrote:
> > > >> This makes me think we are at the stage in boot where EFI variables
> > > >> are trying to be persisted to some media, and when trying to use
> > > >> the fTPM for this it fails (as would be expected without RPMB).
> > > >> So this should be harmless, but why there is such a large error
> > > >> printout we need to investigate and try to make it less verbose.
> > > > 
> > > > Any chance TI can help on this?
> > > Yes, I am looking into it. The logs are showing up as OPTEE's fTPM TA is
> > > failing to load, since the eMMC RPMB isn't provisioned.
> > 
> > Thanks for looking into that, and I am glad you can reproduce the issue.
> > 
> > > Even though these logs don't affect functionality, you can revert this
> > > patch to avoid confusion. I am checking if there's a cleaner way to
> > > handle this.
> > 
> > I am using mainline U-Boot, if this needs to be reverted, it must be
> > reverted here. Given the release timeline, and the fact that this is not
> > breaking the functionality I am fine waiting a little bit to see if it
> > is possible to fix it, we have some time before the v2026.07 release.
> 
> And for the release I would like to make sure someone has a clear path
> on what changes are needed, if any in the end, on mainline U-Boot by
> rc4, which is June 8th. We have the last one on June 22nd but I'd rather
> not have to revert then unless things are just unresolved. Thanks!

Shiva: what's the plan? As of now the issue is still there.

Francesco

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Shiva Tripathi]

On 6/10/26 11:21, Francesco Dolcini wrote:
> Hello Shiva,
> 
> On Fri, May 22, 2026 at 11:36:37AM -0600, Tom Rini wrote:
>> On Fri, May 22, 2026 at 06:20:48PM +0200, Francesco Dolcini wrote:
>>> On Fri, May 22, 2026 at 07:49:27PM +0530, Shiva Tripathi wrote:
>>>> On 5/22/26 11:45, Francesco Dolcini wrote:
>>>>> On Wed, May 13, 2026 at 06:36:40PM +0530, Shiva Tripathi wrote:
>>>>> On Wed, May 13, 2026 at 08:49:31AM -0500, Andrew Davis wrote:
>>>>>> This makes me think we are at the stage in boot where EFI variables
>>>>>> are trying to be persisted to some media, and when trying to use
>>>>>> the fTPM for this it fails (as would be expected without RPMB).
>>>>>> So this should be harmless, but why there is such a large error
>>>>>> printout we need to investigate and try to make it less verbose.
>>>>>
>>>>> Any chance TI can help on this?
>>>> Yes, I am looking into it. The logs are showing up as OPTEE's fTPM TA is
>>>> failing to load, since the eMMC RPMB isn't provisioned.
>>>
>>> Thanks for looking into that, and I am glad you can reproduce the issue.
>>>
>>>> Even though these logs don't affect functionality, you can revert this
>>>> patch to avoid confusion. I am checking if there's a cleaner way to
>>>> handle this.
>>>
>>> I am using mainline U-Boot, if this needs to be reverted, it must be
>>> reverted here. Given the release timeline, and the fact that this is not
>>> breaking the functionality I am fine waiting a little bit to see if it
>>> is possible to fix it, we have some time before the v2026.07 release.
>>
>> And for the release I would like to make sure someone has a clear path
>> on what changes are needed, if any in the end, on mainline U-Boot by
>> rc4, which is June 8th. We have the last one on June 22nd but I'd rather
>> not have to revert then unless things are just unresolved. Thanks!
> 
> Shiva: what's the plan? As of now the issue is still there.
> 
> Francesco
> 

Hi Francesco,

I have sent a fix patch to optee_ftpm[1]. With this patch, the fTPM TA
gracefully handles RPMB unavailability without panicking, eliminating
the memory dumps.

For now, there are two interim approaches:
1. Revert the u-boot patch that enabled k3 fTPM configs
2. Apply the optee-ftpm patch in meta-ti recipes

I am waiting review from optee-ftpm maintainers. If it's accepted, we
will upgrade the optee-ftpm in meta-ti to the fixed version.

[1]: https://github.com/OP-TEE/optee_ftpm/pull/27

Thanks,
Shiva

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Francesco Dolcini]

On Wed, Jun 10, 2026 at 06:57:54PM +0530, Shiva Tripathi wrote:
> 
> 
> On 6/10/26 11:21, Francesco Dolcini wrote:
> > Hello Shiva,
> > 
> > On Fri, May 22, 2026 at 11:36:37AM -0600, Tom Rini wrote:
> >> On Fri, May 22, 2026 at 06:20:48PM +0200, Francesco Dolcini wrote:
> >>> On Fri, May 22, 2026 at 07:49:27PM +0530, Shiva Tripathi wrote:
> >>>> On 5/22/26 11:45, Francesco Dolcini wrote:
> >>>>> On Wed, May 13, 2026 at 06:36:40PM +0530, Shiva Tripathi wrote:
> >>>>> On Wed, May 13, 2026 at 08:49:31AM -0500, Andrew Davis wrote:
> >>>>>> This makes me think we are at the stage in boot where EFI variables
> >>>>>> are trying to be persisted to some media, and when trying to use
> >>>>>> the fTPM for this it fails (as would be expected without RPMB).
> >>>>>> So this should be harmless, but why there is such a large error
> >>>>>> printout we need to investigate and try to make it less verbose.
> >>>>>
> >>>>> Any chance TI can help on this?
> >>>> Yes, I am looking into it. The logs are showing up as OPTEE's fTPM TA is
> >>>> failing to load, since the eMMC RPMB isn't provisioned.
> >>>
> >>> Thanks for looking into that, and I am glad you can reproduce the issue.
> >>>
> >>>> Even though these logs don't affect functionality, you can revert this
> >>>> patch to avoid confusion. I am checking if there's a cleaner way to
> >>>> handle this.
> >>>
> >>> I am using mainline U-Boot, if this needs to be reverted, it must be
> >>> reverted here. Given the release timeline, and the fact that this is not
> >>> breaking the functionality I am fine waiting a little bit to see if it
> >>> is possible to fix it, we have some time before the v2026.07 release.
> >>
> >> And for the release I would like to make sure someone has a clear path
> >> on what changes are needed, if any in the end, on mainline U-Boot by
> >> rc4, which is June 8th. We have the last one on June 22nd but I'd rather
> >> not have to revert then unless things are just unresolved. Thanks!
> > 
> > Shiva: what's the plan? As of now the issue is still there.
> > 
> I have sent a fix patch to optee_ftpm[1]. With this patch, the fTPM TA
> gracefully handles RPMB unavailability without panicking, eliminating
> the memory dumps.
> 
> For now, there are two interim approaches:
> 1. Revert the u-boot patch that enabled k3 fTPM configs
> 2. Apply the optee-ftpm patch in meta-ti recipes
> 
> I am waiting review from optee-ftpm maintainers. If it's accepted, we
> will upgrade the optee-ftpm in meta-ti to the fixed version.

Given the current status I would not revert the patch in U-Boot.

Once the patch is accepted in optee the issue will naturally solve on its own,
and in the short term you can have the patch in meta-ti.

Francesco

Re: [PATCH v2] arm: k3: Kconfig: Enable fTPM and RPMB support

[Tom Rini]

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

On Wed, Jun 10, 2026 at 03:53:16PM +0200, Francesco Dolcini wrote:
> On Wed, Jun 10, 2026 at 06:57:54PM +0530, Shiva Tripathi wrote:
> > 
> > 
> > On 6/10/26 11:21, Francesco Dolcini wrote:
> > > Hello Shiva,
> > > 
> > > On Fri, May 22, 2026 at 11:36:37AM -0600, Tom Rini wrote:
> > >> On Fri, May 22, 2026 at 06:20:48PM +0200, Francesco Dolcini wrote:
> > >>> On Fri, May 22, 2026 at 07:49:27PM +0530, Shiva Tripathi wrote:
> > >>>> On 5/22/26 11:45, Francesco Dolcini wrote:
> > >>>>> On Wed, May 13, 2026 at 06:36:40PM +0530, Shiva Tripathi wrote:
> > >>>>> On Wed, May 13, 2026 at 08:49:31AM -0500, Andrew Davis wrote:
> > >>>>>> This makes me think we are at the stage in boot where EFI variables
> > >>>>>> are trying to be persisted to some media, and when trying to use
> > >>>>>> the fTPM for this it fails (as would be expected without RPMB).
> > >>>>>> So this should be harmless, but why there is such a large error
> > >>>>>> printout we need to investigate and try to make it less verbose.
> > >>>>>
> > >>>>> Any chance TI can help on this?
> > >>>> Yes, I am looking into it. The logs are showing up as OPTEE's fTPM TA is
> > >>>> failing to load, since the eMMC RPMB isn't provisioned.
> > >>>
> > >>> Thanks for looking into that, and I am glad you can reproduce the issue.
> > >>>
> > >>>> Even though these logs don't affect functionality, you can revert this
> > >>>> patch to avoid confusion. I am checking if there's a cleaner way to
> > >>>> handle this.
> > >>>
> > >>> I am using mainline U-Boot, if this needs to be reverted, it must be
> > >>> reverted here. Given the release timeline, and the fact that this is not
> > >>> breaking the functionality I am fine waiting a little bit to see if it
> > >>> is possible to fix it, we have some time before the v2026.07 release.
> > >>
> > >> And for the release I would like to make sure someone has a clear path
> > >> on what changes are needed, if any in the end, on mainline U-Boot by
> > >> rc4, which is June 8th. We have the last one on June 22nd but I'd rather
> > >> not have to revert then unless things are just unresolved. Thanks!
> > > 
> > > Shiva: what's the plan? As of now the issue is still there.
> > > 
> > I have sent a fix patch to optee_ftpm[1]. With this patch, the fTPM TA
> > gracefully handles RPMB unavailability without panicking, eliminating
> > the memory dumps.
> > 
> > For now, there are two interim approaches:
> > 1. Revert the u-boot patch that enabled k3 fTPM configs
> > 2. Apply the optee-ftpm patch in meta-ti recipes
> > 
> > I am waiting review from optee-ftpm maintainers. If it's accepted, we
> > will upgrade the optee-ftpm in meta-ti to the fixed version.
> 
> Given the current status I would not revert the patch in U-Boot.
> 
> Once the patch is accepted in optee the issue will naturally solve on its own,
> and in the short term you can have the patch in meta-ti.

Thanks everyone, we have a plan here then.

-- 
Tom

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