- TF-M - lists.trustedfirmware.org

by Andrei Narkevitch

Hi all, Just to let you know, some time ago Cypress has officially released the PSoC64 platform. With this, we are planning to stop supporting old PSoC64 development kits and move our focus on the new release boards. This is mainly because the old boards were programmed with an old firmware which is not compatible with the changes we do to the TFM code and it would be an unnecessary overhead to support both versions. Please let us know if it causes any issues. The new PSoC64 kit: https://www.cypress.com/documentation/development-kitsboards/psoc-64-standa… Thanks, Andrei Narkevitch Cypress Semiconductor Corp. An Infineon Technologies Company 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

Invitation: TF-M Tech Forum @ Thu 1 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 1 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=N250M2VrZnZtMnY0MjU3d… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 3 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 15 Oct 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 15 Oct 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MjRoajVlNjRuczZqYWIwN… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 3 months

1
0
0 0

New buildsystem merged

by Raef Coles

Hi all The new buildsystem has now been merged to both the trusted-firmware-m and tf-m-tests repositories. There are a few known issues: * STM platforms run into issues with flash space when building under debug configuration. * nxp/lpcxpresso66s69 fails regression tests - this is being looked into as a priority. For building with the new buildsystem, there have been some changes to the command-line. An example invocation is shown below. ``` cd <TFM root dir> mkdir build && cd build cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake make ``` CMAKE_TOOLCHAIN_FILE and TFM_PLATFORM are the only required arguments. CMAKE_TOOLCHAIN_FILE is conceptually a replacement for COMPILER. It is a path to one of the three toolchain files in the TFM root dir. * <TFM root dir>/toolchain_GNUARM.cmake * <TFM root dir>/toolchain_ARMCLANG.cmake * <TFM root dir>/toolchain_IARARM.cmake TFM_PLATFORM is conceptually a replacement for TARGET_PLATFORM. Unlike TARGET_PLATFORM it takes as an argument the path between `platform/ext/target` and the target dir. For example: * -DTFM_PLATFORM=musca_s1 * -DTFM_PLATFORM=cypress/psoc64 * -DTFM_PLATFORM=nxp/lpcxpresso55s69 PROJ_CONFIG has now been removed. Instead configuration has been simplified using composable variables. Enable regression tests: -DTEST_NS=ON -DTEST_S=ON Enable IPC mode: -DTFM_PSA_API=ON Set isolation level: -DTFM_ISOLATION_LEVEL=2 So instead of ConfigRegressionIPC: -DTEST_NS=ON -DTEST_S=ON -DTFM_PSA_API=ON For integration with other projects, there is a new option: -DNS=[ON/OFF] If NS is set to OFF, TFM will build only the secure image (as bin tfm_s.axf) and the PSA api as a static library. This should make integration with other projects much simpler. Other miscellaneous improvements: * Full ninja support * Automatic dependency management * generation of axf, elf, hex and bin files for all outputs * Full support for partial rebuilding and parallel building * Modular support for crypto accelerators * better integration of multi-core support For full details of buildsystem variable changes, refer to `docs/getting_started/tfm_build_instructions.rst` and `config/config_default.cmake` Raef

5 years, 3 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Thanks all for the inputs. May I collect answers for these questions: * Does the build system/IDE support sub-project for components and finally assemble them into one final image? The intention is to check the possibility to integrate TFM with sub-projects instead of a whole item. * Is there scenarios that dynamic sections being added into sct/ld, how do you deal with this? A reference link is also helpful. The intention: TF-M is actually a set of components, and the secure firmware part (secure boot is another image binary so not listed here) contains: 1. Libraries. 2. Partitions. 3. SPM. 4. Image assembling with all above components. The straight way is to generate ABC as *.a and assemble them together into a final image. Then go through each component, A and C can be configured in C domain, as what they needs maybe just some feature flags. B is a bit special but we still could provide specification defined .json and its compatible .yaml manifest and pre-generated C-based manifest with preprocessors. D is the hard part, as it needs special arrangement inside ld/sct, which make this discussion happen. Even the ‘include’ and ‘preprocessor’ are supported inside sct/ld, we still can not avoid the partitions including part, we can not do a foreach on the partition list which involve the preprocessor complexity into sct/ld. Looks like the templating can’t be avoided here. For platform specific requirements like: * Some platform won’t separate RODATA and CODE; * Some platform got non-continuous memory regions for special data; Put a platform dedicated sct/ld into the platform folder would help; but to mitigate the effort of platform, a common sct/ld needs to be abstracted. Thanks again for your great feedback. /Ken [History collapsed due to message size limitation]

5 years, 3 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Reed Hinkel

Hello Gyrogy: Your comment raises the question. Why is TF-M so complex and does it need to be the only answer? Either it needs to be simplified or respect must be paid to support in commercial tools as a first class citizen. Commercial tools are the path for large scale product developers. If they can’t engage TF-M with commercial tools or SiP tools then developers will face challenges to develop with it. It there are challenges they may even avoid using it in favor of simplified solutions much as they do today. Multiple target use cases will be using various components of TF-M (MbedTLS with and without hardware interfaces, Attestation, Audit Logs, etc.): 1. Arm v8M – Cortex-M33, M35, M55 2. Dual Core Systems – Multiple possible configs 3. Cortex v6M of v7M – M0, M0+, M3 & M4 4. TF-A 5. Other Cortex-R & Cortex-A implementations This reality argues for a more modular build packaging system that allows for it. All the best! Reed From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: Gyorgy Szing <Gyorgy.Szing(a)arm.com> Date: Wednesday, September 23, 2020 at 5:04 AM To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the “ecosystem” solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 AM 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] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can’t be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 AM 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] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don’t think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature – but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on “simple” values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. “Not sure if all these format support #include” The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What’s your opinion on this? Best regards, Shawn

5 years, 3 months

2
2
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Soby Mathew

Thanks Gyorgy for your inputs. I haven't checked out the details of all the pre-build processing, but it does seem complex to solve this in a portable way, but one suggestion from me is that perhaps the output from the pre-build processing should be a standard C header and from then on the standardized C pre-processing can be used for the rest of the configuration. For example, instead of the pre-build step generating producing the final linker script , it could instead generate a C header file which then can be consumed by the linker script. Here only the C header is generated and the linker script is untouched. This means that, if the IDEs can find a path to generate this C header file somehow (either via IDE configuration or different custom pre-build processing), then rest of the setup continues in a C standard way. Best regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 23 September 2020 11:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the "ecosystem" solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 AM 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] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 AM 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] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 3 months

2
1
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the "ecosystem" solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 AM 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] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 AM 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] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 3 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Hi, Thanks for the input - this should be the goal we are approaching. I believe the updated build system has changed something, and I will raise an proposal based on that during October, let's discuss when the proposal is done. Before that, two more questions: * So if a user have to modify the file manually, will they work on the .sct directly, or the .sct.template? * Does your IDE support pre-build function? What kinds of command it could support? An IDE specific script or general shell commands or python? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Wednesday, September 23, 2020 3:33 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 AM 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] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 AM 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] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 3 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 3 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Andrej Butok

Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 3 months

2
1
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 3 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 3 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 3 months

1
0
0 0

Linaro Connect Sessions of Interest

by Don Harbin

Hi All, As Linaro Connect starts tomorrow, here are some pointers to sessions that will be of interest related to trustedfirmware.org. - *PSA Secure Partitions in OP-TEE* - Tuesday, September 22nd (1:25-1:50pm UTC) - Speaker: Miklos Balint - Slides available here <https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…> - *Trusted Firmware Project update* - Tuesday, Sept. 22nd (2:00-2:25pm UTC) - Spreaders: Matteo Carlini, Shebu Kuriakose - Slides available here <https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…> - *Scalable Security Using Trusted Firmware-M Profiles* - Wednesday September 23rd (11.45am – 12.10pm UTC) - Speakers: Shebu Kuiakose, David Want - Slides available here <https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…> - *Enable UEFI Secure Boot using OP-TEE as Secure Partition* - Thursday September 24th (3.45-4.10pm UTC) - Speakers: Sahil Malhotra, Ilias Apalodimas - *Secure Partition Manager (SEL2 firmware) for Arm A-class devices* - Thursday September 24th (4.15-4.40pm UTC) - Speaker: Olivier Deprez - Slides are available here <https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…> Some general pointers to sessions of potential interest: - Security related topics can be viewed here - Boot architecture topics can be viewed here As a reminder, sign up for tomorrow's event is at Linaro Connect Registration <https://connect.linaro.org/> and is free, so feel free to forward this information on. :) The overall schedule is available at the same link as registration in case you may be interested in other sessions. Best regards, Don

5 years, 3 months

1
0
0 0

Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0)

by Soby Mathew

For the record, I have attached the full log of the PSA Arch Crypto test run on AN521. The SHA of respective repositories are the test run given below: TF-M - 8f895ab8 PSA Arch tests - ee3c463d tf-m-tests - 7789423 mbedtls - tag: mbedtls-2.23.0 There is an additional failure for test "psa_close_key with RSA 2048 keypair" compared to the summary report below. This is due to incorrect build flag propagation for changing the ITS_MAX_ASSET_SIZE. This will be corrected in the following days. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 21 August 2020 11:22 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Just an update to this, I have merged the patch which upgrades to the latest mbedTLS tag. The PSA Arch initial attestation test suite fails to build after this merge due to width change of `ecc_curve_t` type. The issue is reported here in PSA Arch test github project : https://github.com/ARM-software/psa-arch-tests/pull/232 The patch for changing the ITS_MAX_ASSET_SIZE is still outstanding and I hope to merge it after a week. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 11 August 2020 16:24 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Hi Everyone The following patch updates the crypto service in TF-M to use the latest mbedTLS tag v2.23.0. All reviews for the same will be much appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/1 With this update, additional PSA APIs psa_hash_compute() and psa_hash_compare() are now supported. There is also another patch for platforms to update the ITS_MAX_ASSET_SIZE when testing with PSA Crypto API compliance test as one of the tests require a larger size: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/1 . Could the platform owners review the same and let me know whether the size changes are OK ? With the above patches, the API compliance remains the same as v1.0 Beta 3 and the PSA Crypto compliance test suite gives the below results (as tested on AN521) : ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 42 TOTAL SIM ERROR : 0 TOTAL FAILED : 17 TOTAL SKIPPED : 2 ****************************************** Best Regards Soby Mathes

5 years, 3 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Summer Qin

Hi Anton, I'd like to briefly introduce the enhancement of the TF-M initialization flow, about 20 minutes. Regards, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, September 15, 2020 3:08 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - September 17 Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia 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, 3 months

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Sherry Zhang

Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia 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, 3 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Kevin Peng

Anton, I'd like to give an update on the HAL APIs, around 10 minutes. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia 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, 3 months

1
0
0 0

Secure Enclave solution in TF-M

by Mark Horvath

Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

5 years, 3 months

1
0
0 0

Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by Anton Komlev

Great news! Congratulations, Shery, David. You made it happen! Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M Sent: 14 September 2020 04:47 To: tf-m(a)lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Thanks Sherry for sharing this great news! Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Sherry Zhang via TF-M Sent: Monday, September 14, 2020 9:50 AM 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] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

5 years, 3 months

1
0
0 0

Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by David Wang

Thanks Sherry for sharing this great news! Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Sherry Zhang via TF-M Sent: Monday, September 14, 2020 9:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

5 years, 3 months

1
0
0 0

Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by Sherry Zhang

Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

5 years, 3 months

1
0
0 0

Re: [TF-M] The GNUARM linker script change about psa_client objects and the integration method [NXP]

by Ken Liu

Hi Andrej, Thanks, if the different approach for project compilation has its own ld file then we can remove these 4 lines - going to create a patch for this. BR /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Friday, September 11, 2020 9:10 PM To: Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: The GNUARM linker script change about psa_client objects and the integration method [NXP] Hi Ken, Guess, these lines where upstream from NXP SDK, which is using a different approach for project compilation. Most probably they may be removed for the original TFM. Best regards, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Friday, September 11, 2020 3:04 PM 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] The GNUARM linker script change about psa_client objects and the integration method [NXP] Hi, When I was trying to re-arrange the linker script I found below changes: *psa_client.*(.text*) /* NXP */ *psa_client.*(.rodata*) *psa_service.*(.text*) /* NXP */ *psa_service.*(.rodata*) *psa_lifecycle.*(.text*) /* NXP */ *psa_lifecycle.*(.rodata*) *tfm_log_raw.*(.text*) /* NXP */ I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated. What is the purpose of this change? Would it fix build problem or runtime problem? Thanks. /Ken

5 years, 3 months

1
0
0 0

The GNUARM linker script change about psa_client objects and the integration method [NXP]

by Ken Liu

Hi, When I was trying to re-arrange the linker script I found below changes: *psa_client.*(.text*) /* NXP */ *psa_client.*(.rodata*) *psa_service.*(.text*) /* NXP */ *psa_service.*(.rodata*) *psa_lifecycle.*(.text*) /* NXP */ *psa_lifecycle.*(.rodata*) *tfm_log_raw.*(.text*) /* NXP */ I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated. What is the purpose of this change? Would it fix build problem or runtime problem? Thanks. /Ken

5 years, 3 months

1
0
0 0

Test message - please ignore

by Bill Fletcher

.. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 3 months

1
0
0 0

Test message please ignore

by Bill Fletcher

. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 3 months

1
0
0 0

Skip GNUARM startup initialization

by Summer Qin

Hi, There is no forwarded define for '__START' in the current TF-M design, then the runtime init provided by toolchain is applied. This runtime init did something unnecessary as the data copying and ZI has been done already by the startup code, jumping to spm::main would be the next job as SPM would prepare runtime environment for subsequent partition execution and itself won't need other runtime operations besides the data moving. I have created a patch to jump to main under GNUARM: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5609 Change the code is because this would easy the code reading -- most of the users won't check a compiler flag given in the build system for forwarding '__START', so they will try to find the __start from the toolchain source. Currently, we can not avoid depending on ARMCLANG runtime init, so need double check (also IAR). Please provide your feedback, we are changing the platform startup code and need your confirmation to see if it is applicable. Best Regards, Summer

5 years, 3 months

1
0
0 0

TF-M Technical Forum call - September 17

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia 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, 3 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Raef Coles

Note that it's also still possible to use the "old style" cmake syntax: ``` mkdir build cd build cmake -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake .. make ``` Ninja is also supported as a generator by using ``` mkdir build cd build cmake -GNinja -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake .. ninja ``` This has been noted in the updated build documentation patch, which will be pushed to review.trustedfirmware.org as soon as possible (with other bugfixes, including both of the bugs encountered earlier in the email chain). Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 09 September 2020 08:58 To: 'tf-m(a)lists.trustedfirmware.org' Cc: nd Subject: Re: [TF-M] TF-M build system update heads-up Great to hear that that. BTW, instead of building all targets using “install” You can build a specific target separately by: cmake --build cmake_build --target <target> To list the targets available. use: cmake --build cmake_build --target help Cheers, Anton From: Christopher Brand <chris.brand(a)cypress.com> Sent: 08 September 2020 22:30 To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: TF-M build system update heads-up Thanks, Anton. That does work. The command I ran was definitely correct – I’ve tried switching back-and-forth between “-B” and “--build”, and they consistently fail and succeed, respectively. I’ve also seen my email client change “--” to “—“. I’m running cmake 3.18.2 on Ubuntu 18.04. Chris 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: Tuesday, September 8, 2020 1:13 PM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Could you try this: cmake --build cmake_build -- install Please note, when I copied your command the minus sign “-” was incorrect – probably a dash or hyphen sign. Need double check the doc. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 08 September 2020 19:48 To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; 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] TF-M build system update heads-up Hi, Sorry to hear that. When you manage to find out the culprit please drop an email to the list. I am really curious. /George From: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Sent: 08 September 2020 19:08 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; 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 build system update heads-up Thanks, Gyorgy. I did indeed have the double dash (pretty sure I just copied and pasted from the doc). I guess my email client decided to “fix it in the mail message. Chris From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Saturday, September 5, 2020 5:42 AM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; 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 build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D68687.0FBC1660] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris 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: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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. 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. 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, 3 months

1
0
0 0

Re: [TF-M] PSA tests: NVMEM section

by David Hu

Hi Øyvind, IMOO, such a NVME area is psa-arch-tests dedicated requirement, instead of TF-M implementation or FF-M definitions. I'd suggest to ask for more details in https://github.com/ARM-software/psa-arch-tests/. FYI a patch from psa-arch-test to enable such a NVME area in TF-M: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3360 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Wednesday, September 9, 2020 3:48 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA tests: NVMEM section According to psa-arch-tests[1] the tests need an NVMEM area to write its states to. "Non-volatile memory support to preserve test status over watchdog timer reset. Each byte of this region must be initialised to FF at power on reset." I could not find any code that does this in the TF-M or PSA repos. How do other platforms reserve and manage this 1k area. [1]: https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/p…

5 years, 3 months

2
1
0 0

Re: [TF-M] TF-M build system update heads-up

by Christopher Brand

Thanks, Anton. That does work. The command I ran was definitely correct – I’ve tried switching back-and-forth between “-B” and “--build”, and they consistently fail and succeed, respectively. I’ve also seen my email client change “--” to “—“. I’m running cmake 3.18.2 on Ubuntu 18.04. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, September 8, 2020 1:13 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Could you try this: cmake --build cmake_build -- install Please note, when I copied your command the minus sign “-” was incorrect – probably a dash or hyphen sign. Need double check the doc. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 08 September 2020 19:48 To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; 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] TF-M build system update heads-up Hi, Sorry to hear that. When you manage to find out the culprit please drop an email to the list. I am really curious. /George From: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Sent: 08 September 2020 19:08 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; 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 build system update heads-up Thanks, Gyorgy. I did indeed have the double dash (pretty sure I just copied and pasted from the doc). I guess my email client decided to “fix it in the mail message. Chris From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Saturday, September 5, 2020 5:42 AM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; 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 build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D685EC.35B811C0] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris 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: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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. 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. 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, 3 months

2
1
0 0

PSA tests: NVMEM section

by Rønningstad, Øyvind

According to psa-arch-tests[1] the tests need an NVMEM area to write its states to. "Non-volatile memory support to preserve test status over watchdog timer reset. Each byte of this region must be initialised to FF at power on reset." I could not find any code that does this in the TF-M or PSA repos. How do other platforms reserve and manage this 1k area. [1]: https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/p…

5 years, 3 months

1
0
0 0

Feature branch 'feature-isolation-level3' is created for related patches merging

by Ken Liu

Hi, A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging. The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please: IMPORTANT: Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'. BR /Ken

5 years, 3 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Anton Komlev

Hi Chris, Could you try this: cmake --build cmake_build -- install Please note, when I copied your command the minus sign “-” was incorrect – probably a dash or hyphen sign. Need double check the doc. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 08 September 2020 19:48 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M build system update heads-up Hi, Sorry to hear that. When you manage to find out the culprit please drop an email to the list. I am really curious. /George From: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Sent: 08 September 2020 19:08 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; 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 build system update heads-up Thanks, Gyorgy. I did indeed have the double dash (pretty sure I just copied and pasted from the doc). I guess my email client decided to “fix it in the mail message. Chris From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Saturday, September 5, 2020 5:42 AM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; 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 build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D68623.8624BBE0] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris 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: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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. 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, 3 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Gyorgy Szing

Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D68392.B953F780] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris 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: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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, 3 months

2
2
0 0

Re: [TF-M] TF-M build system update heads-up

by Christopher Brand

Thanks, Anton. I tried again today, and got further - the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build - install This error seems like something trivial: CMake Error: The source directory ".../trusted-firmware-m/install" does not exist. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to "MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn't successful. Following docs/getting_started/tfm_build_instruction.rst (the "Example: building TF-M for AN521 platform using GCC:" section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn't being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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, 3 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Robert Rostohar

Hi Soby, Hi Ken, Thanks for your replies. As mentioned before, majority of device vendors already provide system files (CMSIS standard) which configure also FPU. Take a look for example at the system file provided for STM32L5xx device family (part of STM32CubeL5 FW): https://github.com/STMicroelectronics/STM32CubeL5/blob/master/Drivers/CMSIS… Porting TF-M to a new device should be even simpler when such files can be used directly (or with as less modifications as possible). I'm not just looking at the few platforms that are directly supported within TF-M repo but rather how to reduce efforts to enable TF-M on any CMSIS-Core compliant device. Note: If current system files provided by vendors do not properly configure security features then this should be highlighted. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: Wednesday 2 September 2020 16:00 To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Robert, The current architecture abstraction depends on the some CMSIS standard macros (like __FPU_USED) to be defined and if there are vendor tools which can generate the same system file, as long as they are using the standard macros, the architecture abstraction should work alright if the generated file can be included. As Ken says, this makes architecture initialization uniform across platforms and provides the right settings to be applied for security. It also reduces the platform porting effort for new platforms. Hence the move in such a direction. If we allow a mechanism to allow the platform provided system file to be used rather than the default system file, will that suffice your requirement ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 02 September 2020 11:11 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] Changes to configure FPU at the architectural level in TF-M Hi Robert, Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here: https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie's second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting correctly. @Soby @Jamie, please update if I missed something. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M Sent: Wednesday, September 2, 2020 5:30 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; 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] Changes to configure FPU at the architectural level in TF-M Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 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] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 3 months

2
3
0 0

TF-M fault injection mitigation

by Tamas Ban

