Hello,
We're kicking off the release process for TF-Mv2.2.0, starting with the TF-Mv2.2.0-RC1 tag.
As part of this release phase, we're also updating the previous version to TF-Mv2.1.2, which includes critical bug fixes and support for new platforms. New TF-Mv2.1.2-RC1 tag will follow shortly.
After completing initial testing on the reference platform and addressing all identified issues, we'll reach out to platform owners to verify TF-M on platforms not available in LAVA. Please note, the verification might be requested on a different tag by that time.
Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>.
Thanks,
Anton
Hi Team,
I am setting the TFM_SPM_LOG_LEVEL to DEBUG in platform config.cmake. Yet it is getting overwritten by TFM_SPM_LOG_LEVEL_SILENCE. Is there any other place I need to look for? Thanks.
Michael KH
# LOG LEVEL
set(TFM_SPM_LOG_LEVEL TFM_SPM_LOG_LEVEL_DEBUG CACHE STRING "Set default SPM log level as DEBUG level")
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.
