Dear TF-M maintainers,
I am currently developing an application using the STM board b_u585i-iot02a (target: b_u585i_iot02a/stm32u585xx/ns). As mentioned in this issue<https://github.com/zephyrproject-rtos/zephyr/issues/92670>, , the provisioning data is currently statically programmed.
Instead of changing this hardcoded data directly, I created a jinja2 template and a generation script based on the original file. This follows the same pattern used in trusted-firmware-m/platform/ext/common/provisioning_bundle/CMakeLists.txt.
This approach works well locally, but I would like some feedback to ensure it meets the project's standards before opening a PR.
First, what are your thoughts on this method? Should this feature be made available for all STM boards, or is it better to restrict it to the b_u585i-iot02a for now?
Additionally, I am currently passing variables such as huk, iak, and boot_seed from my local project's CMakeLists.txt. If they are not provided, the script simply falls back to the default hardcoded values.
Thank you in advance for your time and guidance.
Best regards,
———
Benjamin Grolleau
benjamin.grolleau(a)outlook.com
Hello,
TF-M CI is currently failing in most builds due to a documentation issue. The documentation was recently upgraded and now requires additional Python components in Docker image.
We are aware of the issue and are working on fixes.
Best regards,
Anton
Hi all,
Currently TFM specifies -fshort-wchar and -fshort-enums
There previously was a discussion about this in https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.…
The decision was to remove these flags – which was done in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6186
But then fix was reverted in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6349 because:
Removing the -fshort-wchar flag will cause link error with
RTX library while using armclang and debug mode.
Now we faced same issue when linking some of our prebuilt crypto libraries.
Since RTX libraries ware prebuilt by TFM maintainers (prebuilt RTX libs are not part of CMSIS RTX) – I believe it is better to rebuild them without -fshort-wchar and -fshort-enums and remove these flags in TFM.
Does TFM team still have a possibility to rebuild these RTX libs? Does this change make sense to TFM community?
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi Everyone,
I am glad to announce the new maintainer of TF-M project:
* Nicola Mazzucato aka nicola-mazzucato-arm <nicola.mazzucato(a)arm.com<mailto:nicola.mazzucato@arm.com>>
Thank you, Nicola, for agreeing to maintain the project.
All the best,
Anton
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.
Hi All,
I se that http://ci.trustedfirmware.org/job/tf-m-static-checks/3233/consoleFull has FAILURE in the log, but the job passed:
Include order test: FAILURE (warning)
Additionally there are some other errors – a suspect that they may lead to this weird behavior:
22:23:00 + ./tf-m-ci-scripts/jenkins/verify.py --category static --value 1 --verify-name static-checks --user ****
22:23:01 Error posting to verify-status: 404
22:23:01 Not found: verify-status~verifications
22:23:01
22:23:01 Could not check if verify-status plugin is installed
Is this expected?
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi,
I recently started seeing a build error for PSE84. "git bisect" tells me that it was introduced in c2fc818e.
The error is from cmake, complaining about a circular dependency. The error message itself is extremely long, so I've attached it as a separate file.
Chris