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
signature.asc
Description: PGP signature
