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
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
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.
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>
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
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
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
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
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
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)