Hi, If you found yesterday the HW fault injection mitigation topic interesting and it raised your attention then you can find detailed info about it here: https://www.cl.cam.ac.uk/~rja14/Papers/whatyouc.pdf https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Chan… The PRs to MCUBoot are here: https://github.com/JuulLabs-OSS/mcuboot/pull/776 https://github.com/JuulLabs-OSS/mcuboot/pull/789 Tamas

5 years, 3 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Anton Komlev

Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to "MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn't successful. Following docs/getting_started/tfm_build_instruction.rst (the "Example: building TF-M for AN521 platform using GCC:" section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn't being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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, 3 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Christopher Brand

I tried to build PSoC64 with the new build system a couple of days ago, and wasn't successful. Following docs/getting_started/tfm_build_instruction.rst (the "Example: building TF-M for AN521 platform using GCC:" section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn't being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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, 3 months

1
0
0 0

TF-M build system update heads-up

by Anton Komlev

Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton

5 years, 3 months

1
0
0 0

New build system with IAR

by Thomas Törnblom

I've started looking at the new build system, and it looks like a nice improvement. I have a problem, that likely has a simple solution, although I'm not sure which. I've looked at the AN521 target, and the preload.cmake file is included very early from the root CMakeLists.txt The first line of preload.cmake is: --- set(CMAKE_SYSTEM_PROCESSOR cortex-m33+nodsp) --- For IAR that line should be: --- set(CMAKE_SYSTEM_PROCESSOR Cortex-M33.no_dsp) --- I need to discriminate between the toolchains already there, but I haven't figured out what the best way would be to do that. Not much is setup at this moment in the run. 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: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 3 months

1
1
0 0

Re: [TF-M] Simpler integration into other projects

by Anton Komlev

Hi Øyvind, Thank you for the proposal. Believe all agreed that NS side shall be separated from S side and be OS independent. There were multiple efforts recently toward this direction like repo split and build system refactoring. I think currently we almost achieve it. Assume you have seen that new build system allows creates S, NS, BL targets independently. Could you specify the remaining dependencies, you concern? Thanks, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: 02 September 2020 13:31 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Simpler integration into other projects Hi list I have a proposal to make it easier to integrate TF-M into other existing projects, e.g. RTOSes such as Zephyr. I'm using Zephyr as an example, but I mean that it should apply to any external project that wants to integrate TF-M. I'm assuming the project wants to use the secure FW as is, so no change is needed there. However, in the NS FW we want to integrate the NS callable (PSA) API into native Zephyr applications, but the NS ("app") part of TF-M has some OS dependencies that interfere with this. My proposal is that the TF-M build system creates OS-independent NS libs that can be linked directly into the native Zephyr app. Ideally, the Zephyr build system should need to only do the following: - Call TF-M build system. - Retrieve S binaries (and optionally mcuboot binary). - Link NS lib(s) into project app. - Add include directories to NS callable API. Additionally, the RTOS will likely need to make an OS wrapper to support the OS functions needed. Please tell me your thoughts. I'm not an expert in Cmake and libs, so please also tell me if the above is infeasible in any way. I think making such integrations as simple as possible will be very beneficial, not just when doing the initial integration, but continuously, since changes in TF-M will eventually require tweaks in the integration. Best regards, Øyvind Rønningstad -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 3 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Soby Mathew

Thanks Gyorgy for your inputs. My only concern with git hooks is that they are triggered when patches are pushed for review whereas checkpatch is something needs to be frequently run for non-trivial patchsets. The other issue is I am not sure whether we can pass different arguments to githooks whereas build system integration allows that (for example check the entire tree vs only the changed lines). Also having it part of regular build allows easier integration with work flow. Hence many OSS projects integrate this into regular build for this reason. But as you say, perhaps the first solution is to download the script and run locally and I don't have a strong opinion against git hooks either. Whatever works best can be used. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 02 September 2020 15:25 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CI Checkpatch Hi, My two cents on the topic. Sort term Sort term it is possible to clone the ci-scripts repository and to run the check-patch script locally (https://git.trustedfirmware.org/ci/tf-m-ci-scripts.git/tree/run-checkpatch.…) . The script has some in-line documentation. Long term I think this is an automation topic which may have a connection to the build system, but the right place for a solution in not there. When it comes to automation the best is to differentiate two use cases: 1. Centralized. This is where the automation happens on a server, and the main purpose is to keep authentic records about quality, or to drive delivery (i.e. push documents to hosting provider.) For this we have Jenkins. 2. De-centralized. This is when the automation is executed on the developers machine. How the user interacts with this system can be an implementation detail. The same scripts could be executed by git hooks, manually, or by the build system. I think the best solution would be to use git-hooks for decentralized automation, as this is there already, and has a well defined and standard interface towards the developer. The main problem with git hooks is, git as a policy leaves hook management as the responsibility of the developer, and there is no built-in way to deploy hooks to the developers machine. (This is due to security considerations.) As a solution to this issue multiple "hook frameworks" have been developed. I suggest investigating these and to build a decentralize automation solution on top of one of them. Ideally the same scripts executed by Jenkins could be executed by the framework too. Some contenders (and the language thy are developed with): * https://github.com/icefox/git-hooks - bash * https://github.com/git-hooks/git-hooks -golang * https://github.com/gnustavo/Git-Hooks - perl Of course there are many more. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 02 September 2020 15:18 To: Karl Zhang <Karl.Zhang(a)arm.com<mailto:Karl.Zhang@arm.com>>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; 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] CI Checkpatch Hi, Just my view on this, One of the things that will be helpful is to have is the checkpatch script imported into the project and have a `make checkpatch` build target. This will help to pipe clean check-patch errors from developer side before pushing patch for review. We could also make it a git hook but then I feel it is less convenient than having a regular build target. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M Sent: 02 September 2020 01:56 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] CI Checkpatch Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, September 1, 2020 12:35 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] CI Checkpatch So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, 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, 3 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 3

by Anton Komlev

Hello, The agenda for this forum: 1. Hardware fault injection mitigation 2. Secure Partition Addition Demonstration See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 26 August 2020 13:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 3 Hello, The next Technical Forum is planned on Thursday, September 3 at 15:00-16:00 UTC (US 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 Komlev

5 years, 3 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Gyorgy Szing

Hi, My two cents on the topic. Sort term Sort term it is possible to clone the ci-scripts repository and to run the check-patch script locally (https://git.trustedfirmware.org/ci/tf-m-ci-scripts.git/tree/run-checkpatch.…) . The script has some in-line documentation. Long term I think this is an automation topic which may have a connection to the build system, but the right place for a solution in not there. When it comes to automation the best is to differentiate two use cases: 1. Centralized. This is where the automation happens on a server, and the main purpose is to keep authentic records about quality, or to drive delivery (i.e. push documents to hosting provider.) For this we have Jenkins. 2. De-centralized. This is when the automation is executed on the developers machine. How the user interacts with this system can be an implementation detail. The same scripts could be executed by git hooks, manually, or by the build system. I think the best solution would be to use git-hooks for decentralized automation, as this is there already, and has a well defined and standard interface towards the developer. The main problem with git hooks is, git as a policy leaves hook management as the responsibility of the developer, and there is no built-in way to deploy hooks to the developers machine. (This is due to security considerations.) As a solution to this issue multiple "hook frameworks" have been developed. I suggest investigating these and to build a decentralize automation solution on top of one of them. Ideally the same scripts executed by Jenkins could be executed by the framework too. Some contenders (and the language thy are developed with): * https://github.com/icefox/git-hooks - bash * https://github.com/git-hooks/git-hooks -golang * https://github.com/gnustavo/Git-Hooks - perl Of course there are many more. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 02 September 2020 15:18 To: Karl Zhang <Karl.Zhang(a)arm.com>; Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CI Checkpatch Hi, Just my view on this, One of the things that will be helpful is to have is the checkpatch script imported into the project and have a `make checkpatch` build target. This will help to pipe clean check-patch errors from developer side before pushing patch for review. We could also make it a git hook but then I feel it is less convenient than having a regular build target. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M Sent: 02 September 2020 01:56 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] CI Checkpatch Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, September 1, 2020 12:35 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] CI Checkpatch So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, 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, 3 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Soby Mathew

Hi Robert, The current architecture abstraction depends on the some CMSIS standard macros (like __FPU_USED) to be defined and if there are vendor tools which can generate the same system file, as long as they are using the standard macros, the architecture abstraction should work alright if the generated file can be included. As Ken says, this makes architecture initialization uniform across platforms and provides the right settings to be applied for security. It also reduces the platform porting effort for new platforms. Hence the move in such a direction. If we allow a mechanism to allow the platform provided system file to be used rather than the default system file, will that suffice your requirement ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 02 September 2020 11:11 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Robert, Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here: https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie's second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting correctly. @Soby @Jamie, please update if I missed something. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M Sent: Wednesday, September 2, 2020 5:30 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; 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] Changes to configure FPU at the architectural level in TF-M Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 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] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 3 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Soby Mathew

Hi, Just my view on this, One of the things that will be helpful is to have is the checkpatch script imported into the project and have a `make checkpatch` build target. This will help to pipe clean check-patch errors from developer side before pushing patch for review. We could also make it a git hook but then I feel it is less convenient than having a regular build target. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Karl Zhang via TF-M Sent: 02 September 2020 01:56 To: tf-m(a)lists.trustedfirmware.org; Christopher Brand <chris.brand(a)cypress.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CI Checkpatch Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, September 1, 2020 12:35 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] CI Checkpatch So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, 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, 3 months

1
0
0 0

Re: [TF-M] psa_key_id_t type mismatch --- HardFault

by David Hu

Hi Alamy, In my very own opinion, `psk_key_id_t` defined as structure seems to be Mbed Crypto/MbedTLS own definition and should be transparent to applications calling `psa_open_key()`, as described in https://github.com/ARMmbed/mbedtls/blob/v2.23.0/include/psa/crypto_platform…. TF-M provides standard PSA APIs and therefore the `psa_key_id_t` in `psa_open_key()` is `uint32_t` as defined in PSA Cryptography API v1 Beta 3. The `uint32_t` `psa_key_id_t` is defined in `interface/include/psa/crypto_types.h` and included by TF-M Crypto interface files. Then when TF-M Crypto service invokes Mbed Crypto/MbedTLS APIs to fulfill the `psa_open_key()`, it includes Mbed Crypto/MbedTLS specific header file, in which `psa_key_id_t` is defined as a structure to support multiple client. For example, `crypto_key.c` constructs a `psa_key_id_t` structure and pass it to Mbed Crypto/MbedTLS `psa_open_key()` implementation. (https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…) It requires @Jamie Fox<mailto:Jamie.Fox@arm.com> and @Soby Mathew<mailto:Soby.Mathew@arm.com> help to provide a comprehensive answer. 😉 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Alamy Liu via TF-M Sent: Tuesday, September 1, 2020 1:23 AM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] psa_key_id_t type mismatch --- HardFault Sorry all, this is a FALSE alarm. Although some codes still include the local header file (uint32_t), none of them use psa_key_id_t at all. Maybe the code should be more clean, but there is no run-time problem! Sorry if it causes problems, Alamy On Mon, Aug 31, 2020 at 8:38 AM Alamy Liu <alamy.liu(a)gmail.com<mailto:alamy.liu@gmail.com>> wrote: Dear all, While I was working on the PSoC64 platform, I hit the psa_key_id_t type mismatch problem. The patch - 98ab441e096f enables MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER Which in terms to use the psa_key_id_t structure (psa_key_file_id_t) in <mbed-crypto/mbedtls>/include/psa/crypto_platform.h Interestingly, psa_key_id_t is also defined in <tf-m>/interface/include/psa/crypto_types.h, as a uint32_t. So, I do the following testing I could compile the master HEAD no problem 66ee5c8861 (HEAD, origin/master, origin/HEAD) Tools: update iat-verifier README and samples I assume the psa_key_id_t should be a structure (from mbed-crypto/mbedtls), I applied the patch below --- a/interface/include/psa/crypto_types.h +++ b/interface/include/psa/crypto_types.h @@ -211,6 +211,8 @@ typedef uint8_t psa_key_persistence_t; */ typedef uint32_t psa_key_location_t; +#if !defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER) +#error Should not compile this /** Encoding of identifiers of persistent keys. * * - Applications may freely choose key identifiers in the range @@ -222,6 +224,7 @@ typedef uint32_t psa_key_location_t; */ typedef uint32_t psa_key_id_t; #define PSA_KEY_ID_INIT 0 +#endif Then, I notice that there are still many files that use uint32_t psa_key_id_t in the TF-M source tree. a) It's good (lucky?) that TF-M seems to cut it cleanly so it doesn't run into problems (well, it happens on PSoC64, or I won't notice it). b) It's bad that psa_key_id_t in TF-M has two different types. I'm not going to argue what's correct/wrong. Maybe this kind of coding could be a feature in the future. I just go with it. But I found no information to define the boundary of the two types under the <tf-m>/docs/ directory. I would like to know where the boundary is, in TF-M. In other words, Which part of the code should use the structure definition from mbedtls/mbed-crypto; which part of the code should use uint32_t ? In my work, the problem happens when it passes psa_key_id_t as a parameter, the parent & child functions see it differently (HardFault, in my case, memory violation to other parameters). e.g.: func_a.c (structure), func_b.c (uint32_t). func_b.h ---- the type changes when it's included by func_a.c and/or func_b.c Regards, Alamy

5 years, 3 months

2
1
0 0

Simpler integration into other projects

by Rønningstad, Øyvind

Hi list I have a proposal to make it easier to integrate TF-M into other existing projects, e.g. RTOSes such as Zephyr. I'm using Zephyr as an example, but I mean that it should apply to any external project that wants to integrate TF-M. I'm assuming the project wants to use the secure FW as is, so no change is needed there. However, in the NS FW we want to integrate the NS callable (PSA) API into native Zephyr applications, but the NS ("app") part of TF-M has some OS dependencies that interfere with this. My proposal is that the TF-M build system creates OS-independent NS libs that can be linked directly into the native Zephyr app. Ideally, the Zephyr build system should need to only do the following: - Call TF-M build system. - Retrieve S binaries (and optionally mcuboot binary). - Link NS lib(s) into project app. - Add include directories to NS callable API. Additionally, the RTOS will likely need to make an OS wrapper to support the OS functions needed. Please tell me your thoughts. I'm not an expert in Cmake and libs, so please also tell me if the above is infeasible in any way. I think making such integrations as simple as possible will be very beneficial, not just when doing the initial integration, but continuously, since changes in TF-M will eventually require tweaks in the integration. Best regards, Øyvind Rønningstad

5 years, 3 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Ken Liu

Hi Robert, Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here: https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie's second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting correctly. @Soby @Jamie, please update if I missed something. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Wednesday, September 2, 2020 5:30 PM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 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] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 3 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Robert Rostohar

Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 3 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Karl Zhang

Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, September 1, 2020 12:35 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] CI Checkpatch So I see the CI system runs checkpatch, but I don’t see any mention of checkpatch under the “docs” directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, 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, 3 months

1
0
0 0

[RFC] The code review guideline

by Ken Liu

Hi, We are creating one document to describe the code review guidelines: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5372 The goal of this document is to introduce the source management level concepts to be followed while reviewing a code – which try to simplify the contribution (but burdens the reviewers? 😉). Difference to the `coding style`: * It focuses more on the source placement, interface definition and including, etc. As this document is keeping evolving in a period, the plan is we merge a simple version as start and adding more contents by new patches, so please give enough comments if you have, and don’t forget the concept: we want to make things rational and simple. Thanks. /Ken

5 years, 3 months

1
0
0 0

psa_key_id_t type mismatch --- HardFault

by Alamy Liu

Dear all, While I was working on the PSoC64 platform, I hit the *psa_key_id_t* type mismatch problem. The patch - *98ab441e096f *enables *MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER* Which in terms to use the *psa_key_id_t* *structure* (psa_key_file_id_t) in <mbed-crypto/mbedtls>/include/psa/*crypto_platform.h* Interestingly, psa_key_id_t is also defined in <tf-m>/interface/include/psa/ *crypto_types.h*, as a uint32_t. So, I do the following testing I could compile the master HEAD no problem *66ee5c8861* (HEAD, origin/master, origin/HEAD) Tools: update iat-verifier README and samples I assume the psa_key_id_t should be a *structure* (from mbed-crypto/mbedtls), I applied the patch below --- a/interface/include/psa/crypto_types.h +++ b/interface/include/psa/crypto_types.h @@ -211,6 +211,8 @@ typedef uint8_t psa_key_persistence_t; */ typedef uint32_t psa_key_location_t;+#if !defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER)+#error Should not compile this /** Encoding of identifiers of persistent keys. * * - Applications may freely choose key identifiers in the range @@ -222,6 +224,7 @@ typedef uint32_t psa_key_location_t; */ typedef uint32_t psa_key_id_t; #define PSA_KEY_ID_INIT 0+#endif Then, I notice that there are still many files that use *uint32_t* psa_key_id_t in the TF-M source tree. a) It's good (lucky?) that TF-M seems to cut it cleanly so it doesn't run into problems (well, it happens on PSoC64, or I won't notice it). b) It's bad that psa_key_id_t in TF-M has two different types. I'm not going to argue what's correct/wrong. Maybe this kind of coding could be a feature in the future. I just go with it. But I found no information to define the boundary of the two types under the <tf-m>/docs/ directory. I would like to know where the boundary is, in TF-M. In other words, *Which part of the code should use the structure definition from mbedtls/mbed-crypto; which part of the code should use uint32_t ?* In my work, the problem happens when it passes psa_key_id_t as a parameter, the parent & child functions see it differently (HardFault, in my case, memory violation to other parameters). e.g.: func_a.c (structure), func_b.c (uint32_t). func_b.h ---- the type changes when it's included by func_a.c and/or func_b.c Regards, Alamy

5 years, 3 months

1
1
0 0

CI Checkpatch

by Christopher Brand

So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, 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, 3 months

1
0
0 0

Changes to configure FPU at the architectural level in TF-M

by Jamie Fox

Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 3 months

1
0
0 0

ST platforms building broken

by Kevin Peng

Hi Michel, Some of the configurations on ST platform building is broken. Please see the details in the following ticket: https://developer.trustedfirmware.org/T808 Would you please have a look. Thanks. Best Regards, Kevin

5 years, 3 months

1
0
0 0

TF-M Technical Forum call - September 3

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, September 3 at 15:00-16:00 UTC (US 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 Komlev

5 years, 4 months

1
0
0 0

Re: [TF-M] New build system with IAR

by David Hu

Hi Thomas, Sorry if I misunderstand your problem. Does it mean that diverse compilers require different core config flags? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, August 25, 2020 7:39 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] New build system with IAR I've started looking at the new build system, and it looks like a nice improvement. I have a problem, that likely has a simple solution, although I'm not sure which. I've looked at the AN521 target, and the preload.cmake file is included very early from the root CMakeLists.txt The first line of preload.cmake is: --- set(CMAKE_SYSTEM_PROCESSOR cortex-m33+nodsp) --- For IAR that line should be: --- set(CMAKE_SYSTEM_PROCESSOR Cortex-M33.no_dsp) --- I need to discriminate between the toolchains already there, but I haven't figured out what the best way would be to do that. Not much is setup at this moment in the run. 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: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 4 months

2
2
0 0

Re: [TF-M] New build system with IAR

by Gyorgy Szing

Hi, CMAKE_SYSTEM_PROCESSOR identifies the CPU the build targets. If this string is passed to the compiler as a command line flag, that seems to be an error to me. Also I have the feeling that this value should be more hardware specific. A Cortex-M33 CPU has many configuration options to be set when it is put into a system, and different set of options may need different compiler switches. All this complexity might not be needed in the build-system and it could be better to hide it. I suggest naming the CMAKE_SYSTEM_PROCESSOR after the "chip" (i.e. AN521). The compiler specific files can map this name to the appropriate set of compiler options, and the compiler will set the "feature test macros" described in [1]. Source code can use these macros to configure itself properly. In the build system only features having an effect on CMake files shall be visible. (I.e. if a feature needs a different file to be compiled in.) [1] https://developer.arm.com/documentation/101028/0011/Feature-test-macros?lan… /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 25 August 2020 15:56 To: David Hu <David.Hu(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] New build system with IAR Hi David, Apparently yes. Here are the valid M33 choices for IAR: --- thomasto@ubuntu-20:~/tf-m1/trusted-firmware-m$ iccarm --cpu list|grep -i m33 Cortex-M33 Cortex-M33.no_dsp Cortex-M33.fp Cortex-M33.fp.no_dsp Cortex-M33.no_se Cortex-M33.no_dsp.no_se Cortex-M33.fp.no_se Cortex-M33.fp.no_dsp.no_se --- Cheers, Thomas Den 2020-08-25 kl. 15:49, skrev David Hu: Hi Thomas, Sorry if I misunderstand your problem. Does it mean that diverse compilers require different core config flags? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> Sent: Tuesday, August 25, 2020 7:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] New build system with IAR I've started looking at the new build system, and it looks like a nice improvement. I have a problem, that likely has a simple solution, although I'm not sure which. I've looked at the AN521 target, and the preload.cmake file is included very early from the root CMakeLists.txt The first line of preload.cmake is: --- set(CMAKE_SYSTEM_PROCESSOR cortex-m33+nodsp) --- For IAR that line should be: --- set(CMAKE_SYSTEM_PROCESSOR Cortex-M33.no_dsp) --- I need to discriminate between the toolchains already there, but I haven't figured out what the best way would be to do that. Not much is setup at this moment in the run. 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: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> -- 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>

