Hello,
TF-M release v2.2.0 is unfortunately delayed for about a month.
The new tentative start date is the end of February with a goal to complete the release at the middle of March.
The main reasons of the delay are:
* Delays in PSA certification of RPi2350 platform
* An opportunity to accommodate of Mbed TLS v3.6.3 planned on February
* Limited availability of TF-M maintainers
Thanks, and sorry for the possible inconveniences caused be this delay,
Anton
Hello,
Following the Tech Forum yesterday I am repeating the questions asked at the time.
Please share your opinions
* Do we need C++ support on S side?
* CLANG/LLVM toolchain name
* toolchain_CLANG.cmake vs toolchain_LLVM.cmake
* Can we drop the support of -march -mtune options in favor of -mcpu only?
* Can we limit supported toolchains to the earliest version with m55 support?
In other words: is there anyone who must use toolchains earlier than in the table?
Toolchain
Cortex-M55 support since
Release Date
ArmClang
V6.14
March 2020
GNU Arm Embedded Toolchain
V10.
December 2020
LLVM Embedded Toolchain for Arm
V11.0.0
September 2020
IAR Embedded Workbench
V8.50
November 2020
Thanks,
Anton
Hi Everyone,
Following today's announcement in the Tech Forum, I am pleased to share that the TF-M maintainer team is expanding.
We warmly welcome back David Hu (davidhuzj(a)gmail.com<mailto:davidhuzj@gmail.com>) to the maintainer team!
David has been a key contributor and TF-M maintainer for several years. After a brief pause, he has kindly agreed to resume his role, overseeing TF-M changes once again.
Thank you, David, for your continued commitment and contributions to the project!
All the best,
Anton
Hi,
In TF-M v2.0, Initial_attestation.h says:
* The initial attestation token is planned to be aligned with future version of
* Entity Attestation Token format:
* https://tools.ietf.org/html/draft-mandyam-eat-01
But that spec is expired and superceded with the following.
Is the implementation aligned with the following spec? If so, what version of this spec is actually supported?
https://datatracker.ietf.org/doc/draft-ietf-rats-eat/02/
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hello Everyone,
We are currently working on TF-M for the firmware of our Cortex-M55 based core, part of a bigger platform
including a cortex-A based application processor, a bit like the corstone1000.
We use the RAM_LOAD boot mode of TF-M/MCUBoot and we want to implement an upgrade strategy based on
2 banks, and a switch to decide which bank to boot from. I have a few questions regarding some design choices.
I hope someone can answer them. Please correct me if some of my assumptions are wrong.
*
For the generic Firmware Upgrade partition, are there plans to support the RAM_LOAD mode ? Do you have
suggestions about what is missing or how it should be done ?
*
Currently, MCUBoot in RAM_LOAD mode only supports booting the slot with the highest version.
Do you think it is realistic to try and integrate another boot mode in MCUBoot that matches our needs ?
I'm asking this because I noticed that the corstone1000 platform has been developed working around
this limitation by changing the flash_map at platform initialization in order to abstract the problem from
MCUBoot completely.
Thank you and all the best,
Julien
Hi all,
I would like to know if the PSA ITS is protected in case tearing cases (power failure) happening during write/erase in the internal flash, using `psa_its_set()` or `psa_its_remove()`, please.
Thanks a lot.
Best regards,
Abel.
Could you please help with my issue? Thank you!
From: Michael Ji
Sent: Friday, February 14, 2025 4:15 PM
To: Raef.Coles(a)arm.com; Anton.Komlev(a)arm.com
Subject: TFM build error
Hi Raef and Anton:
I am following the steps in this webpage to build tfm on my Windows laptop:
https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht…
All my steps are successful till I ran this command below and got error (FYI - I am using the platform arm/mps2/an521 and GNU ARM compiler):
[cid:image001.png@01DB7EFB.878CE310]
Could you share your insight on how to resolve this? Thank you very much!
Best,
Michael
Hi all,
We would like to remove PSA_IOT_PROFILE_1<https://review.trustedfirmware.org/q/topic:%22remove-psa_iot_1%22> which is an early attestation token profile (used for the original
implementation of the PSA Initial Attestation service) and has been superseded by profile PSA 2.0.0
(https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#nam…).
The above patches include:
* Change the default token profile configuration to: ATTEST_TOKEN_PROFILE_PSA_2_0_0,
* Remove support for PSA_IOT_PROFILE_1.
Please let us know if you have any concerns, suggestions.
Best regards,
David Vincze
