Hi Thomas,
The diff below is caused by this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/3942 .
REGION_NAME is used to pasting the input parameters into a string. So there should be no difference between Image$$ARM_LIB_STACK_MSP$$ZI$$Base and REGION_NAME(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base) basing on the current implementation of REGION_NAME in file platform/include/region.h
So, is there a specific REGION_NAME macro implementation for IAR compiler? Or the automatically generated region related symbols are with different names in IAR compiler?
Regards,
Sherry Zhang
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: Tuesday, April 28, 2020 4:58 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] REGION_DECLARE macros
I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software.
Trying another type:
/* Set Main Stack Pointer limit */
- extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
- __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base);
+ __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+ $$ZI$$Base));
Den 2020-04-28 kl. 10:51, skrev Thomas T�rnblom via TF-M:
With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base".
The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains.
Example diff:
---
���� /* Set Main Stack Pointer limit */
-��� extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
-��� __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+��� REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,� $$ZI$$Base);
+��� __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+��������������������������������������� $$ZI$$Base));
---
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>
I have no idea what causes the crap characters in the diff below, they
should be blanks. Looks like a problem with the mailing list software.
Trying another type:
/* Set Main Stack Pointer limit */
- extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
- __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base);
+ __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+ $$ZI$$Base));
Den 2020-04-28 kl. 10:51, skrev Thomas Törnblom via TF-M:
> With the integration of the IAR toolchain support in TF-M it has
> become important to use the REGION_DECLARE/REGION_NAME macros in
> platform/region.h instead of using symbols like
> "Image$$ARM_LIB_STACK_MSP$$ZI$$Base".
>
> The IAR linker can not use these symbols and the macros in combination
> with the IAR specific cmake rules creates appropriate symbols for all
> the supported toolchains.
>
> Example diff:
> ---
> ���� /* Set Main Stack Pointer limit */
> -��� extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
> -��� __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
> +��� REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,� $$ZI$$Base);
> +��� __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
> +���������������������������������������
> $$ZI$$Base));
> ---
>
> 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>
With the integration of the IAR toolchain support in TF-M it has become
important to use the REGION_DECLARE/REGION_NAME macros in
platform/region.h instead of using symbols like
"Image$$ARM_LIB_STACK_MSP$$ZI$$Base".
The IAR linker can not use these symbols and the macros in combination
with the IAR specific cmake rules creates appropriate symbols for all
the supported toolchains.
Example diff:
---
/* Set Main Stack Pointer limit */
- extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
- __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base);
+ __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+ $$ZI$$Base));
---
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>
I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled.
However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime.
Reinhard
Hi Reinhard
I think the closer to a high level documentation is this page:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
To your question regarding the nv counters, they are currently used by MCUBOOT and Protected Storage Service. You may be interested in this patch under review which is will expose them as a service
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3367
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Reinhard Keil via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 27 April 2020 16:07
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Documentation for platform interfaces
Is there somewhere a high-level documentation for the platform interfaces that are here:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/includ…
What are the dependencies of the services to the platform files?
For example, when is nv_counters used?
Reinhard
Hi Anton,
I would like to give a brief introduction for a mechanism which would improve the coding efficiency and performance for RoT Service API by avoiding 'psa_connect'/'psa_close'.
BR.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Thursday, April 23, 2020 3:29 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - April 30
Hello,
The next Technical Forum is planned on Thursday, April 30 at 7:00-8:00 UTC.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hi Raymond,
Sorry for the trouble. Sorry that I cannot find a Crypto test case with index 250.
Could you please share more details and error logs of this test case?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M
Sent: Monday, April 27, 2020 10:26 AM
To: tf-m(a)lists.trustedfirmware.org; Jamie Fox <Jamie.Fox(a)arm.com>
Subject: [TF-M] PSA Crypto failure with addition of persistent keys
Hi Jamie,
With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack.
Thank you,
Ray
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.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Jamie,
With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack.
Thank you,
Ray
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.
Looks no more feedbacks. We will start creating it and call for review when finished.
Issue created for collecting comments: https://developer.trustedfirmware.org/T720
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Thursday, April 9, 2020 4:32 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [RFC] The veneer usage under library model (Ken Liu)
Hi Reinhard,
Thanks for your feedback, and let's see if others would give more comments.
Will broadcast the implementation after it is created. Before that we need to know if some users (especially those developing secure partitions under library model) got comments on this.
Also, I think this update could help the first point in your list.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Reinhard Keil via TF-M
Sent: Thursday, April 9, 2020 2:57 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] [RFC] The veneer usage under library model (Ken Liu)
Ken,
This is the answer to "What do you think about this update?"
When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine.
I made some suggestions here
https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html
I would be happy to review your implementation in case that you have doubts.
Best regards
Reinhard