5 years, 4 months

1
0
0 0

Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0)

by Soby Mathew

Just an update to this, I have merged the patch which upgrades to the latest mbedTLS tag. The PSA Arch initial attestation test suite fails to build after this merge due to width change of `ecc_curve_t` type. The issue is reported here in PSA Arch test github project : https://github.com/ARM-software/psa-arch-tests/pull/232 The patch for changing the ITS_MAX_ASSET_SIZE is still outstanding and I hope to merge it after a week. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 11 August 2020 16:24 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Hi Everyone The following patch updates the crypto service in TF-M to use the latest mbedTLS tag v2.23.0. All reviews for the same will be much appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/1 With this update, additional PSA APIs psa_hash_compute() and psa_hash_compare() are now supported. There is also another patch for platforms to update the ITS_MAX_ASSET_SIZE when testing with PSA Crypto API compliance test as one of the tests require a larger size: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/1 . Could the platform owners review the same and let me know whether the size changes are OK ? With the above patches, the API compliance remains the same as v1.0 Beta 3 and the PSA Crypto compliance test suite gives the below results (as tested on AN521) : ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 42 TOTAL SIM ERROR : 0 TOTAL FAILED : 17 TOTAL SKIPPED : 2 ****************************************** Best Regards Soby Mathes

5 years, 4 months

1
0
0 0

Re: [TF-M] Deprecate AN539 platform

by Soby Mathew

Thanks Andrew for the update. Just to confirm that AN521 is not affected. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Murray via TF-M Sent: 20 August 2020 08:04 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Deprecate AN539 platform Hi Thomas :) Thanks for that note about the AN521. I've just checked and I was mistaken - it is in fact the AN521 that I am using (rather than the AN539). I therefore have no objection to the deprecation. Sorry about wasting your time :( Andrew ;) -- Andrew Murray indie Semiconductor |Technical Director | MCU Architectures & Security ---------- Forwarded message ---------- From: "Thomas Törnblom" <thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com>> To: <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: Bcc: Date: Thu, 20 Aug 2020 08:51:34 +0200 Subject: Re: [TF-M] Deprecate AN539 platform AN521 is also mps2+/m33.

5 years, 4 months

1
0
0 0

Re: [TF-M] Deprecate AN539 platform

by Andrew Murray

Hi Thomas :) Thanks for that note about the AN521. I've just checked and I was mistaken - it is in fact the AN521 that I am using (rather than the AN539). *I therefore have no objection to the deprecation*. Sorry about wasting your time :( Andrew ;) *--* *Andrew Murray* *indie Semiconductor |Technical Director | MCU Architectures & Security* ---------- Forwarded message ---------- From: "Thomas Törnblom" <thomas.tornblom(a)iar.com> To: <tf-m(a)lists.trustedfirmware.org> Cc: Bcc: Date: Thu, 20 Aug 2020 08:51:34 +0200 Subject: Re: [TF-M] Deprecate AN539 platform AN521 is also mps2+/m33.

5 years, 4 months

1
0
0 0

-DBL2=False causes duplicates in ASM_FLAGS in makefiles

by Thomas Törnblom

For some reason that I've not been able to track down, using -DBL2=False on the cmake command line causes ASM_FLAGS to have duplicated debug flags and defines. It does not happen to C_FLAGS and it doesn't happen with -DBL2=True. I've worked around the issue in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5365, but a cleaner solution would be to avoid this in the first place. I would appreciate if someone with more cmake experience could have a go at this. It causes build failures with IAR, and ARMCLANG and GNUARM doesn't care about the duplicates. 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>

5 years, 4 months

1
0
0 0

Re: [TF-M] Deprecate AN539 platform

by Thomas Törnblom

AN521 is also mps2+/m33. Den 2020-08-20 kl. 08:48, skrev Andrew Murray via TF-M: > Hi Soby ;) > > I'm currently using an MPS2+ board with the AN539 system to experiment > with TF-M code for a new M33-based, IC design. Does "deprecating the > AN539 platform" effectively mean deprecating TF-M support for the > MPS2+ FPGA platform entirely? In other words: is AN539 the only > example subsystem for the MPS2+ board that supports the M33 and TF-M? > If it is, then I'd like to object (for what that's worth!) > > (Feel free to try to persuade me of the merits of an alternative > prototyping platform.) > > Andrew ;) > > /--/ > > /Andrew Murray/ > > /indie Semiconductor |Technical Director | MCU Architectures & Security/ > > // > > > > ... > From: Soby Mathew <Soby.Mathew(a)arm.com <mailto:Soby.Mathew@arm.com>> > To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org > <mailto:tf-m@lists.trustedfirmware.org>> > Cc: > Bcc: > Date: Mon, 17 Aug 2020 14:11:36 +0000 > Subject: [TF-M] Deprecate AN539 platform > > Hi Everyone, > > As mentioned in > https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr…, > we would like to propose the deprecation of AN539 MPS2 platform and > remove the same from TF-M master after next release. As per the > process, this proposal will be open for discussion for a period of 4 > weeks and if there are no major objections, the platform will be > marked as deprecated. > > Thanks & Regards > > Soby Mathew > > -- *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>

5 years, 4 months

1
0
0 0

Re: [TF-M] Deprecate AN539 platform

by Andrew Murray

Hi Soby ;) I'm currently using an MPS2+ board with the AN539 system to experiment with TF-M code for a new M33-based, IC design. Does "deprecating the AN539 platform" effectively mean deprecating TF-M support for the MPS2+ FPGA platform entirely? In other words: is AN539 the only example subsystem for the MPS2+ board that supports the M33 and TF-M? If it is, then I'd like to object (for what that's worth!) (Feel free to try to persuade me of the merits of an alternative prototyping platform.) Andrew ;) *--* *Andrew Murray* *indie Semiconductor |Technical Director | MCU Architectures & Security* ... From: Soby Mathew <Soby.Mathew(a)arm.com> To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Cc: Bcc: Date: Mon, 17 Aug 2020 14:11:36 +0000 Subject: [TF-M] Deprecate AN539 platform Hi Everyone, As mentioned in https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr…, we would like to propose the deprecation of AN539 MPS2 platform and remove the same from TF-M master after next release. As per the process, this proposal will be open for discussion for a period of 4 weeks and if there are no major objections, the platform will be marked as deprecated. Thanks & Regards Soby Mathew

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - August 20

by Anton Komlev

Hello, The agenda is empty since no topics were proposed. I will start the session anyway for ad-hoc discussions or Q&A, but feel free to treat it as cancelled and enjoy your vacation season. The best, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 12 August 2020 13:56 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - August 20 Hello, The next Technical Forum is planned on Thursday, August 20 at 6:00-07:00 UTC (Asia 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 Komlev

5 years, 4 months

1
0
0 0

Deprecate AN539 platform

by Soby Mathew

Hi Everyone, As mentioned in https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr…, we would like to propose the deprecation of AN539 MPS2 platform and remove the same from TF-M master after next release. As per the process, this proposal will be open for discussion for a period of 4 weeks and if there are no major objections, the platform will be marked as deprecated. Thanks & Regards Soby Mathew

5 years, 4 months

1
0
0 0

Re: [TF-M] Detailed build logfiles

by Gyorgy Szing

Hi, Please see the file “pipeline.log” on the artifacts tab, or based on the job name and build number (tf-m-static; 428), find the job on the Jenkins main page (https://ci.trustedfirmware.org/). Then check the console output using the menus related to the build number (https://ci.trustedfirmware.org/view/TF-M/job/tf-m-static/428/console). You can find the triggered sub-jobs the same way (in you case tf-m-build-and-test #434; https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-and-test/434/console). At a quick glance some lava errors seem to be the root cause: Calling: 'nice' 'docker' 'pull' 'REPLACE_DOCKER_PREFIX/lava-fvp-mps2' >> invalid reference format: repository name must be lowercase see here: https://tf.validation.linaro.org/scheduler/job/9372 Note: I did not made a full investigation, just a quick check. Please dig trough all the sub-jobs to ensure my result is correct. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Malcolm Fernandes via TF-M Sent: 14 August 2020 21:04 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Detailed build logfiles This Gerrit https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5286 has a build failure as per the TFM CI build system. When I click on the link (https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai…), it just has two lines. How do I see a detailed log of that build? Cheers, Mal

5 years, 4 months

2
1
0 0

Detailed build logfiles

by Malcolm Fernandes

This Gerrit https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5286 has a build failure as per the TFM CI build system. When I click on the link ( https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai…), it just has two lines. How do I see a detailed log of that build? Cheers, Mal

5 years, 4 months

1
0
0 0

Re: [TF-M] [RFC]Patches for migrating testing codes from TF-M to tf-m-tests

by Kevin Peng

Hi all The review window has closed as promised. I'd like to merge the changes by 13th, Aug (Tomorrow). To be noted that any changes for TF-M/test or TF-M/app will have to "rebase" to the tf-m-tests repo after the merge. Will let you know when the merge is done. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Friday, July 24, 2020 10:16 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC]Patches for migrating testing codes from TF-M to tf-m-tests Hi, As have shared on the tech forum yesterday, there is the activity to move the test codes from tf-m to tf-m-tests. Here are the patches for the step 1 - moving the codes without modifications: https://review.trustedfirmware.org/q/topic:%22Migration_of_test_code%22+(st… Please help on review. Thanks. The review window would be closed in one week in case of no comments. Best Regards, Kevin

5 years, 4 months

1
1
0 0

TF-M Technical Forum call - August 20

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, August 20 at 6:00-07:00 UTC (Asia 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 Komlev

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M repository restructure

by Anton Komlev

Hello, This is a kind reminder on TF-M repository change below. The old URL will be alive for the following 3 months before depreciation. Regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 14 May 2020 15:32 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M repository restructure Hello, Let me announce the changes in TF-M project repository structure. To allow project grow up in a more organized way the existing codebase will be split on multiple repositories and placed under TF-M folder. This is the similar structure as all other projects have in git.trustedfirmware.org<https://git.trustedfirmware.org>. This weekend TF-M git repository will be moved from https://git.trustedfirmware.org/trusted-firmware-m.git to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git The original URL will be supported for some time (as a link to the new one) giving time for adjustment. Current plan is to keep the redirection for 6 months but let me know please, if it makes any conflict and another depreciation period is better. Best regards, Anton Komlev

5 years, 4 months

1
0
0 0

Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0)

by Soby Mathew

Hi Everyone The following patch updates the crypto service in TF-M to use the latest mbedTLS tag v2.23.0. All reviews for the same will be much appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/1 With this update, additional PSA APIs psa_hash_compute() and psa_hash_compare() are now supported. There is also another patch for platforms to update the ITS_MAX_ASSET_SIZE when testing with PSA Crypto API compliance test as one of the tests require a larger size: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/1 . Could the platform owners review the same and let me know whether the size changes are OK ? With the above patches, the API compliance remains the same as v1.0 Beta 3 and the PSA Crypto compliance test suite gives the below results (as tested on AN521) : ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 42 TOTAL SIM ERROR : 0 TOTAL FAILED : 17 TOTAL SKIPPED : 2 ****************************************** Best Regards Soby Mathew

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - August 6

by Anton Komlev

Hello, The agenda for this forum: 1. Musca-B1 Secure Enclave solution 2. Platform specific vs common scatter/link scripts 3. Any Other Business See you, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 03 August 2020 12:13 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M Technical Forum call - August 6 Hi, I would like to talk a little about the Musca-B1 Secure Enclave solution I plan it to 15 minutes +questions. Best regards, Mark 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: 28 July 2020 19:24 To: 'tf-m(a)lists.trustedfirmware.org' <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] TF-M Technical Forum call - August 6 Hello, The next Technical Forum is planned on Thursday, August 6 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 4 months

1
0
0 0

Proposal to separate SCT/LD into each platform folder

by Shawn Shan

Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 4 months

1
0
0 0

Re: [TF-M] Fail pushing, no common ancestry

by Soby Mathew

Hi Thomas >From the log, Your folder seems to indicate trusted-firmware-m and you are trying to push to tf-m-tests. The trusted-firmware-m.git<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/> and tf-m-tests.git<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> do not have a common ancestor. You might need to create a patch file and then apply to the tests repo manually I think. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 03 August 2020 15:43 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Fail pushing, no common ancestry I've tried fixing a minor issue in one of my already pushed changes, but for some reason I get an error. To avoid anything I've done today I tried to push the local repo with no changes at all since I pushed it last, and I'm still getting an issue, and it seems related to tf-m-tests --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/tf-m-tests.git HEAD:refs/for/master Enumerating objects: 24547, done. Counting objects: 100% (24547/24547), done. Delta compression using up to 4 threads Compressing objects: 100% (8849/8849), done. Writing objects: 100% (24547/24547), 12.14 MiB | 1.07 MiB/s, done. Total 24547 (delta 17058), reused 21946 (delta 15111), pack-reused 0 remote: Resolving deltas: 100% (17058/17058) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org/TF-M/tf-m-tests.git ! [remote rejected] HEAD -> refs/for/master (no common ancestry) error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/tf-m-tests.git' --- What am I missing? 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>

5 years, 4 months

2
1
0 0

Fail pushing, no common ancestry

by Thomas Törnblom

I've tried fixing a minor issue in one of my already pushed changes, but for some reason I get an error. To avoid anything I've done today I tried to push the local repo with no changes at all since I pushed it last, and I'm still getting an issue, and it seems related to tf-m-tests --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/tf-m-tests.git HEAD:refs/for/master Enumerating objects: 24547, done. Counting objects: 100% (24547/24547), done. Delta compression using up to 4 threads Compressing objects: 100% (8849/8849), done. Writing objects: 100% (24547/24547), 12.14 MiB | 1.07 MiB/s, done. Total 24547 (delta 17058), reused 21946 (delta 15111), pack-reused 0 remote: Resolving deltas: 100% (17058/17058) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org/TF-M/tf-m-tests.git ! [remote rejected] HEAD -> refs/for/master (no common ancestry) error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/tf-m-tests.git' --- What am I missing? 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>

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - August 6

by Mark Horvath

Hi, I would like to talk a little about the Musca-B1 Secure Enclave solution I plan it to 15 minutes +questions. Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 28 July 2020 19:24 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - August 6 Hello, The next Technical Forum is planned on Thursday, August 6 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 4 months

1
0
0 0

Re: [TF-M] Process for deprecating and removing platforms

by Soby Mathew

Hi Everyone Just a reminder, I plan to merge this proposal by end of this week. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 16 July 2020 14:00 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Process for deprecating and removing platforms Hi Everyone, The document in tf.org defines the different "Platform Support Life Cycle": https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Although a platform can be implicitly in deprecated state due to lack of support or maintenance, a process to explicitly declare a platform as deprecated with the intention to remove it in future is needed as well. So I have attempted to define a process as described here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4962/1/docs/… Comments welcome. Best Regards Soby Mathew

5 years, 4 months

1
0
0 0

Call for final review of Profile Medium patches

by David Hu

Hi all, Thanks a lot for the reviews and comments on Profile Medium patches. I'd like to merge those patches by this Thursday if no further critical issue. Please access https://review.trustedfirmware.org/q/topic:%22profile-m-config%22+(status:o… if you are interested to take another look. Thank you. Best regards, Hu Ziji

5 years, 4 months

1
0
0 0

TF-M Technical Forum call - August 6

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, August 6 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 4 months

1
0
0 0

Re: [TF-M] Ninja builds broken

by Ken Liu

Looks like some mistake happened in the cmake file which causes trouble under windows. I have created a patch for this: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5100 Could you check if this would help? Thanks. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Tuesday, July 28, 2020 12:33 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Ninja builds broken Looks like Ninja builds are now broken for some targets. AN519, AN521, AN539, and possibly others, fails to link tfm_ns.axf with the following error: --- Usage: wrapper.py [OPTIONS] INFILE OUTFILE Try "wrapper.py --help" for help. Error: Got unexpected extra argument (C:/Users/thomasto/Projects/tf-m1/trusted-firmware-m/cmake_build_gcc/tfm_s_signed.bin) ninja: build stopped: subcommand failed. --- 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>

5 years, 4 months

1
0
0 0

Ninja builds broken

by Thomas Törnblom

Looks like Ninja builds are now broken for some targets. AN519, AN521, AN539, and possibly others, fails to link tfm_ns.axf with the following error: --- Usage: wrapper.py [OPTIONS] INFILE OUTFILE Try "wrapper.py --help" for help. Error: Got unexpected extra argument (C:/Users/thomasto/Projects/tf-m1/trusted-firmware-m/cmake_build_gcc/tfm_s_signed.bin) ninja: build stopped: subcommand failed. --- 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>

5 years, 4 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 17 Sep 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 17 Sep 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NjZuNjVnbmNmZG1qZ24xa… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 5 months

1
0
0 0

Invitation: TF-M tech forum @ Thu 3 Sep 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M tech forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 3 Sep 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=M2R2cW8ycGhvbGk0bWM0M… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 5 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 20 Aug 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 20 Aug 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MmhydThhczM3N3RrNnNmY… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 5 months

1
0
0 0

Invitation: TF-M Tech forum @ Thu 6 Aug 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 6 Aug 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MjZua2JubGhybjJlMGswM… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 5 months

1
0
0 0

[RFC]Patches for migrating testing codes from TF-M to tf-m-tests

by Kevin Peng

Hi, As have shared on the tech forum yesterday, there is the activity to move the test codes from tf-m to tf-m-tests. Here are the patches for the step 1 - moving the codes without modifications: https://review.trustedfirmware.org/q/topic:%22Migration_of_test_code%22+(st… Please help on review. Thanks. The review window would be closed in one week in case of no comments. Best Regards, Kevin

5 years, 5 months

1
0
0 0

TF-M: v1.1 and Ecosystem Enablement Blog

by Shebu Varghese Kuriakose

Hi All, Here is a blog about TF-M v1.1 and recent Ecosystem enablement - https://www.trustedfirmware.org/blog/tfm-v1-1-blog/ Regards, Shebu TF-M Technology Manager

5 years, 5 months

1
0
0 0

Re: [TF-M] New TrustedFirmware.org security incident process is now live

by Anton Komlev

Hi, Let me remind you about the security incident process and open registration for Trusted Stakeholders. Best regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley via TF-M Sent: 30 June 2020 15:13 To: tsc(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org; tf-m(a)lists.trustedfirmware.org; op-tee(a)lists.trustedfirmware.org; mbed-tls(a)lists.trustedfirmware.org; mbed-tls-announce(a)lists.trustedfirmware.org; hafnium(a)lists.trustedfirmware.org Subject: [TF-M] New TrustedFirmware.org security incident process is now live Hi all The new TrustedFirmware.org security incident process is now live. This process is described here: https://developer.trustedfirmware.org/w/collaboration/security_center/repor… Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change. If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here: https://developer.trustedfirmware.org/w/collaboration/security_center/trust… Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. Best regards Dan. (on behalf of the TrustedFirmware.org security team)

5 years, 5 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - July 23

by Kevin Peng

Hi Anton, I'd like to give a brief introduction on the changes (both happened and proposal) for TF-M testing. The duration would be ~30 minutes. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, July 20, 2020 4:14 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - July 23 Hello, The next Technical Forum is planned on Thursday, July 23 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 5 months

2
1
0 0

New build system WIP

by Raef Coles

Hi all The new buildsystem (work in progress) is now available at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5039. Comment would be very much appreciated. There have been some minor interface changes to how the buildsystem is invoked. a sample invocation is: cmake -S .. \ -B . \ -G"Unix Makefiles" \ -DTFM_PLATFORM=musca_s1 \ -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake \ -DCMAKE_BUILD_TYPE=release -DBL2=ON \ -DNS=ON \ -DTFM_PSA_API=ON \ -DTEST_NS=ON -DTEST_S=ON \ -DTFM_ISOLATION_LVL=2 More specifically cmake -S [Source_dir (often ..)] \ -B [build_dir (often .)] \ -G ["Unix Makefiles" OR Ninja] \ -DTFM_PLATFORM=[musca_b1 OR musca_s1 OR mps2/an521 OR cypress/psoc64 ETC...] -DCMAKE_TOOLCHAIN_FILE=[build_dir/toolchain_GNUARM.cmake OR build_dir/toolchain_ARMCLANG.cmake] -DCMAKE_BUILD_TYPE=[release OR debug OR minsizerel OR relwithdbginfo] -DBL2=[OFF OR ON] -DNS=[OFF OR ON] -DTFM_PSA_API=[OFF OR ON] -DTEST_NS=[OFF OR ON] -DTEST_S=[OFF OR ON] -DTFM_ISOLATION_LVL=[1 OR 2] Note that this interface is not set in stone and may change before these patches are merged. The new buildsystem is currently missing a few of the platforms, as well as some features. All of these are planned to be added prior to merging. Notable are dualcpu/Cypress PSoC64 which is currently being finalized, documentation building, and image signing for some of the boot modes which is on the TODO list. Note that unlike previous versions, this should work "out the box" with regard to dependencies. The paths for dependencies can be set, but some patches to mbedtls that are in the process of being upstreamed are used. These patches are stored in the lib/ext/mbedcrypto directory and can easily be applied manually. Regards, Raef Coles

5 years, 5 months

1
0
0 0

MCUBoot related changes

by Tamas Ban

Hi, Just a heads-up for the coming changes related to MCUBoot. Some of them requires installing new tools in build system others could affect devices on the field (if there is any) after SW upgrade. Short term, within one week: 1. Official imgtool enablement: * The official released version of the image signings script will be used. * Must be installed in the build system. It is a PyPI package: imgtool v1.6 * https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4564/6 2. Encrypted image support: * This feature already exists in the upstream repo for a while * This change makes possible to turn it on in TF-M build system * https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4565/6 Long term, but still expected in Q3: 1. Removal of forked MCUBoot from TF-M: * Only upstream MCUBoot will supported * Platform and project related files will be kept: i. shim layer to match MCUBoot HAL's to TF-M's HAL ii. bl2_main.c, example signing keys, keys.c iii. platform code: flash and UART drivers, implementation of boot_hal.h * When building TF-M with upstream MCUboot it is a mixture of files from the two repo + crypto code from mbedcrypto repo. * https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4953 * The removal of the fork depends on the feature upstream to MCUBoot repo: i. https://github.com/JuulLabs-OSS/mcuboot/pull/739 ii. RAM_LOAD: PR will come a bit later 1. Removal of LEGACY_TFM_TLV_HEADER support * This is a compatibility mode. It was introduced to hide the difference in the definition of the TLV header int he shared data between bootloader and runtime SPE. * If forked removed, then this is not necessary anymore, unless an forked version of MCUBoot wants to cooperate new SPE. * Please check and indicate if you think that this is a valid use case and compatibility mode must be kept! Tamas

5 years, 5 months

1
1
0 0

TF-M/FreeRTOS blog

by Shebu Varghese Kuriakose

Hi All, Here is a blog post about FreeRTOS/TF-M integration - https://freertos.org/2020/07/security-for-arm-cortex-m-devices-with-freerto… Regards, Shebu

5 years, 5 months

1
0
0 0

TF-M Technical Forum call - July 23

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, July 23 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 5 months

1
0
0 0

Process for deprecating and removing platforms

by Soby Mathew

Hi Everyone, The document in tf.org defines the different "Platform Support Life Cycle": https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Although a platform can be implicitly in deprecated state due to lack of support or maintenance, a process to explicitly declare a platform as deprecated with the intention to remove it in future is needed as well. So I have attempted to define a process as described here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4962/1/docs/… Comments welcome. Best Regards Soby Mathew

5 years, 5 months

1
0
0 0

Re: [TF-M] Persistent key storage ownership/access

by Andrew Thoelke

Hi, The ITS design requires that all data items are private to its client - it essentially just provides a persistence capability within the same isolation domain. So it is not possible for two distinct clients to access the same stored material, *unless they do this through a common intermediary*. Jamie outlines one approach: PSA Crypto Partition hosts the key store, and delegates the operations to the AES partition. But this fails the concurrency requirement as noted. Another plausible approach is that the AES Partition is a special/trusted client of the PSA Crypto Partition and uses a dedicated service/API to retrieve the AES client's key material. However, this also fails the concurrency objective when the PSA Crypto Partition is busy. Without the IPC model (which allows for nested/interleaved message handling, under service developer control) - the design that would work is to: 1. Create a key store Partition that interfaces with ITS 2. Have the PSA Crypto and AES partitions be trusted clients of the key store (the key store does not allow other client connections) 3. Key management operations go through a PSA Crypto service, which invokes the key store service to store material in ITS 4. AES operations go through a AES service, which invokes the key store service to retrieve key material This model works, but delivering the desired concurrency requires that the framework supports multiple Partitions, and can run one Partition while another is busy/blocked. Note that the key store service is _just_ a proxy to ITS using the key-id + Crypto-client-id supplied by its client. Security depends on the client-ids of the Crypto and AES Partitions being fixed so that the private key store service can strictly enforce which clients can use it. Regards, Andrew From: psa-crypto <psa-crypto-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via psa-crypto Sent: 10 July 2020 14:22 To: Quach, Brian <brian(a)ti.com>; tf-m(a)lists.trustedfirmware.org; psa-crypto(a)lists.trustedfirmware.org Subject: Re: [psa-crypto] Persistent key storage ownership/access Hi Brian, It is true that each persistent key has only one owner who can access it, the partition that created it. But note that even if the driver partition could be given permission to access the key, then it wouldn't immediately fix the issue. The driver partition would then need to implement another layer of access control, otherwise partitions would be able to use it as a conduit to access keys that they don't themselves own. I think a more expected flow would look like: 1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function in the PSA Crypto partition and provides the key ID. 3. PSA Crypto partition retrieves the key from ITS for use. Client ID = -1. 4. PSA Crypto partition calls an AES crypto function in the driver partition and provides the key material. But I assume you discarded this approach because it didn't give you the level of concurrency between PSA Crypto and the crypto driver that you wanted. I am adding the psa-crypto mailing list to this, as people on there may have more/better input. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Quach, Brian via TF-M Sent: 10 July 2020 06:18 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Persistent key storage ownership/access Hi, I see that keys can only be accessed/modified by their owning secure partition. File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1) Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3. However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work. Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the 32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver The file ID would not match what the App imported and the key would not be found. Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated? Another explanation of the scenario if the above was not clear: 1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function and provides the key ID. 3. AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition. RoT Partition 1: * PSA Crypto (with keystore) RoT Partition 2: - AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators) RoT Partition 3: * ITS Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 5 months

2
1
0 0

Re: [TF-M] Persistent key storage ownership/access

by Jamie Fox

Hi Brian, It is true that each persistent key has only one owner who can access it, the partition that created it. But note that even if the driver partition could be given permission to access the key, then it wouldn't immediately fix the issue. The driver partition would then need to implement another layer of access control, otherwise partitions would be able to use it as a conduit to access keys that they don't themselves own. I think a more expected flow would look like: 1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function in the PSA Crypto partition and provides the key ID. 3. PSA Crypto partition retrieves the key from ITS for use. Client ID = -1. 4. PSA Crypto partition calls an AES crypto function in the driver partition and provides the key material. But I assume you discarded this approach because it didn't give you the level of concurrency between PSA Crypto and the crypto driver that you wanted. I am adding the psa-crypto mailing list to this, as people on there may have more/better input. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Quach, Brian via TF-M Sent: 10 July 2020 06:18 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Persistent key storage ownership/access Hi, I see that keys can only be accessed/modified by their owning secure partition. File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1) Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3. However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work. Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the 32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver The file ID would not match what the App imported and the key would not be found. Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated? Another explanation of the scenario if the above was not clear: 1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function and provides the key ID. 3. AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition. RoT Partition 1: * PSA Crypto (with keystore) RoT Partition 2: - AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators) RoT Partition 3: * ITS Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 5 months

1
0
0 0

Persistent key storage ownership/access

by Quach, Brian

Hi, I see that keys can only be accessed/modified by their owning secure partition. File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1) Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3. However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work. Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the 32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver The file ID would not match what the App imported and the key would not be found. Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated? Another explanation of the scenario if the above was not clear: 1) NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2) NS application calls an AES crypto function and provides the key ID. 3) AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition. RoT Partition 1: - PSA Crypto (with keystore) RoT Partition 2: - AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators) RoT Partition 3: - ITS Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 5 months

