Hi,
I'm seeing this warning when running cmake from a conan pkg: `/home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/bin/cmake -S . -B build -DTFM_PLATFORM=arm/mps2/an521`. Does anyone know how to fix it? I see the language is set by `project("Trusted Firmware M" VERSION ${TFM_VERSION} LANGUAGES C CXX ASM)`.
Per-partition files done:
CMake Warning (dev) at /home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/share/cmake-3.21/Modules/GNUInstallDirs.cmake:236 (message):
Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
target architecture is known. Please enable at least one language before
including GNUInstallDirs.
Call Stack (most recent call first):
build/lib/ext/mbedcrypto-src/CMakeLists.txt:42 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
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
Hi TFM Developer Forum Organizer,
I'm currently integrating the CryptoCell3xx Runtime code for ECDSA hardware acceleration and have a question regarding the implementation.
I'm not entirely sure if this is the right list to post to - perhaps it belongs in mbed-tls or psa-crypto instead - so please forgive me and suggest the right list if this is not the appropriate forum.
I noticed that the repository contains two variants of pka_ec_wrst_smul: one under no_scap and another under scap, located in
/lib/ext/cryptocell-312-runtime/codesafe/src/crypto_api/pki/ec_wrst/.
From the filenames and comments, it appears that scap.c is the Side-Channel Attack (SCA)-resistant version, and would therefore be preferred for end-user products where stronger security is prioritized over performance.
However, in the current version of pka_ec_wrst_smul_scap.c from the main open-source branch, I found a couple of apparent typos/bugs that cause compilation errors:
Line 239: should probably be
PkaAddJcbJcb2Mdf(EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS, EC_SIGN_REG_TS,
EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS,
EC_SIGN_REG_X2, EC_SIGN_REG_T2, EC_SIGN_REG_Z2);
(currently missing the leading "P".)
Lines 389 and 391: the output parameters are declared as const, which seems incorrect. For example:
CCError_t PkaEcWrstScalarMult(const CCEcpkiDomain_t *pDomain, /*!< [in] Pointer to EC domain. */
const uint32_t *scalar, /*!< [in] Pointer to the scalar buffer. */
uint32_t scalSizeInWords, /*!< [in] Size of the scalar in 32-bit words. */
uint32_t *inPointX, /*!< [in] Pointer to input point X coordinate. */
const uint32_t *inPointY, /*!< [in] Pointer to input point Y coordinate. */
const uint32_t *outPointX, /*!< [out] Pointer to output point X coordinate. */
The const qualifier on the output parameters seems unintended and rather for inPointX.
Because of these issues, it seems this file might not have been recently reviewed or tested.
So, my questions are:
1. Is the CryptoCell312 Runtime actively maintained and tested in a specific branch where these typos/bugs are already fixed? If so, could you please share which branch that is?
2. If not, it seems that CMake currently only selects the no_scap variant. Does this mean the scap variant is not actively maintained or tested, and therefore not recommended for production use due to higher risk?
Thanks in advance for your help and clarification.
Best regards,
Masaki Sato
(P.S. I have sent this message from proofpoint TFM list by "Start a new thread" button. However, I don't see a record on the "posting activity" under my account profile nor active discussion list. Pardon me, but I'm a newbie to this forum, so please forgive me to send the same message by email.
________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Hello,
I would like to inform the community that the TF-M v2.3.0 release has been postponed to April 2026 in order to incorporate the forthcoming PSA-Crypto LTS release, anticipated in Q1 2026.
This decision is intended to ensure improved long-term alignment between two projects.
I apologize for any inconvenience the delay may cause and appreciate your understanding.
Best regards,
Anton
Hello,
I have already poted this. but, i can't find my thread.
I’m trying to enable the PLATFORM_PSA_ADAC_SECURE_DEBUG.
1) Platform (arm neoverse RDV3R1 (RSE))
repo init -u https://git.gitlab.arm.com/infra-solutions/reference-design/infra-refdesign… -m <manifest-file-name> -b refs/tags/<RELEASE_TAG> --depth=1
repo sync -c -j $(nproc) --fetch-submodules --force-sync --no-clone-bundle
manifest file: pinned-rdv3r1.xml
release tag: refs/tags/RD-INFRA-2025.07.03
2) Enabling the ADAC Parameter
\\wsl.localhost\Ubuntu-22.04\home\phillip\251020_ws\tf-m\config\config_base.cmake
I changed the parameter from FALSE to TRUE.
set(PLATFORM_PSA_ADAC_SECURE_DEBUG TRUE CACHE BOOL "Whether to use psa-adac secure debug.")
3) Build Command
phillip@phillip3420:~/251020_ws$ ./build-scripts/build-tf-m.sh -p rdv3r1 -f uefi build
4) Error Message
===============================================================================
-- Populating libpsaadac
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to: /home/phillip/251020_ws/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-subbuild
[1/9] Creating directories for 'libpsaadac-populate'
[1/9] Performing download step (git clone) for 'libpsaadac-populate'
Cloning into 'libpsaadac-src'...
HEAD is now at 819a254 Platform: Fix prototype for crypto_hw_apply_debug_permissions
[2/9] Performing update step for 'libpsaadac-populate'
-- Already at requested ref: 819a254af6fb5eefdcef194ec85d2c7627451351
[3/9] No patch step for 'libpsaadac-populate'
[5/9] No configure step for 'libpsaadac-populate'
[6/9] No build step for 'libpsaadac-populate'
[7/9] No install step for 'libpsaadac-populate'
[8/9] No test step for 'libpsaadac-populate'
[9/9] Completed 'libpsaadac-populate'
CMake Error at cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/target/trusted-firmware-m/config.cmake:12 (Message):
Platform arm/rse/neoverse_rd/rdv3r1 not supported.
Call Stack (most recent call first):
cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/CMakeLists.txt:34 (include)
-- Configuring incomplete, errors occurred!
+++ handle_error
++++ caller 0
+++ local 'callinfo=93 do_build ./build-scripts/build-tf-m.sh'
+++ local script=./build-scripts/build-tf-m.sh
+++ local lineno=93
+++ local 'func=93 do_build'
+++ func=do_build
+++ echo
+++ echo -en '\e[1m\e[31mBuild failed: error while running do_build at line '
Build failed: error while running do_build at line +++ echo -en '93 in ./build-scripts/build-tf-m.sh for rdv3r1[rdv3r1]'
93 in ./build-scripts/build-tf-m.sh for rdv3r1[rdv3r1]+++ echo -e '[uefi].\e[0m'
[uefi].
+++ echo
+++ exit 1
===============================================================================
5) My opinion
TFM_PLATFORM_PATH is "/home/phillip/251020_ws/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/target/trusted-firmware-m/platform/arm/rse/neoverse_rd/rdv3r1" in my workpace.
But, in the "/home/phillip/251020_ws/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/target/trusted-firmware-m/platform/arm/rse/" directory, there are only two folders, "common" and "tc".
PLATFORM_PSA_ADAC_VERSION should be changed?
(The RD-INFRA-2025.07.03 source code use PLATFORM_PSA_ADAC_VERSION as 819a254)
I would be grateful for any advice or pointers from anyone familiar with this.
Thanks
Best Regards
Phillip
