- TF-M - lists.trustedfirmware.org

by Andrej Butok

Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

6 years, 2 months

1
0
0 0

Experimental IAR support

by Thomas Törnblom

Thank you for merging my cleanup in T398. I have a set of IAR build related files that I would like to push, both new and modified cmake files and startup and linker scripts for the Musca A board. There is still some work needed on the linker scripts to get everything fully functional but I can load and debug the secure and non secure images, and the non-secure image will start and execute the idle thread. I have not tested mcuboot although it appears to build properly. We have chip vendors that are eagerly awaiting our port and I would like to push this as "experimental". Would this be OK? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 3 months

1
0
0 0

Re: [TF-M] Feature request

by Gyorgy Szing

Hi Andrej, We shall avoid adding IDE specific workarounds to the code. I see many possible better solutions to this problem: 1. All IDEs are capable to "ignore" files present in the working copy but not part of the build. You could try this feature. 2. Irrelevant files can be deleted from the workspace by using a script. 3. Using a different generator of CMake could allow to generate a project format which your IDE can import. (See https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html) 4. Using CMAKE_EXPORT_COMPILE_CMMANDS will make CMake to generate a json file listing all C files part of the build with the build command needed to compile them. It could be relative simple to write a Python script to create an IDE project or to update an existing one with build settings. (See: https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.…) 5. Long term a generators could be up streamed to CMake to add Support for you IDE. Please contact the IDE vendor with this request. 6. The IDE could be updated to co-operate with "cmake server" to allow integration with cmake based build systems. Again please contact the IDE vendor with this request. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 18 June 2019 08:23 To: Miklos Balint <Miklos.Balint(a)arm.com>; Thomas Törnblom <thomas.tornblom(a)iar.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Feature request Hi Miklos, One more feature request: 3) Using separate files in TFM without #ifdef is causing issues for IDE projects, and requires creation of separate projects/targets (with different file set) per each feature combination. We are using IDEs (IAR, MCUx, Keil), so we have to add missing #ifdef to the original TFM source code. Please use #if/#ifdef in TFM, everywhere were it is needed. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M Sent: Monday, June 17, 2019 5:31 PM To: Thomas Törnblom <thomas.tornblom(a)iar.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Feature request Hi Thomas, I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters. For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s. Let me know your thoughts on this approach Thanks and kindest regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Feature request While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: https://eur01.safelinks.protection.outlook.com/?url=www.iar.com&data=02… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iar.co…> Twitter: https://eur01.safelinks.protection.outlook.com/?url=www.twitter.com%2Fiarsy… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitte…> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
2
0 0