1
0
0 0

TF-M v1.1 release

by Anton Komlev

Hello, Today, TF-M project released version v1.1, tagged by TF-Mv1.1<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.1>. Please take a look into Change Log<https://ci.trustedfirmware.org/view/TF-M/job/tf-m-nightly/lastStableBuild/a…> for the new features and changes. The next and further releases are expected in every 4 months. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M Technical lead Arm Ltd.

5 years, 5 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - July 9

by Summer Qin

Hi Anton, I'd like to give a brief introduction to SPRTL (Secure Partition Runtime Library) update. It will take no more than 30 minutes. Best Regards, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, July 3, 2020 10:44 AM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - July 9 Hi Anton, I’d like to give a brief introduction to Profile Medium design. It won’t take very long time. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, July 2, 2020 6:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - July 9 Hello, The next Technical Forum is planned on Thursday, July 9 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 5 months

2
1
0 0

C preprocessor directives issue for IAR linker

by Andrej Butok

Hello Tomas, I am trying to port TFM to IAR Embedded Workbench v8.50.5 IDE (NOT cmake) for LPC55S69. And have an error during linking in tfm\platform\ext\common\iar\tfm_common_s.icf on #include "region_defs.h": Error[Lc003]: expected ""check", "define", "do", "export", "if", "include", "initialize", "keep", "place", "reserve", or a placement label It can be fixed by changing: #include "region_defs.h" to: include "region_defs.h"; but it creates 44 Errors [Lc003] in region_defs.h, The IAR linker does not understand the C preprocessor directives like #ifndef, #ifdef, #endif etc. How did you solve this IAR issue? As we have to use IAR IDE (not cmake), what is your suggestion? Maybe a special IAR Linker preprocessing parameter/option? Thank you, Andrej Butok

5 years, 5 months

2
8
0 0

Call for review on TF-M HAL design

by Edison Ai

Hi All, Please review the design of the TF-M HAL: https://review.trustedfirmware.org/c/trusted-firmware-m/+/4076. This new design aims to make the TF-M more simple to integrate and porting to different platforms. The current version only includes the HAL API for the TF-M core, the HAL for Secure Partition will be the next step. Main Context: * There are 6 modules in the Core HAL: * Isolation API: Provides the necessary isolation functionalities required by the PSA FF and TBSA-M, and provides functions to SPM to check the validate of memory access. * Platform API: Provides the platform initial, receives platform data, system reset, etc. * Loader API: Provides the function to load partition and service and provides the necessary data to SPM. * Log dev API: Provides the log system functions. * Interrupt API: Provides the interrupt functions. * Debug API: Provides the debug functions. * There are some sequence diagrams that help you to more quick and easy the using of the new HAL. Main Change: There are some main changes to the TF-M core: * Move most of the platform data from Core to the platform and need tools to support it. * The platform needs to provide the required necessary memory to the Core for its runtime data using. * Load mode change. The platform needs to load the secure partition and provide the necessary info to the core. Please see the design for more details and welcome comments. BR, Edison

5 years, 5 months

1
2
0 0

Re: [TF-M] TF-M v1.1 - Heads up

by Anton Komlev

Hi All, New TF-Mv1.1-RC2 tag has been applied to all project repositories, marking fixes of issues found in RC1. The changes are small so only affected configurations will be retested. Best regards, Anton Komlev Tech Lead of TF-M in Arm Ltd. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 24 June 2020 18:16 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M v1.1 - Heads up Hi All, Both trusted-firmware-m and tf-m-tests repositories are tagged with TF-Mv1.1-RC1 tag marking the code freeze and beginning of the release candidate testing. Best regards, Anton Komlev Tech Lead of TF-M in Arm Ltd. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: 10 June 2020 18: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] TF-M v1.1 - Heads up Hi All, Just a heads up that TF-Mv1.1 tag is planned for middle to end of July. Code freeze of TF-M master is aimed around end of June to allow enough time for testing. Similar to TF-Mv1.0 and previous tags, v1.1 will include all TF-M changes in TF-M master available till code freeze in end of June. Availability of the tag will be notified via. this mailing list. Thanks, Shebu Technology Manager-TF-M, Arm Ltd.

5 years, 5 months

1
0
0 0

Re: [TF-M] f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds

by Jamie Fox

Hi Thomas, This is not expected. Please can you share the error that you see? (Might be best to open an issue on developer.trustedfirmware.org for it) Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 29 June 2020 16:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds Looks like f58bd227 breaks Musca_A builds, or at least it will not boot without additional configuration options. Is this expected? 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>

5 years, 5 months

2
3
0 0

Re: [TF-M] TF-M Technical Forum call - July 9

by David Hu

Hi Anton, I'd like to give a brief introduction to Profile Medium design. It won't take very long time. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, July 2, 2020 6:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - July 9 Hello, The next Technical Forum is planned on Thursday, July 9 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 5 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum Agenda - June 25

by Anton Komlev

The below mail was intended to arrive before previous Tech Forum but blocked because of big attachment. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 01 July 2020 13:39 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum Agenda - June 25 Hi, Please find the presentation materials attached for Secure functions topic. Reminder, the PSA L3 isolation design is here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730 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: 25 June 2020 13:38 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] TF-M Technical Forum Agenda - June 25 Hello, The agenda for today's forum: * PSA Isolation (level 3) design review * Secure Function model * Any other business, if time permitted. See you soon, 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: 17 June 2020 12:55 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] TF-M Technical Forum call - June 25 Hello, The next Technical Forum is planned on Thursday, June 25 at 15:00-16:00 UTC (US time zone). This is exceptional time zone change because of a public holiday in China that day. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 5 months

1
0
0 0

TF-M Technical Forum call - July 9

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, July 9 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 5 months

1
0
0 0

Re: [TF-M] [RFC] PSA Isolation (level 3) design document

by Ken Liu

Someone reported the previous mail is lost in their mailbox due to unknown reasons, let me re-send it. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, June 24, 2020 3:08 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] PSA Isolation (level 3) design document Hi, We have created one PSA Isolation implementation design document and now call for comments: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730 The overall goal is to cover all isolation levels into this one document, and at current stage we take level 3 as an example. The image layout and regions are based on the assumption of the existing TF-M code base. Feel free to put comments, or post under this task: https://developer.trustedfirmware.org/T778 Thanks. /Ken

5 years, 5 months

1
0
0 0

[RFC] TF-M Documentation Contribution Format

by Minos Galanakis

Hi, As the project matures, and the community grows, I would like to revive an old discussion and suggest that we set some guidelines for contributing to the project's documentation. I would like to propose that we establish a minimal sub-set of rules, based on the official Python guidelines<https://devguide.python.org/documenting/#style-guide> which is the most widely used notation. This offers compatibility with existing tools for proofing and producing said documentation. The following rules should be considered: 1. H1 document title headers should be expressed by # with over-line (rows on top and bottom) of the text 2. Only ONE H1 header should allowed per document, ideally placed on top of the page. 3. H2 headers should be expressed by * with over-line 4. H2 header's text should be UNIQUE in per document basis 5. H3 headers should be expressed by a row of '=' 6. H4 headers should be expressed by a row of '-' 7. H3 and H4 headers have no limitation about naming. They can have similar names on the same document, as long as they have different parents. 8. H5 headers should be expressed by a row of '^' 9. H5 headers will be rendered in document body but not in menus on the navigation bar. 10. Do not use more than 5 level of heading 11. When writing guide, which are expected to be able to be readable by command line tools, it would be best practice to add long complicated tables, and UML diagrams in the bottom of the page and using internal references(auto-label). Please refer to the `tfm_sw_requirement.rst<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getti…>` as an example 12. No special formatting should be allowed in Headers ( code, underline, strike-through etc ) 13. Long URLs and external references should be placed at the bottom of the page and referenced in the body of the document 14. New introduced terms and abbreviations should be added to Glossary and directly linked by the `:term:` notation across all documents using it. When something new, which is not covered is required, the rule should be first to follow the any reference to of an existing document, and the Python Documentation rules otherwise. Please let me know if you have any questions/objection or proposals or new rules you would like to consider. Any feedback is more than welcome. Minos

5 years, 5 months

1
0
0 0

New TrustedFirmware.org security incident process is now live

by Dan Handley

Hi all The new TrustedFirmware.org security incident process is now live. This process is described here: https://developer.trustedfirmware.org/w/collaboration/security_center/repor… Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change. If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here: https://developer.trustedfirmware.org/w/collaboration/security_center/trust… Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. Best regards Dan. (on behalf of the TrustedFirmware.org security team)

5 years, 5 months

1
0
0 0

[RFC] Profile Medium design document

by David Hu

Hi all, Profile Medium design document has been uploaded for review on https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4775. I'd like to ask for review and comment. Any suggestion is welcome. Thanks in advance for any help. As part of TF-M Profiles, Profile Medium aims to connect devices to cloud services with asymmetric cipher support. Compared to Profile Small, Profile Medium contains more combabilities and requires more resource. Best regards, Hu Ziji

5 years, 5 months

1
0
0 0

Re: [TF-M] f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds

by Thomas Törnblom

Build steps: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\configs\ConfigRegressionIPC.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=GNUARM -DCMAKE_BUILD_TYPE=Debug PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\cmake_build_gcc> ..\flash_musca.bat C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\cmake_build_gcc>srec_cat bl2/ext/mcuboot/mcuboot.bin -Binary -offset 0x200000 tfm_sign.bin -Binary -offset 0x220000 -o tfm.hex -Intel C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\cmake_build_gcc>xcopy tfm.hex g: C:tfm.hex --- terminal output: Adding "-DPS_RAM_FS=ON -DITS_RAM_FS=ON" to the cmake line makes it work again, but I assume that should not be needed. Thomas Den 2020-06-29 kl. 18:58, skrev Thomas Törnblom via TF-M: > I’ve tried with GNUARM, ARMCLANG and IARARM on Win 10. > > I builds fine, but the boot appears to get stuck when starting the > secure image. > > I can provide the exact terminal output tomorrow. > > Thomas > > *Thomas Törnblom*, /Product Engineer/ > IAR Systems AB > Box 23051, Strandbodgatan 1 <x-apple-data-detectors://6/1> > SE-750 23 Uppsala, SWEDEN <x-apple-data-detectors://6/1> > Mobile: +46 76 180 17 80 <tel:+46%2076%20180%2017%2080> Fax: +46 18 16 > 78 01 <tel:+46%2018%2016%2078%2001> > 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> > >> 29 juni 2020 kl. 18:02 skrev Jamie Fox <Jamie.Fox(a)arm.com>: >> >> >> >> Hi Thomas, >> >> This is not expected. Please can you share the error that you see? >> (Might be best to open an issue on developer.trustedfirmware.org for it) >> >> Kind regards, >> >> Jamie >> >> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of >> *Thomas Törnblom via TF-M >> *Sent:* 29 June 2020 16:38 >> *To:* tf-m(a)lists.trustedfirmware.org >> *Subject:* [TF-M] f58bd227, Build: Disable RAM FS by default, breaks >> Musca_A builds >> >> Looks like f58bd227 breaks Musca_A builds, or at least it will not >> boot without additional configuration options. >> >> Is this expected? >> >> 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> >> > -- *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>

5 years, 5 months

1
0
0 0

f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds

by Thomas Törnblom

Looks like f58bd227 breaks Musca_A builds, or at least it will not boot without additional configuration options. Is this expected? 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>

5 years, 5 months

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Kumar Gala

I think I found the issue in cmake/Compiler/GNUARM.cmake not handling “.exe” correctly. Try: diff --git a/cmake/Compiler/GNUARM.cmake b/cmake/Compiler/GNUARM.cmake index fc9db7a0..8fbd97bb 100644 --- a/cmake/Compiler/GNUARM.cmake +++ b/cmake/Compiler/GNUARM.cmake @@ -18,6 +18,7 @@ set(CMAKE_EXECUTABLE_SUFFIX ".axf") if(NOT DEFINED GNUARM_PREFIX) get_filename_component(__c_bin ${CMAKE_C_COMPILER} NAME) string(REPLACE "-gcc" "" GNUARM_PREFIX ${__c_bin}) + string(REPLACE ".exe" "" GNUARM_PREFIX ${GNUARM_PREFIX}) endif() Will work up a proper change if that tests out ok. - k > On Jun 26, 2020, at 7:40 AM, Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Thanks Anton, > > I worked around it with: > > git rebase 7946bdd3 --onto 7946bdd3^ > > Cheers, > Thomas > > Den 2020-06-26 kl. 14:30, skrev Anton Komlev via TF-M: >> Thanks, Thomas. >> >> Yes, it was noted right after RC1 applied. The problem affects the build (not code) on Windows platform only. >> While waiting for the fix we do continue tests using Linux build. >> A fix will be applied or the patch reverted before TF-M release or with RC2, if happen. >> >> Cheers, >> Anton >> >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M >> Sent: 26 June 2020 09:23 >> To: DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> >> Subject: [TF-M] Build issues with GNUARM with 7946bdd3 >> >> The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. >> >> [100%] Linking C static library mbedcrypto.a >> /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found >> make[5]: *** [library/mbedcrypto.a] Fel 127 >> make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 >> make[3]: *** [all] Fel 2 >> make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 >> make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 >> make: *** [all] Fel 2 >> >> Excluding this commit is a workaround. >> >> This is on Win 10. >> >> Cheers, >> 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 Website: www.iar.com >> Twitter: www.twitter.com/iarsystems >> >> > > -- > > 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 Website: www.iar.com > Twitter: www.twitter.com/iarsystems > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Alignment issues on stack with ITS

by Jamie Fox

