Hello,
I am thrilled to announce the support of new Clan/LLVM toolchain, freely available here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm. This extends a suite of powerful tools designed to enhance your development experience and boost productivity.
Key Features:
* Offers Clang frontend
* Available for Linux, Windows and macOS
* Builds TF-M binaries for all Arm targets
* Secure side built without libc and picolib libraries, while both are available to Bootloader and Non-Secure side
Important notes:
* Floating point support is not verified
* MVE is not supported yet
* This has been verified with version v18.1.3 of the toolchain.
We're excited for you to try out the new toolchain support and look forward to your feedback. The use of the toolchain_CLANG.cmake is the same as all other toolchains.
I plan to present the new toolchain and compare it with the existing tools in one of the upcoming TF-M forums. Meanwhile I encourage the platform owners to include the new toolchain support using arm platforms as a reference. The relevant changes are in this chain:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34351
There is ongoing discussion on the best name for the toolchain to avoid possible confusion. Should it be Clang as now, LLVM, or even LLVMClang? Please share your opinion.
Thanks, and best regards,
Anton.
Hello,
The next Technical Forum is planned on Thursday, Sep 12 at 7:00-8:00 UTC (East time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
I notice that TFM_VERSION_MANUAL gets set to "2.2.1" in both release/2.2.x and in main. Granted, the hash gets appended to make TFM_VERSION, and there's some reading of git tags involved that can override TFM_VERSION_MANUAL, but it still feels odd that both identify as the "same" version.
Perhaps main should be flagged as being the "next" version as soon as the previous version branch has been created? So we would tag main as v2.3.pre or something. Either that or something that identifies as *not* being a regular release.
Chris
Hi all,
I am trying to build TFM with IAR with TFM_FIH_PROFILE=HIGH and I am facing the issue with the FIH labels.
I see following errors:
[ 98%] Linking C executable ../bin/tfm_s.axf
Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_END_46_1"; in
"main.o(libtfm_spm.a)", and "tfm_hal_platform.o(libtfm_spm.a)"
Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_START_46_1"; in
"main.o(libtfm_spm.a)", and "tfm_hal_platform.o(libtfm_spm.a)"
Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_END_35_0"; in
"tfm_hal_platform.o(libtfm_spm.a)", and
"platform_svc_handler.o(libtfm_spm.a)"
Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_START_35_0"; in
"tfm_hal_platform.o(libtfm_spm.a)", and
"platform_svc_handler.o(libtfm_spm.a)"
I did some investigations and I believe I know the root cause:
Looks like __COUNTER__ for IAR is unique only for a translation unit (.c file) - thus when 2 files have FIH call in same line with the same number of FIH calls before - it creates a label which overlaps with labels in other file.
For example tfm_hal_platform.c in our case has first FIH CALL in line 46 (which creates label FIH_LABEL_FIH_CALL_END_46_1) but main.c in our code also has first FIH CALL in line 46 which also results in FIH_LABEL_FIH_CALL_END_46_1 label.
The question is - how can we solve this issue? Any ideas I can try?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hello,
We're preparing two new minor releases: v2.1.4 and v2.2.2. Both releases update TF-M to include MbedTLS v3.6.5, which brings several vulnerability fixes and fix of the bug reported in v2.2.1.
Following a successful dry-run test we'll publish Release Candidate (RC1) followed by the final release.
As these are minor updates, we don't expect platform-specific testing, assuming the changes are platform-independent and that our CI coverage will be sufficient. However, please feel free to reach out if you have any
concerns or foresee any platform impact.
Thank you and best regards,
Anton
All,
Please be aware that today we have published our AI policy with Guidance on
AI-assisted contributions.
See the full details here: https://www.trustedfirmware.org/aipolicy/
Should you have any questions feel free to raise them.
Thanks,
Shaun
Community Manager