[PLEASE READ] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, Configurations has been moved into 'configs' directory. Please: - Update your build commands to build with configurations under 'configs' directory, check updated document: docs/user_guides/tfm_build_instruction.rst - If you want to push new configurations, please put new configurations under 'configs' directory. The dummy configurations under root directory will be removed soon so please DO UPDATE YOUR BUILD COMMAND! Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, June 18, 2019 10:03 AM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Move configuration files into specified directory > > Hi, > The patch has been pushed for a while and is going to be merged in one week, > please help to review it if you planned but still not have a look: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > After this patch get merged, all new configurations created in root directory will > be rejected. Please create new configuration files under ./configs directory. > The existing fake configuration files under root directory will be removed after > CI setting changed. > > Thanks. > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, June 11, 2019 1:40 PM > > To: TF-M(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [TF-M] [RFC] Move configuration files into specified > > directory > > > > Hi, > > Since the number of configuration files is increasing, let’s move the > > configuration files (ConfigXXXX.cmake) into specified directory. > > This would reduces the files under root directory and makes the > > structure more clearer. > > > > I have created the issue and patch for it: > > https://developer.trustedfirmware.org/T394 > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > IMPORTANT NOTES: > > To be compatible with the existing building configurations, the > > existing configuration files have been forwarded into the corresponded > > configuration file under ./configs. Which means there are two set of > > configuration files under sources tree at current – but this will > > change soon. There is a warning while you are building with root > > configurations files: “Please use the configs available in the ./config sub- > directory.” > > > > So please: > > > > - If you are planning to create new configuration, create it under > > ./configs instead of root directory > > - The reference of configuration files under root directory will be > > removed soon, please change your build system setting to reference the > > configuration files put under ./configs > > > > Any feedbacks please reply this mail or put comments under the issue, > > thanks > > 😉 > > > > -Ken > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

TF-M CI Blog

by Shebu Varghese Kuriakose

Hi All, Not sure if everyone knows that there is an initial deployment of TF-M CI (Continuous Integration) system. It tests every patch that gets submitted in TF-M gerrit. Read about the CI system and find the relevant links in this blog - https://www.trustedfirmware.org/blog/trusted-firmware-open-ci-update/ Thanks, Shebu

6 years, 3 months

1
0
0 0

Please help review the patches of architecture abstraction in TF-M

by David Hu (Arm Technology China)

Hi all, Could you please review the following patches to abstract architecture specific code? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157/<https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157> https://review.trustedfirmware.org/c/trusted-firmware-m/+/1158 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1390/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1251/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1252/ The above patches abstract architecture specific code to decouple TF-M core to specific architecture details. It can help enable TF-M running on diverse Arm M-profile architectures. Other Arm M-profile architecture implementation will be added later. Suggestions are welcome. Thank you. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

Align manifest to PSA FF

by Edison Ai (Arm Technology China)

Hi, I had create patches related to manifest. There are two topics for it: * Align manifest to PSA FF: https://review.trustedfirmware.org/#/q/topic:Align_manifest_to_PSA_FF+(stat… * Generate SID and signal header files according to manifest: https://review.trustedfirmware.org/#/q/topic:generate_SID_signal_header_fil… I had added some reviewers to help to review them. Please feel free to give any comment even you are not in reviewer list(Sorry maybe skip someone by mistake). There are some important patches I think and please pay your attention to them: * Remove "tfm_symbol" from manifest: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1243/ * Change the value of SID: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1246/ * Rename the manifest file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1247/ * Generate manifest file name header file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ * Assign signal value to SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ * Generate service ID header file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1353/ Thanks, Edison

6 years, 3 months

1
0
0 0

Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Christian Daudt

If the objective of assigning it to TEST_PASSED before the test is that it becomes the default final answer (i.e. unless it gets reassigned to TEST_FAILED the final result remains this assignment) then it should absolutely be set to TEST_PASSED at startup. thanks, Christian. ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 19, 2019 6:00 AM To: Thomas Törnblom; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain Hi Thomas, Personally I would avoid the type cast too. But to turn your dilemma into a trilemma, there is a third possible solution too -- you could remove the `{0}` initialiser from the initialiser list. Then the last member of the struct will be initialised implicitly the same way as a static object (i.e. to zero). Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 19 June 2019 13:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain I get lots of warnings about type mismatch for enums. I have fixed some of them where it seems natural, but I need to discuss the approach for fixing these: --- [ 37%] Building C object test/CMakeFiles/tfm_secure_tests.dir/suites/invert/secure/invert_s_interface_testsuite.o "Invert with valid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",20 Warning[Pe188]: enumerated type mixed with another type "Invert with invalid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",22 Warning[Pe188]: enumerated type mixed with another type --- The issue is that the "{0}" is the initializer for the enum test_status_t "val" below: --- enum test_status_t { TEST_PASSED = 0, /*!< Test has passed */ TEST_FAILED = 1, /*!< Test has failed */ }; struct test_result_t { enum test_status_t val; /*!< Test result \ref test_status_t */ const char *info_msg; /*!< Information message to show in case of * failure */ const char *filename; /*!< Filename where the failure has occured */ uint32_t line; /*!< Line where the failure has occured */ }; --- I can eliminate the warnings by either casting the "0" to enum test_status_t, or replace the 0 with "TEST_PASSED". Personally I would prefer to avoid having a type cast, but initializing the value to "TEST_PASSED" may seem to indicate that the test has passed even before having been run. Comments? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> <http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 3 months

1
0
0 0

Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Jamie Fox

Hi Thomas, Personally I would avoid the type cast too. But to turn your dilemma into a trilemma, there is a third possible solution too -- you could remove the `{0}` initialiser from the initialiser list. Then the last member of the struct will be initialised implicitly the same way as a static object (i.e. to zero). Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 19 June 2019 13:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain I get lots of warnings about type mismatch for enums. I have fixed some of them where it seems natural, but I need to discuss the approach for fixing these: --- [ 37%] Building C object test/CMakeFiles/tfm_secure_tests.dir/suites/invert/secure/invert_s_interface_testsuite.o "Invert with valid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",20 Warning[Pe188]: enumerated type mixed with another type "Invert with invalid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",22 Warning[Pe188]: enumerated type mixed with another type --- The issue is that the "{0}" is the initializer for the enum test_status_t "val" below: --- enum test_status_t { TEST_PASSED = 0, /*!< Test has passed */ TEST_FAILED = 1, /*!< Test has failed */ }; struct test_result_t { enum test_status_t val; /*!< Test result \ref test_status_t */ const char *info_msg; /*!< Information message to show in case of * failure */ const char *filename; /*!< Filename where the failure has occured */ uint32_t line; /*!< Line where the failure has occured */ }; --- I can eliminate the warnings by either casting the "0" to enum test_status_t, or replace the 0 with "TEST_PASSED". Personally I would prefer to avoid having a type cast, but initializing the value to "TEST_PASSED" may seem to indicate that the test has passed even before having been run. Comments? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Thomas Törnblom

I get lots of warnings about type mismatch for enums. I have fixed some of them where it seems natural, but I need to discuss the approach for fixing these: --- [ 37%] Building C object test/CMakeFiles/tfm_secure_tests.dir/suites/invert/secure/invert_s_interface_testsuite.o "Invert with valid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",20 Warning[Pe188]: enumerated type mixed with another type "Invert with invalid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",22 Warning[Pe188]: enumerated type mixed with another type --- The issue is that the "{0}" is the initializer for the enum test_status_t "val" below: --- enum test_status_t { TEST_PASSED = 0, /*!< Test has passed */ TEST_FAILED = 1, /*!< Test has failed */ }; struct test_result_t { enum test_status_t val; /*!< Test result \ref test_status_t */ const char *info_msg; /*!< Information message to show in case of * failure */ const char *filename; /*!< Filename where the failure has occured */ uint32_t line; /*!< Line where the failure has occured */ }; --- I can eliminate the warnings by either casting the "0" to enum test_status_t, or replace the 0 with "TEST_PASSED". Personally I would prefer to avoid having a type cast, but initializing the value to "TEST_PASSED" may seem to indicate that the test has passed even before having been run. Comments? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M