Hi Thomas, It is only the size of the struct that needs to be aligned to the flash program unit, so that the write size is aligned when the struct is programmed to flash. So indeed the attribute puts too strong a constraint on the compiler as it also forces it to allocate these structs at aligned addresses on the stack. The only vaguely clean, portable way I can think of aligning up the size of the struct alone is something like: struct its_file_meta_t_padded { struct its_file_meta_t file_meta; uint8_t pad[ITS_FLASH_MAX_ALIGNMENT - (sizeof(struct its_file_meta_t) % ITS_FLASH_MAX_ALIGNMENT)]; }; But that has the disadvantage of adding ITS_FLASH_MAX_ALIGNMENT to the size of the struct in the case that it is already aligned (no zero-sized arrays), as well as the extra step of accessing the nested struct each time. Would be happy to hear any alternative solutions though. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 26 June 2020 10:07 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Alignment issues on stack with ITS ITS defines a few structs with specific alignment requirements, like: struct __attribute__((__aligned__(ITS_FLASH_MAX_ALIGNMENT))) its_file_meta_t { uint32_t lblock; /*!< Logical datablock where file is * stored */ size_t data_idx; /*!< Offset in the logical data block */ size_t cur_size; /*!< Size in storage system for this # * fragment */ size_t max_size; /*!< Maximum size of this file */ uint32_t flags; /*!< Flags set when the file was created */ uint8_t id[ITS_FILE_ID_SIZE]; /*!< ID of this file */ }; This causes issues with the IAR compiler when these structs are declared as autos: static psa_status_t its_mblock_copy_remaining_block_meta( struct its_flash_fs_ctx_t *fs_ctx, uint32_t lblock) { struct its_block_meta_t block_meta; psa_status_t err; uint32_t meta_block; size_t pos; uint32_t scratch_block; size_t size; ... The IAR compiler gives these errors if the alignment is 0x10 (the stack is 8 byte aligned): struct its_block_meta_t block_meta; ^ "C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\secure_fw\partitions\internal_trusted_storage\flash_fs\its_flash_fs_mblock.c",415 Error[Ta121]: Auto variable "block_meta" cannot have a stricter alignment than the stack I assume this alignment is only required for the flash, so the alignment attributes should be set when declaring variables in the flash, not on the type. Comments? Cheers, 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Thomas Törnblom

Thanks Anton, I worked around it with: git rebase 7946bdd3 --onto 7946bdd3^ Cheers, Thomas Den 2020-06-26 kl. 14:30, skrev Anton Komlev via TF-M: > > Thanks, Thomas. > > Yes, it was noted right after RC1 applied. The problem affects the > build (not code) on Windows platform only. > > While waiting for the fix we do continue tests using Linux build. > > A fix will be applied or the patch reverted before TF-M release or > with RC2, if happen. > > Cheers, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Thomas Törnblom via TF-M > *Sent:* 26 June 2020 09:23 > *To:* DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> > *Subject:* [TF-M] Build issues with GNUARM with 7946bdd3 > > The merge of "Build: Add support for specifying GNUARM_PREFIX" appears > to break GNUARM builds. > > [100%] Linking C static library mbedcrypto.a > /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found > make[5]: *** [library/mbedcrypto.a] Fel 127 > make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 > make[3]: *** [all] Fel 2 > make[2]: *** > [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] > Fel 2 > make[1]: *** > [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 > make: *** [all] Fel 2 > > Excluding this commit is a workaround. > > This is on Win 10. > > Cheers, > 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> > > -- *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>

5 years, 6 months

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Anton Komlev

Thanks, Thomas. Yes, it was noted right after RC1 applied. The problem affects the build (not code) on Windows platform only. While waiting for the fix we do continue tests using Linux build. A fix will be applied or the patch reverted before TF-M release or with RC2, if happen. Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 26 June 2020 09:23 To: DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Build issues with GNUARM with 7946bdd3 The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. [100%] Linking C static library mbedcrypto.a /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found make[5]: *** [library/mbedcrypto.a] Fel 127 make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 make[3]: *** [all] Fel 2 make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 make: *** [all] Fel 2 Excluding this commit is a workaround. This is on Win 10. Cheers, 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Kumar Gala

> On Jun 26, 2020, at 3:23 AM, Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. > > [100%] Linking C static library mbedcrypto.a > /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found > make[5]: *** [library/mbedcrypto.a] Fel 127 > make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 > make[3]: *** [all] Fel 2 > make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 > make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 > make: *** [all] Fel 2 > > Excluding this commit is a workaround. > > This is on Win 10. > > Cheers, > Thomas Is this issue seen on any other host OS? Linux, Mac OS X? Which specific toolchain are you using? - k

5 years, 6 months

2
1
0 0

Alignment issues on stack with ITS

by Thomas Törnblom

ITS defines a few structs with specific alignment requirements, like: struct __attribute__((__aligned__(ITS_FLASH_MAX_ALIGNMENT))) its_file_meta_t { uint32_t lblock; /*!< Logical datablock where file is * stored */ size_t data_idx; /*!< Offset in the logical data block */ size_t cur_size; /*!< Size in storage system for this # * fragment */ size_t max_size; /*!< Maximum size of this file */ uint32_t flags; /*!< Flags set when the file was created */ uint8_t id[ITS_FILE_ID_SIZE]; /*!< ID of this file */ }; This causes issues with the IAR compiler when these structs are declared as autos: static psa_status_t its_mblock_copy_remaining_block_meta( struct its_flash_fs_ctx_t *fs_ctx, uint32_t lblock) { struct its_block_meta_t block_meta; psa_status_t err; uint32_t meta_block; size_t pos; uint32_t scratch_block; size_t size; ... The IAR compiler gives these errors if the alignment is 0x10 (the stack is 8 byte aligned): struct its_block_meta_t block_meta; ^ "C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\secure_fw\partitions\internal_trusted_storage\flash_fs\its_flash_fs_mblock.c",415 Error[Ta121]: Auto variable "block_meta" cannot have a stricter alignment than the stack I assume this alignment is only required for the flash, so the alignment attributes should be set when declaring variables in the flash, not on the type. Comments? Cheers, 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>

5 years, 6 months

1
0
0 0

Build issues with GNUARM with 7946bdd3

by Thomas Törnblom

The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. [100%] Linking C static library mbedcrypto.a /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found make[5]: *** [library/mbedcrypto.a] Fel 127 make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 make[3]: *** [all] Fel 2 make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 make: *** [all] Fel 2 Excluding this commit is a workaround. This is on Win 10. Cheers, 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum Agenda - June 25

by Anton Komlev

Hi, Please find the presentation materials attached for Secure functions topic. Reminder, the PSA L3 isolation design is here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730 The best, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 25 June 2020 13:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum Agenda - June 25 Hello, The agenda for today's forum: * PSA Isolation (level 3) design review * Secure Function model * Any other business, if time permitted. See you soon, 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: 17 June 2020 12:55 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] TF-M Technical Forum call - June 25 Hello, The next Technical Forum is planned on Thursday, June 25 at 15:00-16:00 UTC (US time zone). This is exceptional time zone change because of a public holiday in China that day. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum Agenda - June 25

by Anton Komlev

Hello, The agenda for today's forum: * PSA Isolation (level 3) design review * Secure Function model * Any other business, if time permitted. See you soon, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 17 June 2020 12:55 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - June 25 Hello, The next Technical Forum is planned on Thursday, June 25 at 15:00-16:00 UTC (US time zone). This is exceptional time zone change because of a public holiday in China that day. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Re: [TF-M] new tf-m-test repository

by Kumar Gala

Curious if the intent is that the tf-m-tests repo would eventually be optional? - k > On Jun 19, 2020, at 5:29 AM, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo > The intention is to migrate testing related code/libraries/tools there and clean the main repository. > Patches have been made. Please be aware of the change. > At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo. > > Thanks, > Anton Komlev > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

Re: [TF-M] TF-M v1.1 - Heads up

by Anton Komlev

Hi All, Both trusted-firmware-m and tf-m-tests repositories are tagged with TF-Mv1.1-RC1 tag marking the code freeze and beginning of the release candidate testing. Best regards, Anton Komlev Tech Lead of TF-M in Arm Ltd. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: 10 June 2020 18:28 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M v1.1 - Heads up Hi All, Just a heads up that TF-Mv1.1 tag is planned for middle to end of July. Code freeze of TF-M master is aimed around end of June to allow enough time for testing. Similar to TF-Mv1.0 and previous tags, v1.1 will include all TF-M changes in TF-M master available till code freeze in end of June. Availability of the tag will be notified via. this mailing list. Thanks, Shebu Technology Manager-TF-M, Arm Ltd.

5 years, 6 months

1
0
0 0

Switch to the original MCUboot as default

by David Vincze

Hi everyone, I would like to inform you about that the default bootloader option in TF-M has been changed from TF-M's MCUBoot fork to the original MCUBoot by a commit that was merged a few hours ago (https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4551). Due to this you may experience that your TF-M builds are failing after a recent rebase onto master with the following error message: "Missing MCUBoot. Please clone the MCUBoot repo to directory....." . To solve this, you can choose from the following options: 1. Follow the instructions of the 'MCUBoot' section in the docs/getting_started/tfm_secure_boot.rst to clone the MCUBoot repository and fulfill this dependency. 2. Quick but rather temporary solution: Append '-DMCUBOOT_REPO=TF-M' to your CMake configuration command to use the MCUBoot fork from the TF-M repository as before. Example: cmake -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=ARMCLANG -DMCUBOOT_REPO=UPSTREAM ../ Please let me know, if you have any difficulties. Best regards, David Vincze

5 years, 6 months

1
0
0 0

[RFC] PSA Isolation (level 3) design document

by Ken Liu

Hi, We have created one PSA Isolation implementation design document and now call for comments: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730 The overall goal is to cover all isolation levels into this one document, and at current stage we take level 3 as an example. The image layout and regions are based on the assumption of the existing TF-M code base. Feel free to put comments, or post under this task: https://developer.trustedfirmware.org/T778 Thanks. /Ken

5 years, 6 months

1
0
0 0

Re: [TF-M] MPU Fault Handler in the 'Test secure irq' test

by Andrej Butok

Hi Mate, Thank you for the confirmation. To avoid the limitation, I have switched the IRQ test service to PSA-RoT in our code. Should the original TFM do the same? Thank you, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: Tuesday, June 23, 2020 1:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] MPU Fault Handler in the 'Test secure irq' test Hi Andrej, Yes, this is a known limitation of the IRQ test case. Because of the limitation you mention in your mail it cannot be run in isolation levels higher than 1. This test is part of the core test positive test suite, which is (by default) is disabled in certain cases (mostly because of these limitations): CommonConfig.cmake: if (CORE_TEST) if (NOT CORE_IPC OR TFM_LVL EQUAL 1) set(CORE_TEST_POSITIVE ON) endif() set(CORE_TEST_INTERACTIVE OFF) endif() It might be a possible workaround to define the IRQ test service as a PRoT as well. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: Monday, June 22, 2020 16:45 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] MPU Fault Handler in the 'Test secure irq' test Hello, During my update to the new TFM version (after one month pause), occurs the MPU Fault Handler in the 'Test secure irq' regression test (TFM_ENABLE_IRQ_TEST is enabled). The reason is that the test partition is defined as APP_ROT (non-privileged), but the test accesses to the NS memory region (dined as Privileged by default): spm_irq_test_1_prepare_test_scenario_internal(enum irq_test_scenario_t irq_test_scenario, struct irq_test_execution_data_t *execution_data) "execution_data" points to a global structure in NS RAM area provided by the NS test. The workaround: Define the IRQ test partition as PSA_ROT (privileged). Is it OK? Is this known issue? Thanks, Andrej Butok

5 years, 6 months

1
0
0 0

Re: [TF-M] MPU Fault Handler in the 'Test secure irq' test

by Mate Toth-Pal

Hi Andrej, Yes, this is a known limitation of the IRQ test case. Because of the limitation you mention in your mail it cannot be run in isolation levels higher than 1. This test is part of the core test positive test suite, which is (by default) is disabled in certain cases (mostly because of these limitations): CommonConfig.cmake: if (CORE_TEST) if (NOT CORE_IPC OR TFM_LVL EQUAL 1) set(CORE_TEST_POSITIVE ON) endif() set(CORE_TEST_INTERACTIVE OFF) endif() It might be a possible workaround to define the IRQ test service as a PRoT as well. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, June 22, 2020 16:45 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] MPU Fault Handler in the 'Test secure irq' test Hello, During my update to the new TFM version (after one month pause), occurs the MPU Fault Handler in the 'Test secure irq' regression test (TFM_ENABLE_IRQ_TEST is enabled). The reason is that the test partition is defined as APP_ROT (non-privileged), but the test accesses to the NS memory region (dined as Privileged by default): spm_irq_test_1_prepare_test_scenario_internal(enum irq_test_scenario_t irq_test_scenario, struct irq_test_execution_data_t *execution_data) "execution_data" points to a global structure in NS RAM area provided by the NS test. The workaround: Define the IRQ test partition as PSA_ROT (privileged). Is it OK? Is this known issue? Thanks, Andrej Butok

5 years, 6 months

1
0
0 0

MPU Fault Handler in the 'Test secure irq' test

by Andrej Butok

Hello, During my update to the new TFM version (after one month pause), occurs the MPU Fault Handler in the 'Test secure irq' regression test (TFM_ENABLE_IRQ_TEST is enabled). The reason is that the test partition is defined as APP_ROT (non-privileged), but the test accesses to the NS memory region (dined as Privileged by default): spm_irq_test_1_prepare_test_scenario_internal(enum irq_test_scenario_t irq_test_scenario, struct irq_test_execution_data_t *execution_data) "execution_data" points to a global structure in NS RAM area provided by the NS test. The workaround: Define the IRQ test partition as PSA_ROT (privileged). Is it OK? Is this known issue? Thanks, Andrej Butok

5 years, 6 months

1
0
0 0

Re: [TF-M] new tf-m-test repository

by Kevin Peng

Hi Thomas, Should be review.trustedfirmware.org/c/TF-M/tf-m-tests Just replace "trusted-firmware-m" with "tf-m-tests" in the URL you push patches for TF-M. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Monday, June 22, 2020 3:36 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] new tf-m-test repository What is the URL to push patches to this repo? I attempted to push the IAR RTX libraries but it failed. Cheers, Thomas Den 2020-06-19 kl. 12:29, skrev Anton Komlev via TF-M: Hi, Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> The intention is to migrate testing related code/libraries/tools there and clean the main repository. Patches have been made. Please be aware of the change. At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo. Thanks, Anton Komlev -- 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>

5 years, 6 months

2
1
0 0

Re: [TF-M] new tf-m-test repository

by Thomas Törnblom

What is the URL to push patches to this repo? I attempted to push the IAR RTX libraries but it failed. Cheers, Thomas Den 2020-06-19 kl. 12:29, skrev Anton Komlev via TF-M: > > Hi, > > Following TF-M project restructuring, let me bring your attention to > the new repository: *tf-m-tests* repo > <https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> > > The intention is to migrate testing related code/libraries/tools there > and clean the main repository. > > Patches have been made. Please be aware of the change. > > At this moment it does not affect the project development but in the > future to test TF-M you will need to use this tf-m-tests repo. > > Thanks, > > Anton Komlev > > -- *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>

5 years, 6 months

1
0
0 0

Re: [TF-M] Ask for final review of symmetric based initial attestation design

by David Hu

Hi all, Symmetric initial attestation patches are merged. Symmetric initial attestation now is enabled in TF-M Profile Small. Thanks a lot for the review and support. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, May 18, 2020 3:34 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Ask for final review of symmetric based initial attestation design Hi all, May I ask for a final round of review on symmetric initial attestation design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3898? The document has been reviewed for a long time and received many valuable comments. Thanks a lot. If there is no further critical comment, I'd like to merge this design this Friday. Best regards, Hu Ziji

5 years, 6 months

1
0
0 0

Re: [TF-M] new tf-m-test repository

by Kevin Peng

Thanks Anton. As you may have noticed, the CMSIS RTX libraries have been added to the tf-m-tests. There are also patches<https://review.trustedfirmware.org/q/topic:%22CMSIS_5_to_tfm_tests%22+(stat…> for TF-M to reference the libraries from tf-m-tests. The plan is to merge them before TF-M 1.1 release code freeze (around end of June). You would need to clone the tf-m-tests repo to build TF-M when these patches were merged. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, June 19, 2020 6:30 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] new tf-m-test repository Hi, Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> The intention is to migrate testing related code/libraries/tools there and clean the main repository. Patches have been made. Please be aware of the change. At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo. Thanks, Anton Komlev

5 years, 6 months

1
0
0 0

new tf-m-test repository

by Anton Komlev

Hi, Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> The intention is to migrate testing related code/libraries/tools there and clean the main repository. Patches have been made. Please be aware of the change. At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo. Thanks, Anton Komlev

5 years, 6 months

1
0
0 0

Documenting Release cadence and process

by Soby Mathew

Hi Everyone I have pushed the proposal for release cadence and process for here : https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4635 This mainly follows the TF-A release process. The release cadence period is set to be 4 months with a code freeze of up to 3 weeks. Best Regards Soby Mathew

5 years, 6 months

1
0
0 0

Re: [TF-M] PS => AP ROT

by Jamie Fox

