Hi Alan,
Is it OK for you to commit this change?
-Ken
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars,
> Alan via TF-M
> Sent: Wednesday, April 3, 2019 5:50 AM
> To: Michel JAOUEN <michel.jaouen(a)st.com>
> Cc: tf-m(a)lists.trustedfirmware.org
> Subject: Re: [TF-M] build with GNUARM with option -Os
>
> I had a similar problem. Upon advice in this email list, I fixed it by changing the
> implementation of "tfm_core_ns_ipc_request()" in
> secure_fw/core/tfm_psa_api_client.c.
>
> Add 'volatile' to the declaration of these variables:
>
> struct tfm_sfn_req_s desc, *desc_ptr = &desc;
>
> change to:
>
> volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc;
>
> After this change, I am able to build and run with -O3 as well as -Os.
>
> I don't know why this fix hasn't been added to the master branch as this problem
> has already been identified.
>
> Alan
>
> -----Original Message-----
> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of
> Michel JAOUEN via TF-M
> Sent: Tuesday, April 02, 2019 4:11 AM
> To: tf-m(a)lists.trustedfirmware.org
> Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os
>
> Hello,
> I tested my board port on top of
> 1c266ae74bd93c2ef290e9aac0caecf92b06b93d
> Without option -Os , the tests with ConfigCoreIPC.cmake are passed .
> When I put the option -Os , 1st test is failing in Hardware Fault.
>
> For info, the test with ConfigRegression.cmake and option -Os is passed .
>
> With the configuration -Os , code footprint is much better.
>
> Is it plan to activate this option in master ? Is the same issue reproduced on
> another board ?
>
> Best regards
>
> --
> 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
I had a similar problem. Upon advice in this email list, I fixed it by changing the implementation of "tfm_core_ns_ipc_request()" in secure_fw/core/tfm_psa_api_client.c.
Add 'volatile' to the declaration of these variables:
struct tfm_sfn_req_s desc, *desc_ptr = &desc;
change to:
volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc;
After this change, I am able to build and run with -O3 as well as -Os.
I don't know why this fix hasn't been added to the master branch as this problem has already been identified.
Alan
-----Original Message-----
From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Michel JAOUEN via TF-M
Sent: Tuesday, April 02, 2019 4:11 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os
Hello,
I tested my board port on top of 1c266ae74bd93c2ef290e9aac0caecf92b06b93d
Without option -Os , the tests with ConfigCoreIPC.cmake are passed .
When I put the option -Os , 1st test is failing in Hardware Fault.
For info, the test with ConfigRegression.cmake and option -Os is passed .
With the configuration -Os , code footprint is much better.
Is it plan to activate this option in master ? Is the same issue reproduced on another board ?
Best regards
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hello,
I tested my board port on top of 1c266ae74bd93c2ef290e9aac0caecf92b06b93d
Without option -Os , the tests with ConfigCoreIPC.cmake are passed .
When I put the option -Os , 1st test is failing in Hardware Fault.
For info, the test with ConfigRegression.cmake and option -Os is passed .
With the configuration -Os , code footprint is much better.
Is it plan to activate this option in master ? Is the same issue reproduced on another board ?
Best regards
Hi Antonio,
Ok, so the TFM is using the old API.
Hope, it will be updated soon. I prefer do not downgrade the test suite from master, as it contains >50 of new commits.
Thanks,
Andrej
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Monday, April 1, 2019 11:24 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] PSA Test Suite forum?
Hi Andrej,
I have replied on the GitHub issue as well, copy-pasting my reply below:
TF-M uses a version of the API which is marked 0.1.0b. The psa-arch-tests, on the master branch, have moved to use a newer version of the API, while on the branch marked ew_beta0 they use the version of the API compatible with the one TF-M uses, hence TF-M PSA API compliance needs to be tests using the ew_beta0 branch. Work is ongoing on TF-M side to move to newer versions of the API.
Thanks,
Antonio
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu (Arm Technology China) via TF-M
Sent: 01 April 2019 09:14
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: Re: [TF-M] PSA Test Suite forum?
Andrej,
Yes, the PSA test suite was developed by different team.
If it is a common topic, you can report the issue at any of the site, then we will sync it internal.
Thanks.
Best Regards,
Qixiang Xu
-----Original Message-----
From: Andrej Butok <andrey.butok(a)nxp.com>
Sent: Monday, April 1, 2019 3:59 PM
To: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: RE: PSA Test Suite forum?
Hi Qixiang Xu,
I have added https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
Not sure, what forum to use if it is a common topic related to both TFM and Test-suite. Is the PSA test suite developed by other independent team?
Thanks,
Andrej
-----Original Message-----
From: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com>
Sent: Monday, April 1, 2019 9:41 AM
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: RE: PSA Test Suite forum?
Andrej,
You can report any issue or concern at:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
Best Regards,
Qixiang Xu
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Monday, April 1, 2019 3:29 PM
To: TF-M(a)lists.trustedfirmware.org
Subject: [TF-M] PSA Test Suite forum?
Hello,
Do you have a forum dedicated to the PSA Test-suite (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… )?
Or we may use this one?
Thanks
Andrej
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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.
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.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
Hi Andrej,
I have replied on the GitHub issue as well, copy-pasting my reply below:
TF-M uses a version of the API which is marked 0.1.0b. The psa-arch-tests, on the master branch, have moved to use a newer version of the API, while on the branch marked ew_beta0 they use the version of the API compatible with the one TF-M uses, hence TF-M PSA API compliance needs to be tests using the ew_beta0 branch. Work is ongoing on TF-M side to move to newer versions of the API.
Thanks,
Antonio
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu (Arm Technology China) via TF-M
Sent: 01 April 2019 09:14
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: Re: [TF-M] PSA Test Suite forum?
Andrej,
Yes, the PSA test suite was developed by different team.
If it is a common topic, you can report the issue at any of the site, then we will sync it internal.
Thanks.
Best Regards,
Qixiang Xu
-----Original Message-----
From: Andrej Butok <andrey.butok(a)nxp.com>
Sent: Monday, April 1, 2019 3:59 PM
To: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: RE: PSA Test Suite forum?
Hi Qixiang Xu,
I have added https://github.com/ARM-software/psa-arch-tests/issues/79
Not sure, what forum to use if it is a common topic related to both TFM and Test-suite. Is the PSA test suite developed by other independent team?
Thanks,
Andrej
-----Original Message-----
From: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com>
Sent: Monday, April 1, 2019 9:41 AM
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: RE: PSA Test Suite forum?
Andrej,
You can report any issue or concern at:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
Best Regards,
Qixiang Xu
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Monday, April 1, 2019 3:29 PM
To: TF-M(a)lists.trustedfirmware.org
Subject: [TF-M] PSA Test Suite forum?
Hello,
Do you have a forum dedicated to the PSA Test-suite (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… )?
Or we may use this one?
Thanks
Andrej
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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.
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.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Andrej,
You can report any issue or concern at:
https://github.com/ARM-software/psa-arch-tests/issues
Best Regards,
Qixiang Xu
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Monday, April 1, 2019 3:29 PM
To: TF-M(a)lists.trustedfirmware.org
Subject: [TF-M] PSA Test Suite forum?
Hello,
Do you have a forum dedicated to the PSA Test-suite (https://github.com/ARM-software/psa-arch-tests )?
Or we may use this one?
Thanks
Andrej
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
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,
The isolation level 2 patches are pushed for reviewing; you can find all of them under the issue:
https://developer.trustedfirmware.org/T294
The design document was put at:
https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol…
The first group of patches are working on AN521 with ARMCLANG build. Rest options supporting would come later.
With higher isolation level, some functions may not work such as CLIB (malloc/free e.g.). These features need to be supported after dedicated implementation is done. You can check the [RFC] discussion sent in mailing list of the isolation level 2 for details. Isolation level 2 use dedicated config file: "ConfigCoreIPCTfmLevel2.cmake" so the IPC on isolation level 1 is not affected by this change.
Please help to comment in documents and patches - current the document has no comment area so you can put comments under the issue link, or just reply in mailing list. Creating issues is another valid options ; )
Thanks!
-Ken
Yes, that idea would resolve the problem.
I’m not sure I understand the use case for multiple updates to a context’s client Id. What is the thought behind that?
Alan
> On Mar 28, 2019, at 2:23 AM, Miklos Balint via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Alan,
>
> You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule.
>
> The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one.
>
> I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one.
> This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated.
>
> Is this an acceptable amendment?
>
> Regards
> Miklos
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
> Sent: 26 March 2019 00:00
> To: tf-m(a)lists.trustedfirmware.org
> Subject: [TF-M] Please explain tfm_register_client_id() use case
>
> As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread.
>
> It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId.
>
> However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful.
>
> What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once).
>
> Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base.
>
> Alan
>
>
> --
> 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