- TF-M - lists.trustedfirmware.org

Re: [TF-M] gcc compiler requirement documentation

by Shawn Shan

Hi Chris, Thanks for point out this. Here is the fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7226 Regards, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Thursday, November 26, 2020 2:55 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] gcc compiler requirement documentation Looking at docs/getting_started//tfm_sw_requirement.rst it says that the version requirement for gcc is "GNU Arm compiler v7.3.1+". then it describes where to get that toolchain, but in that section the two versions it suggests are "GNU Arm Embedded Toolchain: 6-2017-q1-update" and "GNU Arm Embedded Toolchain: 7-2018-q2-update". The former is gcc version 6.3.1, which doesn't actually meet the requirements. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> 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.

5 years, 2 months

1
0
0 0

Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)

by Ken Liu

Hi, In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files. Because SPM could get what it needed by HAL API run-time. It can be mostly done inside the platform folder if one platform has the variants management already. Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Thursday, November 26, 2020 3:47 AM To: tf-m(a)lists.trustedfirmware.org Cc: Rasmussen, Torsten <Torsten.Rasmussen(a)nordicsemi.no> Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

5 years, 2 months

1
0
0 0

Externally override flash layout and pin configurations (out-of-tree platforms?)

by Rønningstad, Øyvind

Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

5 years, 2 months

1
0
0 0

gcc compiler requirement documentation

by Christopher Brand

Looking at docs/getting_started//tfm_sw_requirement.rst it says that the version requirement for gcc is "GNU Arm compiler v7.3.1+". then it describes where to get that toolchain, but in that section the two versions it suggests are "GNU Arm Embedded Toolchain: 6-2017-q1-update" and "GNU Arm Embedded Toolchain: 7-2018-q2-update". The former is gcc version 6.3.1, which doesn't actually meet the requirements. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> 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.

5 years, 2 months

1
0
0 0

Re: [TF-M] MCUBOOT_LOG_LEVEL description confusing/wrong

by Tamas Ban

Hi Thomas, Here is the fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7196 Actually since the CMake refactor the default value can be overridden from the command line, so it is possible to enable the logging even in Release builds. BR Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 2020. november 25., szerda 8:50 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] MCUBOOT_LOG_LEVEL description confusing/wrong The description of how to set MCUBOOT_LOG_LEVEL in tfm_secure_boot.rst appears wrong, or at least unclear. --- - MCUBOOT_LOG_LEVEL: Can be used to configure the level of logging in MCUBoot. The possible values are the following: - **LOG_LEVEL_OFF** - **LOG_LEVEL_ERROR** - **LOG_LEVEL_WARNING** - **LOG_LEVEL_INFO** - **LOG_LEVEL_DEBUG** The logging in MCUBoot can be disabled and thus the code size can be reduced by setting it to ``LOG_LEVEL_OFF``. Its value depends on the build type. If the build type is ``Debug`` and a value has been provided (e.g. through the command line or the CMake GUI) then that value will be used, otherwise it is ``LOG_LEVEL_INFO`` by default. In case of different kinds of ``Release`` builds its value is set to ``LOG_LEVEL_OFF`` (any other value will be overridden). --- I tried enabling MCUBOOT_LOG_LEVEL_DEBUG by adding -DMCUBOOT_LOG_LEVEL=LOG_LEVEL_DEBUG to the cmake command line, but that set the level to -1. I also tried -DMCUBOOT_LOG_LEVEL=4, which also set it to -1. I then noticed that the default setting in CMakeCache.txt is "MCUBOOT_LOG_LEVEL:STRING=INFO", so I instead used -DMCUBOOT_LOG_LEVEL=DEBUG, which worked. I would also like to be able to use logging for Release builds, as this may assist chasing down optimization issues. Thomas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

1
0
0 0

TF-M v1.2.0 release

by Anton Komlev

Hello, TF-M project released version v1.2.0, tagged as TF-Mv1.2.0. This release has started using adopted semantic versioning as described in the release_process.rst<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr…> Please take a look into the release notes for the new features and changes. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M technical lead Arm Ltd.

5 years, 2 months

1
0
0 0

MCUBOOT_LOG_LEVEL description confusing/wrong

by Thomas Törnblom

The description of how to set MCUBOOT_LOG_LEVEL in tfm_secure_boot.rst appears wrong, or at least unclear. --- - MCUBOOT_LOG_LEVEL: Can be used to configure the level of logging in MCUBoot. The possible values are the following: - **LOG_LEVEL_OFF** - **LOG_LEVEL_ERROR** - **LOG_LEVEL_WARNING** - **LOG_LEVEL_INFO** - **LOG_LEVEL_DEBUG** The logging in MCUBoot can be disabled and thus the code size can be reduced by setting it to ``LOG_LEVEL_OFF``. Its value depends on the build type. If the build type is ``Debug`` and a value has been provided (e.g. through the command line or the CMake GUI) then that value will be used, otherwise it is ``LOG_LEVEL_INFO`` by default. In case of different kinds of ``Release`` builds its value is set to ``LOG_LEVEL_OFF`` (any other value will be overridden). --- I tried enabling MCUBOOT_LOG_LEVEL_DEBUG by adding -DMCUBOOT_LOG_LEVEL=LOG_LEVEL_DEBUG to the cmake command line, but that set the level to -1. I also tried -DMCUBOOT_LOG_LEVEL=4, which also set it to -1. I then noticed that the default setting in CMakeCache.txt is "MCUBOOT_LOG_LEVEL:STRING=INFO", so I instead used -DMCUBOOT_LOG_LEVEL=DEBUG, which worked. I would also like to be able to use logging for Release builds, as this may assist chasing down optimization issues. Thomas

5 years, 2 months

1
0
0 0

Re: [TF-M] Technical Forum call - November 26

by David Hu

Hi Anton, I'd like to share a proposal to improve dual-cpu mailbox. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, November 19, 2020 4:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - November 26 Hello, The next Technical Forum is planned on Thursday, November 26 at 15:00-16:00 GMT (US friendly 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

5 years, 2 months

1
0
0 0

Re: [TF-M] Code freeze heads up for TF-M v1.2

by Anton Komlev

Hi, New TF-M Release Candidate 3 is tagged by TF-Mv1.2-RC3 Please update all repositories as it contain all fixes for issues found in RC2. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 11 November 2020 15:34 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Code freeze heads up for TF-M v1.2 Hi, New TF-M Release Candidate 2 is tagged by TF-Mv1.2-RC2. Please update all repositories as it contain fixes for issues found in RC1. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 04 November 2020 16:35 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Code freeze heads up for TF-M v1.2 Hi, All TF-M repositories are tagged with TF-Mv1.2-RC1 tag, marking the code freeze and beginning of the release candidate testing. 1. tf-m-tools 2. tf-m-tests 3. trusted-firmware-m 4. tf-m-ci-scripts 5. tf-m-job-configs Please use this tag for tests and report all issues found here. The best, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 02 November 2020 14:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Code freeze heads up for TF-M v1.2 Hi All, This is a reminder and heads up that TF-Mv1.2 release is planned for the end of November and TF-M code repository is aimed for freeze on Nov 4th (Wed), tagged by TF-Mv1.2-RC1 for testing. Availability of the tag will be notified via this mailing list. Thanks, Anton

5 years, 2 months

1
0
0 0

Technical Forum call - November 26

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, November 26 at 15:00-16:00 GMT (US friendly 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

5 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M