Hi Andrej, The PSA Storage spec (available here https://developer.arm.com/architectures/security-architectures/platform-sec…) states that the Protected Storage service should be implemented inside the Application Root of Trust. The principle is that the PSA Root of Trust should be kept as small as possible, to reduce the attack surface of the most privileged part of the system. As Protected Storage neither needs the privileges of the PSA Root of Trust nor is used by any PSA Root of Trust service, it should be implemented inside the Application Root of Trust. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 18 June 2020 09:16 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PS => AP ROT Hello, I have just notices that the TFM Protected Storage service partition has been changed from PSA ROT to APP ROT. Just curious, what is a reason? May it stay PSA ROT? Thank you in advance, Andrej Butok

5 years, 6 months

2
1
0 0

PS => AP ROT

by Andrej Butok

Hello, I have just notices that the TFM Protected Storage service partition has been changed from PSA ROT to APP ROT. Just curious, what is a reason? May it stay PSA ROT? Thank you in advance, Andrej Butok

5 years, 6 months

1
0
0 0

TF-M Technical Forum call - June 25

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, June 25 at 15:00-16:00 UTC (US time zone). This is exceptional time zone change because of a public holiday in China that day. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Re: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE

by Andrej Butok

Hi Tamas, > I do not know whether the this two phase setting of MSP_LIMIT is still in use or not. If not the no need for S_MSP_STACK_SIZE_INIT. The only place where it's used is the GCC linker file: __msp_init_stack_size__ = S_MSP_STACK_SIZE_INIT So for GCC __msp_init_stack_size__ is in 2 times less (0x400) than for Keil and IAR (0x800) "__msp_init_stack_size__ = S_MSP_STACK_SIZE". From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Tuesday, June 16, 2020 10:17 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE Hi Andrej, The BOOT_TFM_SHARED_DATA and the MSP_STACK area are overlapping on purpose. The partitions which are expecting to receive data from bootloader is intended to get their own data during the partition init phase with calling tfm_core_get_boot_data() with the partition's major_type. Then the data will be copied from shared area to partition's memory. So after all partition's init is executed then the data from the shared buffer is distributed to the owning partitions and resides in their memory. At this point the shared_data area can be overwritten by growing MSP, without destroying shared data. Originally there was an S_MSP_STACK_SIZE_INIT size which was used to setup the MSP_LIMIT for the init phase to avoid overwriting the shared data area. After the init phase the MSP_LIMIT was set again with its full size S_MSP_STACK_SIZE. I do not know whether the this two phase setting of MSP_LIMIT is still in use or not. If not the no need for S_MSP_STACK_SIZE_INIT. +-> +-> +--------------+ <- Shared boot data base, S_MSP_STACK_SIZE | Shared| | | M | Data | | | S | | | | P | +-> +--------------+ <- S_MSP_STACK_SIZE_INIT | | | | | | | | | +-> +--------------+ <- Top of MSP Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 16 June 2020 09:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE Hello, What is a difference between S_MSP_STACK_SIZE_INIT and S_MSP_STACK_SIZE defined in partition\region_defs.h: #define S_MSP_STACK_SIZE_INIT (0x0000400) #define S_MSP_STACK_SIZE (0x0000800) S_MSP_STACK_SIZE_INIT is used only for gcc. S_MSP_STACK_SIZE is used for armclang and iar. Guess, it should be used only one definition. So in our platform code we are going to use only S_MSP_STACK_SIZE. Should you fix it for all platforms in the original TFM? Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

5 years, 6 months

1
0
0 0

Re: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE

by Tamas Ban

Hi Andrej, The BOOT_TFM_SHARED_DATA and the MSP_STACK area are overlapping on purpose. The partitions which are expecting to receive data from bootloader is intended to get their own data during the partition init phase with calling tfm_core_get_boot_data() with the partition's major_type. Then the data will be copied from shared area to partition's memory. So after all partition's init is executed then the data from the shared buffer is distributed to the owning partitions and resides in their memory. At this point the shared_data area can be overwritten by growing MSP, without destroying shared data. Originally there was an S_MSP_STACK_SIZE_INIT size which was used to setup the MSP_LIMIT for the init phase to avoid overwriting the shared data area. After the init phase the MSP_LIMIT was set again with its full size S_MSP_STACK_SIZE. I do not know whether the this two phase setting of MSP_LIMIT is still in use or not. If not the no need for S_MSP_STACK_SIZE_INIT. +-> +-> +--------------+ <- Shared boot data base, S_MSP_STACK_SIZE | Shared| | | M | Data | | | S | | | | P | +-> +--------------+ <- S_MSP_STACK_SIZE_INIT | | | | | | | | | +-> +--------------+ <- Top of MSP Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 16 June 2020 09:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE Hello, What is a difference between S_MSP_STACK_SIZE_INIT and S_MSP_STACK_SIZE defined in partition\region_defs.h: #define S_MSP_STACK_SIZE_INIT (0x0000400) #define S_MSP_STACK_SIZE (0x0000800) S_MSP_STACK_SIZE_INIT is used only for gcc. S_MSP_STACK_SIZE is used for armclang and iar. Guess, it should be used only one definition. So in our platform code we are going to use only S_MSP_STACK_SIZE. Should you fix it for all platforms in the original TFM? Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

5 years, 6 months

1
0
0 0

S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE

by Andrej Butok

Hello, What is a difference between S_MSP_STACK_SIZE_INIT and S_MSP_STACK_SIZE defined in partition\region_defs.h: #define S_MSP_STACK_SIZE_INIT (0x0000400) #define S_MSP_STACK_SIZE (0x0000800) S_MSP_STACK_SIZE_INIT is used only for gcc. S_MSP_STACK_SIZE is used for armclang and iar. Guess, it should be used only one definition. So in our platform code we are going to use only S_MSP_STACK_SIZE. Should you fix it for all platforms in the original TFM? Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

5 years, 6 months

1
0
0 0

Crypto code sharing b/w MCUboot and SPE

by Tamas Ban

Hi, This design addressing to share the code of the common crypto primitives(SHA256, RSA, later AES) between MCUboot and runtime SPE. The goal is to reduce the flash footprint of SPE. Design proposal: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4587 Implementation: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4583/ TL;DR: SPE binary size can be reduced with 10KB. If image encryption will be turned on then ~12-13KB is the gain. Please let us know if you think this improvements would be useful. @Thomas Törnblom<mailto:thomas.tornblom@iar.com>: Could you check the porting to IAR toolchain? BR, Tamas Ban

5 years, 6 months

1
0
0 0

STM32 support in trutedfirmware

by Michel JAOUEN

Hello, The support of the STM32 boards ( stm32l562e_dk and nucleo_l552ze_q) is now merged in trustedfirmware. Best regards Michel JAOUEN

5 years, 6 months

1
0
0 0

Renaming SST(Secure STorage) to PS(Protected Storage) has been done

by Kevin Peng

Hi all, The patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3597> of Renaming SST(Secure STorage) to PS(Protected Storage) has been merged. This could have some impacts on your working environments and your work ongoing. As you have noticed, a new supported platform was missed during the renaming. (Quick fix<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4562> has been done.) Please do have a check and report any more issues you find, thanks very much. Best Regards, Kevin

5 years, 6 months

1
0
0 0

Re: [TF-M] Does FVP_SSE300_MPS2 target build?

by Jamie Fox

Hi Thomas, My bad, I merged a patch today that broke it. The fix is here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4562. I will merge it once the CI has verified it. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 12 June 2020 14:00 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Does FVP_SSE300_MPS2 target build? I just noticed the merge of the FVP_SSE300_MPS2 support and I'm trying to build, but it fails with: --- [ 23%] Building C object test/secure_test/CMakeFiles/tfm_secure_tests.dir/suites/ps/secure/psa_ps_s_interface_testsuite.o C:/Users/thomasto/Projects/tf-m1/trusted-firmware-m/test/suites/ps/secure/psa_ps_s_interface_testsuite.c:46:39: error: use of undeclared identifier 'PS_MAX_ASSET_SIZE' static const uint8_t write_asset_data[PS_MAX_ASSET_SIZE] = {0xBF}; ... --- Known issue? 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>

5 years, 6 months

2
1
0 0

Does FVP_SSE300_MPS2 target build?

by Thomas Törnblom

I just noticed the merge of the FVP_SSE300_MPS2 support and I'm trying to build, but it fails with: --- [ 23%] Building C object test/secure_test/CMakeFiles/tfm_secure_tests.dir/suites/ps/secure/psa_ps_s_interface_testsuite.o C:/Users/thomasto/Projects/tf-m1/trusted-firmware-m/test/suites/ps/secure/psa_ps_s_interface_testsuite.c:46:39: error: use of undeclared identifier 'PS_MAX_ASSET_SIZE' static const uint8_t write_asset_data[PS_MAX_ASSET_SIZE] = {0xBF}; ... --- Known issue? 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] CMake flags

by Kumar Gala

Zephyr uses DT as a means to describe the hardware to the system for things like register address, irq numbers, etc. Instead of the typical runtime usage, it generates code to be used at build time for Cortex-M (and other) devices to address the size cost concern. On the KConfig side Zephyr uses a python implementation of the KConfig parser to allow portability across host build systems. - k > On Jun 12, 2020, at 4:35 AM, Gyorgy Szing via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Just some minor additions. In the TF-M build system Kconfig will most likely generate input for cmake scripts, so the compiler may not have a connection to it. > > The original intention with DT is capturing configuration data to allow hardware independent binaries (for defining base address of peripherals, boot information, etc..), and is mostly parsed runtime. In the Cortex-M space this might be a bit out-of scope. Most likely it will be used as a “standard” language to define “retargeting” information, and a tool will be developed which runs compile time and which allows access to the retargeting data for cmake. Something like CMSIS zone, but closer to established open-source technologies. > In multicore systems having bot Cortex-A and M core DT would allow having a consistent solution for both A and M firmware. This is also a reason why cmake is a better build solution for TF-M than CMSIS Build. > > /George > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M > Sent: 12 June 2020 11:16 > 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] CMake flags > > Hi Thomas, > > DT is another very attractive topic. TF-M currently doesn’t include any DT support. > So maybe there is mixed preprocessing of DT and Kconfig in Zephyr, but Kconfig can be parsed without any compiler. > > Best regards, > Hu Ziji > > From: Thomas Törnblom <thomas.tornblom(a)iar.com> > Sent: Friday, June 12, 2020 5:09 PM > To: David Hu <David.Hu(a)arm.com>; tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] CMake flags > > Perhaps I'm mixing dts and Kconfig up. > > In Zephyr, dtc is used to generate output that is run through the gcc preprocessor in assembly mode. > > The output from dtc looks like: > --- > /dts-v1/; > > / { > ï¿½ï¿½ï¿½ #address-cells = < 0x1 >; > ï¿½ï¿½ï¿½ #size-cells = < 0x1 >; > ï¿½ï¿½ï¿½ model = "STMicroelectronics STM32F746G DISCOVERY board"; > ï¿½ï¿½ï¿½ compatible = "st,stm32f746g-disco", "st,stm32f746"; > ï¿½ï¿½ï¿½ chosen { > ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,console = &usart1; > ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,shell-uart = &usart1; > ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,sram = &sram0; > ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,flash = &flash0; > ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,dtcm = &dtcm; > ï¿½ï¿½ï¿½ }; > ... > --- > > Our preprocessor can not be run in assembler mode and it pukes on the "#address-cells" type elements in the file. > > If this is not what Kconfig is about, then please ignore my comments. > > Thomas > > Den 2020-06-12 kl. 09:43, skrev David Hu: > Hi Thomas, > ï¿½ > Iï¿½ve not met such a problem yet. Could you please give more details about the portability issues in Kconfig? > In our PoC, it firstly parses the Kconfig files and then convert the output Kconfig options into CMake flags. Thus the whole process is not related to any compiler. > I checked Zephyr previously. It looks like Zephyr has the similar idea as our PoC does. > ï¿½ > Best regards, > Hu Ziji > ï¿½ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Tï¿½rnblom via TF-M > Sent: Friday, June 12, 2020 3:36 PM > To: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] CMake flags > ï¿½ > Introducing a dependency on Kconfig may cause portability issues with some toolchains (IAR for instance) > > I am working on adding support for the IAR toolchain to Zephyr, and Kconfig is one of the issues I've run into. > > At least in Zephyr, the output from Kconfig is run through the C preprocessor and this causes issues with the IAR preprocessor so for now I use gcc for this step. > > Thomas > > Den 2020-06-12 kl. 07:32, skrev David Hu via TF-M: > Hi Adrian, > ï¿½ > Actually we have been investigating configuration alternatives and making some prototypes of Kconfig. > ï¿½ > Kconfig can bring some advantages: > • It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. > • Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system. > ï¿½ > But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig. > ï¿½ > Best regards, > Hu Ziji > ï¿½ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M > Sent: Friday, June 12, 2020 12:24 AM > To: Raef Coles <Raef.Coles(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] CMake flags > ï¿½ > Hi Raef. Thanks for the presentation today. > ï¿½ > If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed. > ï¿½ > From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help? > ï¿½ > Adrian > ï¿½ > > ï¿½ > -- > > 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 Website: www.iar.com > Twitter: www.twitter.com/iarsystems > > -- > > 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 Website: www.iar.com > Twitter: www.twitter.com/iarsystems > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] CMake flags

by Rønningstad, Øyvind

Note that Zephyr has a Cmake function that does this exact thing, if you're interested: https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/extensions.c… Øyvind Rønningstad -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Friday, June 12, 2020 11:45 To: Raef Coles <Raef.Coles(a)arm.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CMake flags Hi Raef, My current prototype is to parse the options from Kconfig output file and "inject" them into CMake (by set()) in a CMake file running at the beginning of build process. Kconfig generation is an optional step before build starts, only if you request to change the configuration. Otherwise, build just starts with previous Kconfig output config as normal. Best regards, Hu Ziji -----Original Message----- From: Raef Coles <Raef.Coles(a)arm.com> Sent: Friday, June 12, 2020 5:34 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; David Hu <David.Hu(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: CMake flags I think I'd advocate for using a workflow of generating a cfg.cmake file from the kconfig, instead of a txt file with an associated cmake parser. I think it'd be advantageous to not have a parser for an arbitrary config file format in the cmake, since the cmake set(CACHE) statements are already fairly user-readable. It would be different if we could only generate something less readable from the kconfig (i.e. xml/json). It would be ideal if we could generate the statements such that: set(<variable_name> <default_option> CACHE <TYPE> "<docstring> (<valid_option> | <valid_option> | ...)" I'm not sure if we can do this in Kconfig, but it seems plausible, and imo is the ideal solution since it gives the user of later editing the cmake config (even using a cache editor like ccmake) while documenting which choices are sane. Raef ________________________________________ From: Gyorgy Szing <Gyorgy.Szing(a)arm.com> Sent: 12 June 2020 06:56 To: David Hu; Adrian Shaw; Raef Coles; tf-m(a)lists.trustedfirmware.org Cc: nd; nd Subject: RE: CMake flags Hi, This requirement could be addressed with a user specific metadata file which is processed by the build-system. Implementation wise the easiest would be to include a file like UserCfg.cmake. This file could contain set(<option> CACHE <STRING|BOOL|PATH> "") commands to set the option variables. User experience wise a text file parsed by cmake scripts would be the best. Such a file could contain variable=value lines. Longer term when Kconfig support is ready, it could cover these options too. Running Kconfig is a an act done less often, and most of the times, the user is expected to save the Kconfig input and output files. Most of the time the build-system would just use the pre-generated config. I imagine a workflow similar to the one used by the Linux Kernel. Just my two cent's though. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 12 June 2020 07:33 To: Adrian Shaw <Adrian.Shaw(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CMake flags Hi Adrian, Actually we have been investigating configuration alternatives and making some prototypes of Kconfig. Kconfig can bring some advantages: * It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. * Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system. But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: Friday, June 12, 2020 12:24 AM To: Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] CMake flags Hi Raef. Thanks for the presentation today. If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed. From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help? Adrian -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] CMake flags

by Gyorgy Szing

Hi, This requirement could be addressed with a user specific metadata file which is processed by the build-system. Implementation wise the easiest would be to include a file like UserCfg.cmake. This file could contain set(<option> CACHE <STRING|BOOL|PATH> "") commands to set the option variables. User experience wise a text file parsed by cmake scripts would be the best. Such a file could contain variable=value lines. Longer term when Kconfig support is ready, it could cover these options too. Running Kconfig is a an act done less often, and most of the times, the user is expected to save the Kconfig input and output files. Most of the time the build-system would just use the pre-generated config. I imagine a workflow similar to the one used by the Linux Kernel. Just my two cent's though. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 12 June 2020 07:33 To: Adrian Shaw <Adrian.Shaw(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CMake flags Hi Adrian, Actually we have been investigating configuration alternatives and making some prototypes of Kconfig. Kconfig can bring some advantages: * It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. * Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system. But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: Friday, June 12, 2020 12:24 AM To: Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] CMake flags Hi Raef. Thanks for the presentation today. If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed. >From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help? Adrian

5 years, 6 months

3
3
0 0

Re: [TF-M] CMake flags

by Gyorgy Szing

Hi, Just some minor additions. In the TF-M build system Kconfig will most likely generate input for cmake scripts, so the compiler may not have a connection to it. The original intention with DT is capturing configuration data to allow hardware independent binaries (for defining base address of peripherals, boot information, etc..), and is mostly parsed runtime. In the Cortex-M space this might be a bit out-of scope. Most likely it will be used as a "standard" language to define "retargeting" information, and a tool will be developed which runs compile time and which allows access to the retargeting data for cmake. Something like CMSIS zone, but closer to established open-source technologies. In multicore systems having bot Cortex-A and M core DT would allow having a consistent solution for both A and M firmware. This is also a reason why cmake is a better build solution for TF-M than CMSIS Build. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 12 June 2020 11:16 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] CMake flags Hi Thomas, DT is another very attractive topic. TF-M currently doesn't include any DT support. So maybe there is mixed preprocessing of DT and Kconfig in Zephyr, but Kconfig can be parsed without any compiler. Best regards, Hu Ziji From: Thomas Törnblom <thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com>> Sent: Friday, June 12, 2020 5:09 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; 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] CMake flags Perhaps I'm mixing dts and Kconfig up. In Zephyr, dtc is used to generate output that is run through the gcc preprocessor in assembly mode. The output from dtc looks like: --- /dts-v1/; / { ï¿½ï¿½ï¿½ #address-cells = < 0x1 >; ï¿½ï¿½ï¿½ #size-cells = < 0x1 >; ï¿½ï¿½ï¿½ model = "STMicroelectronics STM32F746G DISCOVERY board"; ï¿½ï¿½ï¿½ compatible = "st,stm32f746g-disco", "st,stm32f746"; ï¿½ï¿½ï¿½ chosen { ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,console = &usart1; ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,shell-uart = &usart1; ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,sram = &sram0; ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,flash = &flash0; ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,dtcm = &dtcm; ï¿½ï¿½ï¿½ }; ... --- Our preprocessor can not be run in assembler mode and it pukes on the "#address-cells" type elements in the file. If this is not what Kconfig is about, then please ignore my comments. Thomas Den 2020-06-12 kl. 09:43, skrev David Hu: Hi Thomas, ï¿½ Iï¿½ve not met such a problem yet. Could you please give more details about the portability issues in Kconfig? In our PoC, it firstly parses the Kconfig files and then convert the output Kconfig options into CMake flags. Thus the whole process is not related to any compiler. I checked Zephyr previously. It looks like Zephyr has the similar idea as our PoC does. ï¿½ Best regards, Hu Ziji ï¿½ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Tï¿½rnblom via TF-M Sent: Friday, June 12, 2020 3:36 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] CMake flags ï¿½ Introducing a dependency on Kconfig may cause portability issues with some toolchains (IAR for instance) I am working on adding support for the IAR toolchain to Zephyr, and Kconfig is one of the issues I've run into. At least in Zephyr, the output from Kconfig is run through the C preprocessor and this causes issues with the IAR preprocessor so for now I use gcc for this step. Thomas Den 2020-06-12 kl. 07:32, skrev David Hu via TF-M: Hi Adrian, ï¿½ Actually we have been investigating configuration alternatives and making some prototypes of Kconfig. ï¿½ Kconfig can bring some advantages: * It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. * Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system. ï¿½ But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig. ï¿½ Best regards, Hu Ziji ï¿½ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Friday, June 12, 2020 12:24 AM To: Raef Coles <Raef.Coles(a)arm.com><mailto:Raef.Coles@arm.com> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] CMake flags ï¿½ Hi Raef. Thanks for the presentation today. ï¿½ If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed. ï¿½ >From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help? ï¿½ Adrian ï¿½ ï¿½ -- 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> -- 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] CMake flags

by David Hu

Hi Thomas, I've not met such a problem yet. Could you please give more details about the portability issues in Kconfig? In our PoC, it firstly parses the Kconfig files and then convert the output Kconfig options into CMake flags. Thus the whole process is not related to any compiler. I checked Zephyr previously. It looks like Zephyr has the similar idea as our PoC does. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Friday, June 12, 2020 3:36 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] CMake flags Introducing a dependency on Kconfig may cause portability issues with some toolchains (IAR for instance) I am working on adding support for the IAR toolchain to Zephyr, and Kconfig is one of the issues I've run into. At least in Zephyr, the output from Kconfig is run through the C preprocessor and this causes issues with the IAR preprocessor so for now I use gcc for this step. Thomas Den 2020-06-12 kl. 07:32, skrev David Hu via TF-M: Hi Adrian, Actually we have been investigating configuration alternatives and making some prototypes of Kconfig. Kconfig can bring some advantages: * It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. * Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system. But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Friday, June 12, 2020 12:24 AM To: Raef Coles <Raef.Coles(a)arm.com><mailto:Raef.Coles@arm.com> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] CMake flags Hi Raef. Thanks for the presentation today. If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed. >From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help? Adrian -- 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>

5 years, 6 months

2
2
0 0

Re: [TF-M] CMake flags

by Thomas Törnblom

Introducing a dependency on Kconfig may cause portability issues with some toolchains (IAR for instance) I am working on adding support for the IAR toolchain to Zephyr, and Kconfig is one of the issues I've run into. At least in Zephyr, the output from Kconfig is run through the C preprocessor and this causes issues with the IAR preprocessor so for now I use gcc for this step. Thomas Den 2020-06-12 kl. 07:32, skrev David Hu via TF-M: > > Hi Adrian, > > Actually we have been investigating configuration alternatives and > making some prototypes of Kconfig. > > Kconfig can bring some advantages: > > * It can setup configuration and check dependency before CMake > starts and therefore it can help CMake simplify dealing with the > mutual dependencies. For example, if CPU and arch options can be > configured in Kconfig, CMake can avoid the workaround to > re-configure compiler after parsing platform files. > * Kconfig can collect together the options which are distributed in > various CMake files. Developers can more easily understand the > options and their dependencies, compared with searching them all > around the build system. > > But Kconfig may not cover all the flags in command line. Flags such as > compiler selections, build type and project config file, may vary in > each build. It can be inconvenient to put them into Kconfig. > > Best regards, > > Hu Ziji > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Adrian Shaw via TF-M > *Sent:* Friday, June 12, 2020 12:24 AM > *To:* Raef Coles <Raef.Coles(a)arm.com> > *Cc:* tf-m(a)lists.trustedfirmware.org > *Subject:* [TF-M] CMake flags > > Hi Raef. Thanks for the presentation today. > > If I remember correctly, TF-M's CMake has quite a lot of command line > flags now (the ones that are set with -D). And I think this will grow > in the future as more options are needed. > > From a command line point of view, this is kind of annoying because > the commands end up being quite long. Do you guys think something like > Kconfig could help? > > Adrian > > -- *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>

5 years, 6 months

1
0
0 0

Re: [TF-M] CMake flags

by David Hu

Hi Adrian, Actually we have been investigating configuration alternatives and making some prototypes of Kconfig. Kconfig can bring some advantages: * It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. * Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system. But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Friday, June 12, 2020 12:24 AM To: Raef Coles <Raef.Coles(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] CMake flags Hi Raef. Thanks for the presentation today. If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed. >From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help? Adrian

5 years, 6 months

1
0
0 0

CMake flags

by Adrian Shaw

Hi Raef. Thanks for the presentation today. If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed. >From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help? Adrian

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - June 11

by Anton Komlev

Hello, Agenda for today's Tech forum: 1. Ongoing MCUboot alignment update. 2. Build system improvements. Code sharing between bootloader and runtime firmware will be presented on the next call. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Vincze via TF-M Sent: 05 June 2020 13:03 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - June 11 Hi, I also would like to give a brief update on the status of the ongoing MCUboot alignment work. David V From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M Sent: 05 June 2020 11:23 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] TF-M Technical Forum call - June 11 Hi Anton, I would like to give a short presentation about crypto code sharing between bootloader and runtime firmware(SPE). Tamas 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: 03 June 2020 21:21 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] TF-M Technical Forum call - June 11 Hello, The next Technical Forum is planned on Thursday, June 11 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 11 June 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 11 June 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 11 June 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 11 June 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 11 June 2020, 15:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T1500> Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

TF-M v1.1 - Heads up

by Shebu Varghese Kuriakose

Hi All, Just a heads up that TF-Mv1.1 tag is planned for middle to end of July. Code freeze of TF-M master is aimed around end of June to allow enough time for testing. Similar to TF-Mv1.0 and previous tags, v1.1 will include all TF-M changes in TF-M master available till code freeze in end of June. Availability of the tag will be notified via. this mailing list. Thanks, Shebu Technology Manager-TF-M, Arm Ltd.

5 years, 6 months

1
0
0 0

Re: [TF-M] Gerrit issues

by Kevin Peng

Hi, In case you meet the same issue as Thomas. There are two possible solutions from our experience. One is: * Abandon both the duplicated changes. * Change the change-ID of you patch and then submit * You end up with a whole new patch without the original histories. In this way, you lose both the change history and review history. If you are OK with that, you can quick solve the issue by yourself. Otherwise, the other solution is to contact Benjamin Copeland <ben.copeland(a)linaro.org<mailto:ben.copeland@linaro.org>> to delete one of the duplicates(usually keep the one with histories). And push your new patch set after deletion. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Tuesday, June 9, 2020 10:08 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Gerrit issues Issue sorted now, thanks to Ben Copeland. Thomas Den 2020-06-09 kl. 08:51, skrev Thomas Törnblom via TF-M: Still having this issue: --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git HEAD:refs/for/master Enumerating objects: 208, done. Counting objects: 100% (207/207), done. Delta compression using up to 4 threads Compressing objects: 100% (131/131), done. Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done. Total 135 (delta 97), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (97/97) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git ! [remote rejected] HEAD -> refs/for/master (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates) error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git' --- Any ideas how to resolve? I guess starting out with a fresh local repo would work, but I have 11 patches waiting to be reviewed and merged. A handful of them appears to be duplicated, and I abandoned those that appeared to be old and had merge conflicts. Unfortunately a majority of those had already been reviewed and the new ones aren't. The new ones has also lost their reviewers So now I'm stuck and I can't update or create new patches. 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> -- 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] Gerrit issues

by Thomas Törnblom

Issue sorted now, thanks to Ben Copeland. Thomas Den 2020-06-09 kl. 08:51, skrev Thomas Törnblom via TF-M: > Still having this issue: > --- > PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push > ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git > HEAD:refs/for/master > Enumerating objects: 208, done. > Counting objects: 100% (207/207), done. > Delta compression using up to 4 threads > Compressing objects: 100% (131/131), done. > Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done. > Total 135 (delta 97), reused 0 (delta 0), pack-reused 0 > remote: Resolving deltas: 100% (97/97) > remote: Processing changes: refs: 1, done > To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git > ! [remote rejected] HEAD -> refs/for/master > (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates) > error: failed to push some refs to > 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git' > --- > > Any ideas how to resolve? > > I guess starting out with a fresh local repo would work, but I have 11 > patches waiting to be reviewed and merged. > > A handful of them appears to be duplicated, and I abandoned those that > appeared to be old and had merge conflicts. Unfortunately a majority > of those had already been reviewed and the new ones aren't. The new > ones has also lost their reviewers > > So now I'm stuck and I can't update or create new patches. > > 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> > -- *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>

5 years, 6 months

1
0
0 0

Re: [TF-M] Gerrit issues

by Thomas Törnblom

Still having this issue: --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git HEAD:refs/for/master Enumerating objects: 208, done. Counting objects: 100% (207/207), done. Delta compression using up to 4 threads Compressing objects: 100% (131/131), done. Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done. Total 135 (delta 97), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (97/97) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git ! [remote rejected] HEAD -> refs/for/master (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates) error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git' --- Any ideas how to resolve? I guess starting out with a fresh local repo would work, but I have 11 patches waiting to be reviewed and merged. A handful of them appears to be duplicated, and I abandoned those that appeared to be old and had merge conflicts. Unfortunately a majority of those had already been reviewed and the new ones aren't. The new ones has also lost their reviewers So now I'm stuck and I can't update or create new patches. 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M URLs update for code and Gerrit review

by Soby Mathew

Also the dashboard has been updated for the project to point to new repo : https://review.trustedfirmware.org/p/TF-M/trusted-firmware-m/+/dashboard/si… Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 08 June 2020 17:11 To: tf-m(a)lists.trustedfirmware.org; Thomas Törnblom <thomas.tornblom(a)iar.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M URLs update for code and Gerrit review Hi Thomas. I have just prepared a patch which is updating the documentation with references to the new repository address. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4487 Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 08 June 2020 13:17 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] TF-M URLs update for code and Gerrit review .../docs/processes/contributing.rst should be updated with the new URL also. I checked there when I started having issues, but saw no changes there. Thomas Den 2020-06-08 kl. 14:10, skrev Thomas Törnblom via TF-M: Thanks Anton, that explains things. However now I get some other issues: --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git HEAD:refs/for/master Enumerating objects: 208, done. Counting objects: 100% (207/207), done. Delta compression using up to 4 threads Compressing objects: 100% (131/131), done. Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done. Total 135 (delta 97), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (97/97) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git ! [remote rejected] HEAD -> refs/for/master (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates) error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git' --- Thomas Den 2020-06-08 kl. 13:43, skrev Anton Komlev via TF-M: Hello TF-M code moved to the new location recently with a redirection link from the original URL - for compatibility purpose. Unfortunately, Gerrit got confused with two namespaces and several patches got messed up last week. To prevent it from happen again, the old TF-M location marked as read-only mirror. Please use new TF-M URL for your pushing your commits: ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m New repo URL: https://review.trustedfirmware.org/TF-M/trusted-firmware-m Thanks, Anton -- 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> -- 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M URLs update for code and Gerrit review

by Minos Galanakis

Hi Thomas. I have just prepared a patch which is updating the documentation with references to the new repository address. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4487 Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 08 June 2020 13:17 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M URLs update for code and Gerrit review .../docs/processes/contributing.rst should be updated with the new URL also. I checked there when I started having issues, but saw no changes there. Thomas Den 2020-06-08 kl. 14:10, skrev Thomas Törnblom via TF-M: Thanks Anton, that explains things. However now I get some other issues: --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git HEAD:refs/for/master Enumerating objects: 208, done. Counting objects: 100% (207/207), done. Delta compression using up to 4 threads Compressing objects: 100% (131/131), done. Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done. Total 135 (delta 97), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (97/97) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git ! [remote rejected] HEAD -> refs/for/master (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates) error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git' --- Thomas Den 2020-06-08 kl. 13:43, skrev Anton Komlev via TF-M: Hello TF-M code moved to the new location recently with a redirection link from the original URL – for compatibility purpose. Unfortunately, Gerrit got confused with two namespaces and several patches got messed up last week. To prevent it from happen again, the old TF-M location marked as read-only mirror. Please use new TF-M URL for your pushing your commits: ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m New repo URL: https://review.trustedfirmware.org/TF-M/trusted-firmware-m Thanks, Anton -- 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> -- 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M URLs update for code and Gerrit review

by Adrian Shaw

Hi Anton, That URL you provided doesn't work: "Not Found". I presume you mean https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/ and respectively https://review.trustedfirmware.org/q/project:TF-M%252Ftrusted-firmware-m<https://review.trustedfirmware.org/q/project:TF-M%252Ftrusted-firmware-m+st…> Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 08 June 2020 12:43 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M URLs update for code and Gerrit review Hello TF-M code moved to the new location recently with a redirection link from the original URL – for compatibility purpose. Unfortunately, Gerrit got confused with two namespaces and several patches got messed up last week. To prevent it from happen again, the old TF-M location marked as read-only mirror. Please use new TF-M URL for your pushing your commits: ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m New repo URL: https://review.trustedfirmware.org/TF-M/trusted-firmware-m Thanks, Anton

5 years, 6 months

2
1
0 0

Re: [TF-M] TF-M URLs update for code and Gerrit review

by Thomas Törnblom

.../docs/processes/contributing.rst should be updated with the new URL also. I checked there when I started having issues, but saw no changes there. Thomas Den 2020-06-08 kl. 14:10, skrev Thomas Törnblom via TF-M: > Thanks Anton, that explains things. > > However now I get some other issues: > --- > PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push > ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git > HEAD:refs/for/master > Enumerating objects: 208, done. > Counting objects: 100% (207/207), done. > Delta compression using up to 4 threads > Compressing objects: 100% (131/131), done. > Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done. > Total 135 (delta 97), reused 0 (delta 0), pack-reused 0 > remote: Resolving deltas: 100% (97/97) > remote: Processing changes: refs: 1, done > To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git > ! [remote rejected] HEAD -> refs/for/master > (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates) > error: failed to push some refs to > 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git' > --- > > Thomas > > Den 2020-06-08 kl. 13:43, skrev Anton Komlev via TF-M: >> >> Hello >> >> TF-M code moved to the new location recently with a redirection link >> from the original URL – for compatibility purpose. >> >> Unfortunately, Gerrit got confused with two namespaces and several >> patches got messed up last week. To prevent it from happen again, the >> old TF-M location marked as read-only mirror. >> >> Please use new TF-M URL for your pushing your commits: >> >> ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m >> >> New repo URL: >> >> https://review.trustedfirmware.org/TF-M/trusted-firmware-m >> >> Thanks, >> >> Anton >> >> > > -- > > *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> > -- *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>

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M URLs update for code and Gerrit review

by Thomas Törnblom

Thanks Anton, that explains things. However now I get some other issues: --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git HEAD:refs/for/master Enumerating objects: 208, done. Counting objects: 100% (207/207), done. Delta compression using up to 4 threads Compressing objects: 100% (131/131), done. Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done. Total 135 (delta 97), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (97/97) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git ! [remote rejected] HEAD -> refs/for/master (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates) error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git' --- Thomas Den 2020-06-08 kl. 13:43, skrev Anton Komlev via TF-M: > > Hello > > TF-M code moved to the new location recently with a redirection link > from the original URL – for compatibility purpose. > > Unfortunately, Gerrit got confused with two namespaces and several > patches got messed up last week. To prevent it from happen again, the > old TF-M location marked as read-only mirror. > > Please use new TF-M URL for your pushing your commits: > > ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m > > New repo URL: > > https://review.trustedfirmware.org/TF-M/trusted-firmware-m > > Thanks, > > Anton > > -- *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>

5 years, 6 months

1
0
0 0

Re: [TF-M] Gerrit issues

by Thomas Törnblom

Is this perhaps related to the .gitreview and/or new repo location changes that appears to have been merged after my last push on Friday? If so, how to I fix this in my local repo? Thomas Den 2020-06-08 kl. 11:53, skrev Thomas Törnblom via TF-M: > Is there a problem pushing patches currently, or is there something > I've missed? > > I was able to push a patch on Friday, but today I get errors just > trying to push after a rebase with no changes: > --- > PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push > ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git > HEAD:refs/for/master > Enumerating objects: 22731, done. > Counting objects: 100% (22731/22731), done. > Delta compression using up to 4 threads > Compressing objects: 100% (7566/7566), done. > Writing objects: 100% (22731/22731), 11.22 MiB | 6.64 MiB/s, done. > Total 22731 (delta 15732), reused 21321 (delta 14653) > remote: Resolving deltas: 100% (15732/15732) > remote: Processing changes: refs: 1, done > To ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git > ! [remote rejected] HEAD -> refs/for/master (prohibited by Gerrit: > project state does not permit write) > error: failed to push some refs to > 'ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git' > --- > > 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> > -- *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>

5 years, 6 months

1
0
0 0

TF-M URLs update for code and Gerrit review

by Anton Komlev

Hello TF-M code moved to the new location recently with a redirection link from the original URL - for compatibility purpose. Unfortunately, Gerrit got confused with two namespaces and several patches got messed up last week. To prevent it from happen again, the old TF-M location marked as read-only mirror. Please use new TF-M URL for your pushing your commits: ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m New repo URL: https://review.trustedfirmware.org/TF-M/trusted-firmware-m Thanks, Anton

5 years, 6 months

1
0
0 0

Gerrit issues

by Thomas Törnblom

Is there a problem pushing patches currently, or is there something I've missed? I was able to push a patch on Friday, but today I get errors just trying to push after a rebase with no changes: --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git HEAD:refs/for/master Enumerating objects: 22731, done. Counting objects: 100% (22731/22731), done. Delta compression using up to 4 threads Compressing objects: 100% (7566/7566), done. Writing objects: 100% (22731/22731), 11.22 MiB | 6.64 MiB/s, done. Total 22731 (delta 15732), reused 21321 (delta 14653) remote: Resolving deltas: 100% (15732/15732) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git ! [remote rejected] HEAD -> refs/for/master (prohibited by Gerrit: project state does not permit write) error: failed to push some refs to 'ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git' --- 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - June 11

by David Vincze

Hi, I also would like to give a brief update on the status of the ongoing MCUboot alignment work. David V From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 05 June 2020 11:23 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - June 11 Hi Anton, I would like to give a short presentation about crypto code sharing between bootloader and runtime firmware(SPE). Tamas 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: 03 June 2020 21:21 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] TF-M Technical Forum call - June 11 Hello, The next Technical Forum is planned on Thursday, June 11 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 11 June 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 11 June 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 11 June 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 11 June 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 11 June 2020, 15:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T1500> Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - June 11

by Tamas Ban

Hi Anton, I would like to give a short presentation about crypto code sharing between bootloader and runtime firmware(SPE). Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 03 June 2020 21:21 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - June 11 Hello, The next Technical Forum is planned on Thursday, June 11 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 11 June 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 11 June 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 11 June 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 11 June 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 11 June 2020, 15:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T1500> Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Re: [TF-M] build error

by Gyorgy Szing

Hi, Can you please run the build with "cmake -build ./ -- install VERBOSE=1". This will show compiler command lines which could help. Based on the fact your assembler is complaining not understanding assembly instructions generated by the C compiler, I suspect your compiler is not supported. For "arm-none-eabi-cc -v" I get the following output: ....... gcc version 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512] (GNU Tools for ARM Embedded Processors 6-2017-q1-update) (Note I removed some not so interesting lines.) As you can see, the version string includes the release name of "6-2017-q1-update". All gcc binaries built by arm shall have this. Please double check what compiler you are using. The last bullet point in the blue "notes" section here: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… has the link to the download site and also names the releases you can use. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shawn Shan via TF-M Sent: 04 June 2020 10:21 To: Quach, Brian <brian(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] build error Hi Brian, I would like to correct my last Email: * CMSIS_5 version should be v5.5.0. * Mbedtls is not required anymore. Please refer to the "build instructions" link for the detail: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…. I have tried to reproduce your issue on my side but failed. So please try it again after changing the code version. Besides this, you can also check whether your build environment follows the TF-M user guides: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…. Please connect us again if you met any problems. Thanks, Shawn From: Quach, Brian <brian(a)ti.com<mailto:brian@ti.com>> Sent: Wednesday, June 3, 2020 3:09 AM To: Shawn Shan <Shawn.Shan(a)arm.com<mailto:Shawn.Shan@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: build error Hi Shawn, Yes, I emptied the cmake_build directory. I tried a fresh clone of the tags you specified but still get the same error. I'm using GNU Arm version mentioned in the TF-M user guide (v6.3.1) gcc version 6.3.1 20170620 (15:6.3.1+svn253039-1build1) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/trusted-firmware-m (master) $ git log commit b157dca40dcf2051a0420cb16d659a6aa69335d7 (HEAD -> master, origin/master, origin/HEAD) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/mbed-crypto ((mbedcrypto-3.0.1)) $ git log commit 1146b4e06011b69a6437e6b728f2af043a06ec19 (HEAD, tag: mbedcrypto-3.0.1) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/mbedtls ((mbedtls-2.7.9)) $ git log commit 3187e7ca986fe199313343b0c810e41b543ef78a (HEAD, tag: mbedtls-2.7.9) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/CMSIS_5 (Branch_5.2.0) $ git log commit 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 (HEAD -> Branch_5.2.0, tag: 5.2.0) Scanning dependencies of target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Preprocess the /mnt/c/Gits/tfm/trusted-firmware-m/cmake_build/image_macros_to_preprocess_s.c file [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 Scanning dependencies of target tfm_s_pp_tfm_common_s_1 [ 0%] Preprocess the /mnt/c/Gits/tfm/trusted-firmware-m/platform/ext/common/gcc/tfm_common_s.ld file [ 0%] Built target tfm_s_pp_tfm_common_s_1 Scanning dependencies of target tfm_s_obj_lib [ 1%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_api.o [ 1%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccmASnGm.s: Assembler messages: /tmp/ccmASnGm.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Shawn Shan via TF-M Sent: Monday, June 01, 2020 10:27 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [EXTERNAL] Re: [TF-M] build error Hi Brian, Did you empty the build directory before you build? And this is the recommended commit id for each of the repositories: Mbed-crypto: 1146b4e06011b69a6437e6b728f2af043a06ec19 Tag mbedcrypto-3.0.1 Mbedtls: 3187e7ca986fe199313343b0c810e41b543ef78a Tag mbedtls-2.7.9 CMSIS_5: 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 Tag 5.2.0 Could you share us the commit id of each repo and the toolchain version (arm-none-eabi-gcc -v) you are using? Thanks, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Quach, Brian via TF-M Sent: Tuesday, June 2, 2020 7:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] build error Hi All, I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution? mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Built target tfm_s_pp_tfm_common_s_1 [ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccpVCp1C.s: Assembler messages: /tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 6 months

1
0
0 0

Re: [TF-M] build error

by Shawn Shan

Hi Brian, I would like to correct my last Email: * CMSIS_5 version should be v5.5.0. * Mbedtls is not required anymore. Please refer to the "build instructions" link for the detail: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…. I have tried to reproduce your issue on my side but failed. So please try it again after changing the code version. Besides this, you can also check whether your build environment follows the TF-M user guides: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…. Please connect us again if you met any problems. Thanks, Shawn From: Quach, Brian <brian(a)ti.com> Sent: Wednesday, June 3, 2020 3:09 AM To: Shawn Shan <Shawn.Shan(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: build error Hi Shawn, Yes, I emptied the cmake_build directory. I tried a fresh clone of the tags you specified but still get the same error. I'm using GNU Arm version mentioned in the TF-M user guide (v6.3.1) gcc version 6.3.1 20170620 (15:6.3.1+svn253039-1build1) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/trusted-firmware-m (master) $ git log commit b157dca40dcf2051a0420cb16d659a6aa69335d7 (HEAD -> master, origin/master, origin/HEAD) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/mbed-crypto ((mbedcrypto-3.0.1)) $ git log commit 1146b4e06011b69a6437e6b728f2af043a06ec19 (HEAD, tag: mbedcrypto-3.0.1) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/mbedtls ((mbedtls-2.7.9)) $ git log commit 3187e7ca986fe199313343b0c810e41b543ef78a (HEAD, tag: mbedtls-2.7.9) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/CMSIS_5 (Branch_5.2.0) $ git log commit 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 (HEAD -> Branch_5.2.0, tag: 5.2.0) Scanning dependencies of target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Preprocess the /mnt/c/Gits/tfm/trusted-firmware-m/cmake_build/image_macros_to_preprocess_s.c file [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 Scanning dependencies of target tfm_s_pp_tfm_common_s_1 [ 0%] Preprocess the /mnt/c/Gits/tfm/trusted-firmware-m/platform/ext/common/gcc/tfm_common_s.ld file [ 0%] Built target tfm_s_pp_tfm_common_s_1 Scanning dependencies of target tfm_s_obj_lib [ 1%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_api.o [ 1%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccmASnGm.s: Assembler messages: /tmp/ccmASnGm.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Shawn Shan via TF-M Sent: Monday, June 01, 2020 10:27 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [EXTERNAL] Re: [TF-M] build error Hi Brian, Did you empty the build directory before you build? And this is the recommended commit id for each of the repositories: Mbed-crypto: 1146b4e06011b69a6437e6b728f2af043a06ec19 Tag mbedcrypto-3.0.1 Mbedtls: 3187e7ca986fe199313343b0c810e41b543ef78a Tag mbedtls-2.7.9 CMSIS_5: 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 Tag 5.2.0 Could you share us the commit id of each repo and the toolchain version (arm-none-eabi-gcc -v) you are using? Thanks, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Quach, Brian via TF-M Sent: Tuesday, June 2, 2020 7:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] build error Hi All, I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution? mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Built target tfm_s_pp_tfm_common_s_1 [ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccpVCp1C.s: Assembler messages: /tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 6 months

1
0
0 0

Re: [TF-M] [IMPORTANT] [SOURCE STRUCTURE] The first structure adjust patch is pushed

by Ken Liu

Hi, There are few comments on the structure document, so let's merge the first patch as a signal. This merging does not mean it is the decided shape - the structure related comments are always open, feedback on the mailing list or the task: https://developer.trustedfirmware.org/T751 Or, to be direct, put comments on the ongoing updates to the design doc: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4415 Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, June 1, 2020 2:11 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [IMPORTANT] [SOURCE STRUCTURE] The first structure adjust patch is pushed Hi, As the first commit of 'source_structure' document is merged, here is the first patch to follow the document: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4315 The patch looks big, even it just adjusts the content inside 'secure_fw'. To make the related sources can pass the building, some files out of the 'secure_fw' need to be changed. The goal of merging is ASAP so that we won't block upcoming features. Please provide the feedback about potential USAGE problem you may meet. As the patch is big, it won't be applicable to make THIS patch perfect to meet all the requirements defined in the document, a series of upcoming patches would come as amending. Also if there are suggestions about the structure document, please write to the mailing list and put discussion in this task: https://developer.trustedfirmware.org/T751 The rendered structure document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/252/artifact/bui… BR /Ken

5 years, 6 months

1
0
0 0

[RFC] [Logging API] Design document call for review

by Shawn Shan

Hi all, I have created a draft design document of the TF-M logging system. Could you please help review it https://review.trustedfirmware.org/c/trusted-firmware-m/+/4417 ? Welcome your comments and suggestions.😊 Best regards, Shawn

5 years, 6 months

1
0
0 0

TF-M Technical Forum call - June 11

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, June 11 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 11 June 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 11 June 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 11 June 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 11 June 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 11 June 2020, 15:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T1500> Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Tamas Ban

Hi Kumar, We are going to check and merge changes from Kevin before v1.1 release. Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: 03 June 2020 13:02 To: Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes required to enable Zephyr integration as External_Project Than I ask that the changes Kevin has posted be looked at for TFM v1.1 as the are relatively small and than the CMake rework can be done on top of them if its able to land for v1.1. - k > On Jun 3, 2020, at 3:30 AM, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > There was a plan to include the new build system into TFM v1.1 but looking onto change size and interdependencies with other ongoing changes like code restructuring, the delivery of new CMake in TFM v1.1 is optional. > The intention is to be safe and test more instead of delivery ahead and fix later. > > Anton > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar > Gala via TF-M > Sent: 02 June 2020 13:50 > To: Raef Coles <Raef.Coles(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Changes required to enable Zephyr integration as > External_Project > > What’s the timeframe expectation with the new cmake work? Is this something that is planned for TFM 1.1? > > - k > >> On Jun 2, 2020, at 7:11 AM, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> Thank you very much for the changes to the image signing script - those look like great QOL improvements. >> >> WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. >> >> I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. >> >> Raef >> >> ________________________________________ >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of >> Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> >> Sent: 02 June 2020 12:11 >> To: Thomas Törnblom via TF-M >> Subject: [TF-M] Changes required to enable Zephyr integration as >> External_Project >> >> Hi, >> >> The following task lists some of the changes that we had to make to >> enable TF-M to be built using ExternalProject_Add from Zephyr, as >> well as enabling the use of ninja for TF-M builds (which is often >> significantly faster than using classic >> makefiles): https://developer.trustedfirmware.org/T760 >> >> The ninja changes have been tested with: >> >> $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. >> $ ninja >> >> The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. >> >> Any concerns or feedback on these are welcome, but I would be >> interested to hear any opinions on ninja which is often considerably >> faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). >> >> Best regards, >> Kevin >> -- >> 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 > -- > 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

5 years, 6 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Kumar Gala

Than I ask that the changes Kevin has posted be looked at for TFM v1.1 as the are relatively small and than the CMake rework can be done on top of them if its able to land for v1.1. - k > On Jun 3, 2020, at 3:30 AM, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > There was a plan to include the new build system into TFM v1.1 but looking onto change size and interdependencies with other ongoing changes like code restructuring, the delivery of new CMake in TFM v1.1 is optional. > The intention is to be safe and test more instead of delivery ahead and fix later. > > Anton > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M > Sent: 02 June 2020 13:50 > To: Raef Coles <Raef.Coles(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Changes required to enable Zephyr integration as External_Project > > What’s the timeframe expectation with the new cmake work? Is this something that is planned for TFM 1.1? > > - k > >> On Jun 2, 2020, at 7:11 AM, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> Thank you very much for the changes to the image signing script - those look like great QOL improvements. >> >> WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. >> >> I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. >> >> Raef >> >> ________________________________________ >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin >> Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> >> Sent: 02 June 2020 12:11 >> To: Thomas Törnblom via TF-M >> Subject: [TF-M] Changes required to enable Zephyr integration as >> External_Project >> >> Hi, >> >> The following task lists some of the changes that we had to make to >> enable TF-M to be built using ExternalProject_Add from Zephyr, as well >> as enabling the use of ninja for TF-M builds (which is often >> significantly faster than using classic >> makefiles): https://developer.trustedfirmware.org/T760 >> >> The ninja changes have been tested with: >> >> $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. >> $ ninja >> >> The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. >> >> Any concerns or feedback on these are welcome, but I would be >> interested to hear any opinions on ninja which is often considerably >> faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). >> >> Best regards, >> Kevin >> -- >> 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 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Invitation: TF-M Tech Forum (US TZ) @ Thu 25 Jun 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum (US TZ) ** 25th June call rescheduled (due to holidays in China) **About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 25 Jun 2020 16:00 – 17:00 United Kingdom Time Where: Via Zoom Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MGFmdnVlcmltYjB1M2Y1O… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 6 months

1
0
0 0

Cancelled event with note: TF-M tech Forum (Asia TZ) @ Thu 25 Jun 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "Due to holidays in China, the event in this time slot is cancelled. " Title: TF-M tech Forum (Asia TZ) About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 25 Jun 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M PSA key management

by Soby Mathew

Hi Brian, The struct you have mentioned is part of the implementation defined `psa_key_attributes_t` data structure. The key algorithm and policy are accessed via appropriate get/set API's (like psa_set_key_algorithm/ psa_get_key_algorithm). Hence these fields are not meant to be directly accessed by the clients but are an implementation detail of crypto Service. The only reason the 2 algorithm fields exists now is because the mbedcrypto defined the structure that way. I have a patch in flight which cleans up the client view of the psa_key_attributes_t such that only fields required by client are defined. The patch is available for review here : https://review.trustedfirmware.org/c/trusted-firmware-m/+/4217 Regarding psa_open_key() and psa_close_key(), TF-M tries to implement PSA Crypto 1.0 Beta 3 version of the spec whereas the APIs are removed in 1.0 version. Currently mbedcrypto does not support 1.0 version fully yet. Once 1.0 is supported mbedcrypto, then TF-M will also make the migrate the APIs to 1.0. This is expected to happen during Q3 timeframe. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Quach, Brian via TF-M Sent: 02 June 2020 23:44 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M PSA key management Hi All, I see that the PSA crypto API v1.0 spec says "This specification only defines policies that restrict keys to a single algorithm, which is consistent with both common practice and security good practice. ", but the TF-M code defines two algs in the policy struct. Which will be the path going forward? struct psa_key_policy_s { psa_key_usage_t usage; psa_algorithm_t alg; psa_algorithm_t alg2; }; I also see psa_open_key() and psa_close_key() were removed from the spec. Any plans to remove from TF-M code in the future? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 6 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Anton Komlev

Hi, There was a plan to include the new build system into TFM v1.1 but looking onto change size and interdependencies with other ongoing changes like code restructuring, the delivery of new CMake in TFM v1.1 is optional. The intention is to be safe and test more instead of delivery ahead and fix later. Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: 02 June 2020 13:50 To: Raef Coles <Raef.Coles(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes required to enable Zephyr integration as External_Project What’s the timeframe expectation with the new cmake work? Is this something that is planned for TFM 1.1? - k > On Jun 2, 2020, at 7:11 AM, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Thank you very much for the changes to the image signing script - those look like great QOL improvements. > > WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. > > I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. > > Raef > > ________________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin > Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 02 June 2020 12:11 > To: Thomas Törnblom via TF-M > Subject: [TF-M] Changes required to enable Zephyr integration as > External_Project > > Hi, > > The following task lists some of the changes that we had to make to > enable TF-M to be built using ExternalProject_Add from Zephyr, as well > as enabling the use of ninja for TF-M builds (which is often > significantly faster than using classic > makefiles): https://developer.trustedfirmware.org/T760 > > The ninja changes have been tested with: > > $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. > $ ninja > > The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. > > Any concerns or feedback on these are welcome, but I would be > interested to hear any opinions on ninja which is often considerably > faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). > > Best regards, > Kevin > -- > 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

5 years, 6 months

1
0
0 0

TF-M PSA key management

by Quach, Brian

Hi All, I see that the PSA crypto API v1.0 spec says "This specification only defines policies that restrict keys to a single algorithm, which is consistent with both common practice and security good practice. ", but the TF-M code defines two algs in the policy struct. Which will be the path going forward? struct psa_key_policy_s { psa_key_usage_t usage; psa_algorithm_t alg; psa_algorithm_t alg2; }; I also see psa_open_key() and psa_close_key() were removed from the spec. Any plans to remove from TF-M code in the future? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 6 months

1
0
0 0

Re: [TF-M] DSP instructions and FPU use

by Joseph Yiu

Hi Ken, Soby, In additional to FPCCR_S.TS, You should also set FPCCR_S.CLRONRET and FPCCR_S.CLRONRETS. FPCCR_S.CLRONRET ensures that FPU register contents are cleared when return from a Secure exception to the Non-secure world, and FPCCR_S.CLRONRETS ensures that the Non-secure world cannot change the FPCCR_S.CLRONRET setting. Regards, Joseph From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 02 June 2020 04:36 To: Ken Liu <Ken.Liu(a)arm.com>; TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] DSP instructions and FPU use Hi Ken, I agree that FPCCR_S.TS (in addition to other setting for FP) should be set if FPU needs to be used in secure world. The FPCCR.LSPEN allows saving the context lazily which was what I was referring to previously. Eventhough the hardware is performing the stacking, the policy chosen (lazy stacking/stack always) affects interrupt latency which should be considered for the design for FPU usage in TF-M. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 01 June 2020 15:55 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] DSP instructions and FPU use Hi Soby & Andrej, The FP context is managed by hardware automatically in M-profile architecture. While booting we clear FPCA since we are not using FP under handler mode, we don't want FP get involved during initialization and need extra clean up job. But if a thread uses FP the FPCA is set to 1 automatically, and if exceptions are happening the FP context stacked automatically by hardware - the secure scheduler just keep the EXC_RETURN which contains FP context and finally recover it back. Which means if you enabled hardware FP unintentional it can work, the only place a problem may occur should be the non-secure preempting secure execution case. I think the only thing we are missing now is we did not set FPCCR_S.TS = 1 since we did not realize that user would enable FP in secure world. This would cause the FP register may contain secure information while Non-secure preempting secure execution. Need to go through the settings and double-check. So at least before we finish the estimation I think FPCCR_S.TS should be set to ensure the security. Andrej, have you set this bit while you are using hardware FP? Or just let it go (use default TF-M setting)? Thanks. /Ken From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Monday, June 1, 2020 5:25 PM To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: DSP instructions and FPU use Hi, For enabling floating point the ARMv8-M architecture allows the flowing possibilities : * Stacking the basic Floating-point context. * Stacking the basic Floating-point context and the additional Floating-point context. * Activation of Lazy Floating-point state preservation. The easiest way would be to enable FP context stacking for every context switch but it would impact every context switch irrespective of whether FP unit is used in that context or not . I guess this is the approach taken by Andrej ? . The Lazy Floating point state preservation would be better for performance but it would have additional complexity in managing the contexts. Just blue sky thinking here: There could be a middle ground wherein some partitions are allowed to use FP while others are not because they don't really need to. The ones allowed to use FP will need to cater for the additional stack requirement to save FP context. The actual save of the context can be done either on context switch to the partition or lazily. This approach could give the benefit of both performance and memory savings but it requires some analysis and design to be done in TF-M. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 01 June 2020 09:05 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] DSP instructions and FPU use Hi Andrej, You mean the hardware floatpoint can be used in the Secure Partition? That's a good information, can you share us the compiler flags about float-point you are using? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Monday, June 1, 2020 2:46 PM To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: DSP instructions and FPU use FYI: >> Can you do some experiments on enabling hardware float point and see if it is working In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Monday, June 1, 2020 8:41 AM 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] DSP instructions and FPU use Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 6 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Kumar Gala

What’s the timeframe expectation with the new cmake work? Is this something that is planned for TFM 1.1? - k > On Jun 2, 2020, at 7:11 AM, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Thank you very much for the changes to the image signing script - those look like great QOL improvements. > > WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. > > I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. > > Raef > > ________________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 02 June 2020 12:11 > To: Thomas Törnblom via TF-M > Subject: [TF-M] Changes required to enable Zephyr integration as External_Project > > Hi, > > The following task lists some of the changes that we had to make to enable > TF-M to be built using ExternalProject_Add from Zephyr, as well as enabling the > use of ninja for TF-M builds (which is often significantly faster than using classic > makefiles): https://developer.trustedfirmware.org/T760 > > The ninja changes have been tested with: > > $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. > $ ninja > > The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. > > Any concerns or feedback on these are welcome, but I would be interested to hear > any opinions on ninja which is often considerably faster out of the box when compiling > (at least on Linux and native OS X, which is what I use for my builds). > > Best regards, > Kevin > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Raef Coles

Hi, Thank you very much for the changes to the image signing script - those look like great QOL improvements. WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 02 June 2020 12:11 To: Thomas Törnblom via TF-M Subject: [TF-M] Changes required to enable Zephyr integration as External_Project Hi, The following task lists some of the changes that we had to make to enable TF-M to be built using ExternalProject_Add from Zephyr, as well as enabling the use of ninja for TF-M builds (which is often significantly faster than using classic makefiles): https://developer.trustedfirmware.org/T760 The ninja changes have been tested with: $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. $ ninja The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. Any concerns or feedback on these are welcome, but I would be interested to hear any opinions on ninja which is often considerably faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). Best regards, Kevin

5 years, 6 months

1
0
0 0

Changes required to enable Zephyr integration as External_Project

by Kevin Townsend

Hi, The following task lists some of the changes that we had to make to enable TF-M to be built using ExternalProject_Add from Zephyr, as well as enabling the use of ninja for TF-M builds (which is often significantly faster than using classic makefiles): https://developer.trustedfirmware.org/T760 The ninja changes have been tested with: $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. $ ninja The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. Any concerns or feedback on these are welcome, but I would be interested to hear any opinions on ninja which is often considerably faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). Best regards, Kevin

5 years, 6 months

1
0
0 0

Re: [TF-M] DSP instructions and FPU use

by Soby Mathew

Hi Ken, I agree that FPCCR_S.TS (in addition to other setting for FP) should be set if FPU needs to be used in secure world. The FPCCR.LSPEN allows saving the context lazily which was what I was referring to previously. Eventhough the hardware is performing the stacking, the policy chosen (lazy stacking/stack always) affects interrupt latency which should be considered for the design for FPU usage in TF-M. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 01 June 2020 15:55 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] DSP instructions and FPU use Hi Soby & Andrej, The FP context is managed by hardware automatically in M-profile architecture. While booting we clear FPCA since we are not using FP under handler mode, we don't want FP get involved during initialization and need extra clean up job. But if a thread uses FP the FPCA is set to 1 automatically, and if exceptions are happening the FP context stacked automatically by hardware - the secure scheduler just keep the EXC_RETURN which contains FP context and finally recover it back. Which means if you enabled hardware FP unintentional it can work, the only place a problem may occur should be the non-secure preempting secure execution case. I think the only thing we are missing now is we did not set FPCCR_S.TS = 1 since we did not realize that user would enable FP in secure world. This would cause the FP register may contain secure information while Non-secure preempting secure execution. Need to go through the settings and double-check. So at least before we finish the estimation I think FPCCR_S.TS should be set to ensure the security. Andrej, have you set this bit while you are using hardware FP? Or just let it go (use default TF-M setting)? Thanks. /Ken From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Monday, June 1, 2020 5:25 PM To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: DSP instructions and FPU use Hi, For enabling floating point the ARMv8-M architecture allows the flowing possibilities : * Stacking the basic Floating-point context. * Stacking the basic Floating-point context and the additional Floating-point context. * Activation of Lazy Floating-point state preservation. The easiest way would be to enable FP context stacking for every context switch but it would impact every context switch irrespective of whether FP unit is used in that context or not . I guess this is the approach taken by Andrej ? . The Lazy Floating point state preservation would be better for performance but it would have additional complexity in managing the contexts. Just blue sky thinking here: There could be a middle ground wherein some partitions are allowed to use FP while others are not because they don't really need to. The ones allowed to use FP will need to cater for the additional stack requirement to save FP context. The actual save of the context can be done either on context switch to the partition or lazily. This approach could give the benefit of both performance and memory savings but it requires some analysis and design to be done in TF-M. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 01 June 2020 09:05 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] DSP instructions and FPU use Hi Andrej, You mean the hardware floatpoint can be used in the Secure Partition? That's a good information, can you share us the compiler flags about float-point you are using? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Monday, June 1, 2020 2:46 PM To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: DSP instructions and FPU use FYI: >> Can you do some experiments on enabling hardware float point and see if it is working In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Monday, June 1, 2020 8:41 AM 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] DSP instructions and FPU use Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 6 months

1
0
0 0

Re: [TF-M] build error

by Shawn Shan

Hi Brian, Did you empty the build directory before you build? And this is the recommended commit id for each of the repositories: Mbed-crypto: 1146b4e06011b69a6437e6b728f2af043a06ec19 Tag mbedcrypto-3.0.1 Mbedtls: 3187e7ca986fe199313343b0c810e41b543ef78a Tag mbedtls-2.7.9 CMSIS_5: 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 Tag 5.2.0 Could you share us the commit id of each repo and the toolchain version (arm-none-eabi-gcc -v) you are using? Thanks, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Quach, Brian via TF-M Sent: Tuesday, June 2, 2020 7:25 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] build error Hi All, I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution? mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Built target tfm_s_pp_tfm_common_s_1 [ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccpVCp1C.s: Assembler messages: /tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 6 months

1
0
0 0

build error

by Quach, Brian

Hi All, I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution? mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Built target tfm_s_pp_tfm_common_s_1 [ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccpVCp1C.s: Assembler messages: /tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 6 months

1
0
0 0

Re: [TF-M] DSP instructions and FPU use

by Soby Mathew

Hi, For enabling floating point the ARMv8-M architecture allows the flowing possibilities : * Stacking the basic Floating-point context. * Stacking the basic Floating-point context and the additional Floating-point context. * Activation of Lazy Floating-point state preservation. The easiest way would be to enable FP context stacking for every context switch but it would impact every context switch irrespective of whether FP unit is used in that context or not . I guess this is the approach taken by Andrej ? . The Lazy Floating point state preservation would be better for performance but it would have additional complexity in managing the contexts. Just blue sky thinking here: There could be a middle ground wherein some partitions are allowed to use FP while others are not because they don't really need to. The ones allowed to use FP will need to cater for the additional stack requirement to save FP context. The actual save of the context can be done either on context switch to the partition or lazily. This approach could give the benefit of both performance and memory savings but it requires some analysis and design to be done in TF-M. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 01 June 2020 09:05 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] DSP instructions and FPU use Hi Andrej, You mean the hardware floatpoint can be used in the Secure Partition? That's a good information, can you share us the compiler flags about float-point you are using? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Monday, June 1, 2020 2:46 PM To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: DSP instructions and FPU use FYI: >> Can you do some experiments on enabling hardware float point and see if it is working In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Monday, June 1, 2020 8:41 AM 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] DSP instructions and FPU use Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 6 months

2
1
0 0

Re: [TF-M] DSP instructions and FPU use

by Andrej Butok

FYI: >> Can you do some experiments on enabling hardware float point and see if it is working In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, June 1, 2020 8:41 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] DSP instructions and FPU use Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 6 months

2
1
0 0

Re: [TF-M] DSP instructions and FPU use

by Ken Liu

Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 6 months

1
0
0 0

[IMPORTANT] [SOURCE STRUCTURE] The first structure adjust patch is pushed

by Ken Liu

Hi, As the first commit of 'source_structure' document is merged, here is the first patch to follow the document: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4315 The patch looks big, even it just adjusts the content inside 'secure_fw'. To make the related sources can pass the building, some files out of the 'secure_fw' need to be changed. The goal of merging is ASAP so that we won't block upcoming features. Please provide the feedback about potential USAGE problem you may meet. As the patch is big, it won't be applicable to make THIS patch perfect to meet all the requirements defined in the document, a series of upcoming patches would come as amending. Also if there are suggestions about the structure document, please write to the mailing list and put discussion in this task: https://developer.trustedfirmware.org/T751 The rendered structure document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/252/artifact/bui… BR /Ken

5 years, 6 months

1
0
0 0

DSP instructions and FPU use

by Cindy Chaumont

Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 6 months

1
0
0 0

TF-M Profile Small patches merged

by David Hu

Hi all, TF-M Profile Small patches are merged in TF-M master branch. Thanks a lot for all your review, comments and support. I'd appreciate it if you could feedback and share ideas while enabling Profile Small in your actual use cases. If there is any issue, please feel free to let us know. Thank you. The next step will bring in symmetric key algorithm based Initial Attestation and then Profile Small can have a full set of features. Best regards, Hu Ziji

5 years, 6 months

1
0
0 0

Correction - MMIO region is not sharable between partitions

by Ken Liu

Hi, In the tech forum I mentioned a potential way of sharing MMIO regions - this is not correct. Double checked the PSA FF and it is defined explicitly in the spec page 43: "A Secure Partition always has exclusive access to an MMIO region. Secure Partitions are not allowed to share MMIO regions with other Secure Partitions and MMIO regions are not allowed to overlap." Sorry for the confusion. BR /Ken

5 years, 7 months

1
0
0 0

Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM

by Jonatan Antoni

Hi Gyorgy, Ken, Let me add one statement to Gyorgy's > It became a de-facto standard and most compilers support it. Compilers not yet supported can be easily added, if required. Cheers, Jonatan From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 27 May 2020 10:45 To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Ken, One of the most well working part of CMSIS is the compiler abstraction layer: * It does wat is needed. * Most functionality can not be coded in a different way (i.e. intrinsics). * It became a de-facto standard and most compilers support it. What are the benefits driving re-implementation? /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 27 May 2020 02:39 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] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Jamie, At the current stage: * The CMSIS headers dependency has been moved into HAL, the SPM native code would not rely on specific system provided definitions. * These usages are quite TF-M specific and small so there is less significance to upstream back, we can revisit if need to do this after extended the header content - but this extending is out of original design expectation. BR /Ken From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Tuesday, May 26, 2020 10:52 PM To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Ken, Many similar abstractions for compiler C language extensions are provided by cmsis_compiler.h, already copied into the TF-M code base. If it does not meet all of our needs, should we consider proposing improvements to the upstream CMSIS project? Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 25 May 2020 05:02 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] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi, We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code. Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers. Special usage such as 'weak' or 'noreturn' are forbidden inside SPM. Please put comments for this change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211 Or reply here. This is just an example patch, the follow up would apply this defined headers to all SPM sources. Thanks /Ken

5 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M