- TF-M - lists.trustedfirmware.org

Feature 'Custom code generating scripts with Jinja2' has been merged

by Ken Liu (Arm Technology China)

Hi, The patch for applying Jinja2 to generate custom code has been merged into branch 'master'. With these two patches, scatter loader template are also supported. IMPORTANT: Please install Jinja2 before using this feature. You can check ' docs/user_guides/tfm_sw_requirement.md' for installation. Thanks. -Ken > -----Original Message----- > From: Ken Liu (Arm Technology China) > Sent: Tuesday, March 19, 2019 7:09 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: Replace custom code generating scripts with Jinja2 > > Hi, > I saw there is no concern raised about applying Jinja2 into TF-M project, and > some code review is done on these patches. > Plan to merge it at end of Mar 19th, if you have something please just shout 😉 > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ > > Thanks > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Wednesday, January 23, 2019 2:18 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [Tf-m] Replace custom code generating scripts with Jinja2 > > > > Hi Mate, > > I have checked your change and the document, it looks quite easy to > > support conditional including. > > I am OK for this tool. > > > > Thanks. > > > > -Ken > > > > From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > > Sent: Monday, January 21, 2019 9:35 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: Replace custom code generating scripts with Jinja2 > > > > > > Hi Mate, > > > > Thanks for the proposal. It looks nice. > > > > I have read the "Improvements over the current solution" part and I > > think the "More advanced functionality" is the point I am interested > > in. There are some necessary jobs to be done in the code generating > > scripts for IPC; hope using this tool could help on that. One thing we are > investigating is: > > > > * We need to put PSA RoT and APP RoT into different groups in linker script; > > current tool just put all partitions together and ignores partition type. > > > > > > > > Can you help to check if the new tool could make this change easier? > > > > > > > > Thanks. > > > > > > -Ken > > > > ________________________________ > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > > bounces(a)lists.trustedfirmware.org>> on behalf of Mate Toth-Pal via > > TF-M <tf- > > m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> > > Sent: Monday, January 21, 2019 8:37:58 PM > > To: > > tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > > Cc: nd > > Subject: [Tf-m] Replace custom code generating scripts with Jinja2 > > > > Hi All, > > > > Based on the design proposal published here: > > https://developer.trustedfirmware.org/w/tf_m/design/code_generation_wi > > th_j inja2/ I am planning to replace the code generation tool > > currently used in the TF- M with the Jinja2 template engine. > > > > I already prepared the change that implements this. It is available > > for review and testing in this gerrit review: > > https://review.trustedfirmware.org/#/c/trusted- > > firmware-m/+/507/ > > > > Please note, that this introduces a new tool dependency: jinja2 v2.10 > > python library have to be installed to generate code from the > > partition manifests. Earlier than 2.10 versions won't work, as one of > > the templates relies on the namespace feature introduced in this version. > > > > Based on this change I also would like to make the secure sct files > > automatically generated (just like the secure ld files). The gerrit review for this > change is here: > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ > > > > Should you have any questions, suggestions, objections, please do not > > hesitate to contact! > > > > Thanks, > > Mate > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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

7 years, 3 months

1
0
0 0

Re: [TF-M] IPC and clang

by Edison Ai (Arm Technology China)

Hi Andrej, We tested the IPC works on Musca A but not try it on Musca B yet. The current IPC related patches are used to enable IPC mechanism, but services such as crypto, protect storage and attestation are yet to make use of IPC. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 6:06 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, OK. So, according to https://review.trustedfirmware.org/c/trusted-firmware-m/+/463/ the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- 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… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

Re: [TF-M] Replace custom code generating scripts with Jinja2

by Ken Liu (Arm Technology China)

Hi, I saw there is no concern raised about applying Jinja2 into TF-M project, and some code review is done on these patches. Plan to merge it at end of Mar 19th, if you have something please just shout 😉 https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Wednesday, January 23, 2019 2:18 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [Tf-m] Replace custom code generating scripts with Jinja2 > > Hi Mate, > I have checked your change and the document, it looks quite easy to support > conditional including. > I am OK for this tool. > > Thanks. > > -Ken > > From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Sent: Monday, January 21, 2019 9:35 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: Replace custom code generating scripts with Jinja2 > > > Hi Mate, > > Thanks for the proposal. It looks nice. > > I have read the "Improvements over the current solution" part and I think the > "More advanced functionality" is the point I am interested in. There are some > necessary jobs to be done in the code generating scripts for IPC; hope using this > tool could help on that. One thing we are investigating is: > > * We need to put PSA RoT and APP RoT into different groups in linker script; > current tool just put all partitions together and ignores partition type. > > > > Can you help to check if the new tool could make this change easier? > > > > Thanks. > > > -Ken > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > bounces(a)lists.trustedfirmware.org>> on behalf of Mate Toth-Pal via TF-M <tf- > m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> > Sent: Monday, January 21, 2019 8:37:58 PM > To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > Cc: nd > Subject: [Tf-m] Replace custom code generating scripts with Jinja2 > > Hi All, > > Based on the design proposal published here: > https://developer.trustedfirmware.org/w/tf_m/design/code_generation_with_j > inja2/ I am planning to replace the code generation tool currently used in the TF- > M with the Jinja2 template engine. > > I already prepared the change that implements this. It is available for review and > testing in this gerrit review: https://review.trustedfirmware.org/#/c/trusted- > firmware-m/+/507/ > > Please note, that this introduces a new tool dependency: jinja2 v2.10 python > library have to be installed to generate code from the partition manifests. Earlier > than 2.10 versions won't work, as one of the templates relies on the namespace > feature introduced in this version. > > Based on this change I also would like to make the secure sct files automatically > generated (just like the secure ld files). The gerrit review for this change is here: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ > > Should you have any questions, suggestions, objections, please do not hesitate > to contact! > > Thanks, > Mate > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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

7 years, 3 months

1
0
0 0

Re: [TF-M] IPC and clang

by Andrej Butok

Hi Edison, OK. So, according to https://review.trustedfirmware.org/c/trusted-firmware-m/+/463/ the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- 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…

7 years, 3 months

1
0
0 0

Re: [TF-M] IPC and clang

by Edison Ai (Arm Technology China)

Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/677/-1..2. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/463/. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

IPC and clang

by Andrej Butok

Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok

7 years, 3 months

1
0
0 0

[RFC] IPC scheduler on AN519

by Ken Liu (Arm Technology China)

Hi, A patch is submitted to support IPC scheduler on AN519; which makes IPC work for baseline: https://review.trustedfirmware.org/c/trusted-firmware-m/+/715 Please help to take a review on it. Thanks ; ) -Ken

7 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] twin cpu bootloader design document

by David Brown

On Thu, Mar 14, 2019 at 06:51:04PM +0000, Christopher Brand via TF-M wrote: >I've posted a design document for bootloader changes to support twin >cpu at >https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ There are efforts underway to get the TF-M changes to the bootloader contributed back to the upstream MCUboot project. We should be trying to make sure that we continue this effort, as well as to make sure that any efforts to extend the bootloader are done upstream, and not in the TF-M-specific branch. Are you expecting to be running the non-secure CPU before the secure CPU has finished verifying the images? David

7 years, 3 months

2
3
0 0

Fix for issue T276 has been merged

by Ken Liu (Arm Technology China)

Hi, Fix for the issue 'stacking issue in psa_call when FP was enabled' has been merged: https://review.trustedfirmware.org/c/trusted-firmware-m/+/713/ And the issue: https://developer.trustedfirmware.org/T276 This commit fixes the problem while hardware FP is enabled, 5th parameter fetching problem for psa_call(). Please check the latest master branch to get the fix. Thanks. -Ken

7 years, 3 months

1
0
0 0

[RFC] twin cpu bootloader design document

by Christopher Brand

Hi, I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ Comments appreciated! Thanks, Chris 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.

7 years, 3 months

1
0
0 0

[Core Patch] Core: switch signal wait object to 'condition'

by Ken Liu (Arm Technology China)

Hi, I will update the wait object from 'event' to 'condition'. This is mainly for fixing the issue: https://developer.trustedfirmware.org/T273 'event' is actually a depth 1 semaphore, which is not good enough for signals synching case. Involve a simpler sync object 'condition' for signals (and client ACKs): https://review.trustedfirmware.org/c/trusted-firmware-m/+/712 Please help to check if you are interested in it. Thanks -Ken

7 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' is happening

by Ken Liu (Arm Technology China)

Hi Alan, Expected to be merged before end of Mar 13th if there is no more raised concern ;) -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Tuesday, March 12, 2019 11:27 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' > is happening > > Yay! When? > > > On Mar 11, 2019, at 6:57 PM, Ken Liu (Arm Technology China) via TF-M <tf- > m(a)lists.trustedfirmware.org> wrote: > > > > Hi TF-M Subscribers, > > The branch 'feature-ipc' is going to be merged into 'master', and here is the > patch: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 > > > > After the merging, the IPC feature will be available in the 'master' branch, > future updates on the IPC part will happen in 'master' branch, too. > > For those patches pushed towards 'feature-ipc' will be reviewed and we > suggest push new patchset to 'master' branch. > > > > Please reply to this thread without hesitation if there are any questions. > > > > Thanks. > > > > -Ken > > -- > > 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

7 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' is happening

by DeMars, Alan

Yay! When? > On Mar 11, 2019, at 6:57 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi TF-M Subscribers, > The branch 'feature-ipc' is going to be merged into 'master', and here is the patch: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 > > After the merging, the IPC feature will be available in the 'master' branch, future updates on the IPC part will happen in 'master' branch, too. > For those patches pushed towards 'feature-ipc' will be reviewed and we suggest push new patchset to 'master' branch. > > Please reply to this thread without hesitation if there are any questions. > > Thanks. > > -Ken > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

Branches merging from 'feature-ipc' to 'master' is happening

by Ken Liu (Arm Technology China)

Hi TF-M Subscribers, The branch 'feature-ipc' is going to be merged into 'master', and here is the patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 After the merging, the IPC feature will be available in the 'master' branch, future updates on the IPC part will happen in 'master' branch, too. For those patches pushed towards 'feature-ipc' will be reviewed and we suggest push new patchset to 'master' branch. Please reply to this thread without hesitation if there are any questions. Thanks. -Ken

7 years, 3 months

1
0
0 0

TF-M v1.0-Beta Blog

by Shebu Varghese Kuriakose

Hi, Here is a blog on the recent TF-M tag v1.0-Beta and how it enables PSA certification https://www.trustedfirmware.org/blog/Trusted-Firmware-M-v10-Beta-Enabling-P… Regards, Shebu

7 years, 3 months

1
0
0 0

Re: [TF-M] Trusted boot - rollback protection

by David Brown

On Mon, Mar 11, 2019 at 01:43:19PM +0000, Tamas Ban via TF-M wrote: >https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p… Oh, and a little terminology comment about the Trusted non-volatile (NV) counters. This section should use "increase" and "decrease" not "increment" and "decrement". There is no requirement that the counter only be incremented (having 1 added to the value), only that it be set to a larger value than the current value. You should probably also add a discussion as to how testing will be done with a HW security counter. Again, my suggestion is to not add an additional counter, but just use the existing version field (minus the build number) as the security counter value. David

7 years, 3 months

1
0
0 0

Trusted boot - rollback protection

by Tamas Ban

Hi all, Please see the following link for a design proposal on anti-rollback protection in trusted boot: https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p… Comments are welcome! Regards Tamas Ban

7 years, 3 months

1
0
0 0

Re: [TF-M] multiple services within the same SP

by Andrew Thoelke

Hi Alan, I can answer this from the PSA Firmware Framework specification point of view, Ken (or others in the TF-M team) can clarify how closely the TF-M behaviour matches this. In the manifest each service has a "signal" attribute which is a C identifier that is given the signal value for that service. The value is allocated by the TF-M tools and should be available to the SP source code via a generated header file - the specification places these definitions in the psa_manifest/<manifestfilename>.h header file, matching the name of the manifest file itself. When the SP receives a set of signals from psa_wait(), it can identify which signals are asserted using these identifiers to test the signal bits. The example RoT Service in Appendix D of the PSA Firmware Framework demonstrates this. Regards, Andrew -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 08 March 2019 13:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] multiple services within the same SP In a multi-service SP, how does the SP know which SID has been used to connect to it? -- 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.

7 years, 3 months

1
0
0 0

Re: [TF-M] multiple services within the same SP

by Ken Liu (Arm Technology China)

Hi Alan, Services are listed in SP. SPM could enumerate the services in a SP by the list. You can check the member variable ' service_list' of ' tfm_spm_ipc_partition_t' to know details. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Friday, March 8, 2019 9:52 PM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] multiple services within the same SP > > In a multi-service SP, how does the SP know which SID has been used to connect > to it? > -- > 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.

7 years, 3 months

1
0
0 0

multiple services within the same SP

by DeMars, Alan

In a multi-service SP, how does the SP know which SID has been used to connect to it?

7 years, 3 months

1
0
0 0

Re: [TF-M] META: TF-M Mailing list configuration

by Bill Fletcher

Hi David, Thanks for raising this. I'll contact you directly to review the Mailman configuration. Regards Bill On Thu, 28 Feb 2019, 05:04 David Brown via TF-M, < tf-m(a)lists.trustedfirmware.org> wrote: > I have noticed that this mailing list seems to be configured in a > non-ideal way. > > Primarily, the messages are sent from the list address itself, and a > reply-to header is inserted for the original sender. This at least > often will allow someone to reply to the original sender. > > There are a few problems with this. One is that this tends to break > messages that have been copied to more than one list, especially for > recipients who subscribe to both lists. Admittedly it is better than > the all-to-common practice of setting Reply-to to the list itself, > which effectively steals all replies from any other recipients or > lists that were originally included. > > Secondly, however, this kind of violates the intent of the reply-to > field, which was intended for the originator of the message to be able > to give an alternative address they wish for replies to go to. > > I don't know how this list is hosted, and usually this kind of > configuration results from an ISP that rejects messages. But, I know > a lot of mailing lists are managed with mailman without these > problems, so it should be possible to get this working in a more > homogenous way. > > Lists admins, feel free to contact me if you want any assistance in > trying to configure the list better. > > Thanks, > David > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

7 years, 4 months

1
0
0 0

META: TF-M Mailing list configuration

by David Brown

I have noticed that this mailing list seems to be configured in a non-ideal way. Primarily, the messages are sent from the list address itself, and a reply-to header is inserted for the original sender. This at least often will allow someone to reply to the original sender. There are a few problems with this. One is that this tends to break messages that have been copied to more than one list, especially for recipients who subscribe to both lists. Admittedly it is better than the all-to-common practice of setting Reply-to to the list itself, which effectively steals all replies from any other recipients or lists that were originally included. Secondly, however, this kind of violates the intent of the reply-to field, which was intended for the originator of the message to be able to give an alternative address they wish for replies to go to. I don't know how this list is hosted, and usually this kind of configuration results from an ISP that rejects messages. But, I know a lot of mailing lists are managed with mailman without these problems, so it should be possible to get this working in a more homogenous way. Lists admins, feel free to contact me if you want any assistance in trying to configure the list better. Thanks, David

7 years, 4 months

1
0
0 0

Re: [TF-M] SecureFault when starting the OS

by Antonio De Angelis

Hi Thomas, Thanks for the feedback. An additional question from me to understand better the issue: are you rebuilding RTX from source, not using the pre-built binaries distributed with CMSIS_5? Since this commit: https://github.com/ARM-software/CMSIS_5/commit/8bce76b03565359f31cd20ed86c2… CMSIS_5 has changed from using __DOMAIN_NS to DOMAIN_NS macro for better MISRA compliance. I think to officially support newer releases of CMSIS, we should update our instructions and define DOMAIN_NS in addition to __DOMAIN_NS, as this define will come into picture for integrations which actually rebuild RTX from the CMSIS_5 repo sources. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 26 February 2019 09:58 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] SecureFault when starting the OS Thanks Miklos and Antonio, You were both spot on. Turned out I had not define DOMAIN_NS=1, which change the last byte from FD to BC. I need to figure out why I need to add that when the documentation says __DOMAIN_NS=1 should be sufficient. Cheers, /Thomas Den 2019-02-25 kl. 17:13, skrev Antonio De Angelis via TF-M: > Hi Thomas, > > As you correctly identified, the value of the EXC_RETURN is not appropriate for the state the exception was taken from. As a quick double check, you can set it manually from a debugger to 0xFFFFFFBC before the exception return takes place and in that case the exception return will happen correctly. You can find more details on the meaning of each bit of the EXC_RETURN register at the following link: https://static.docs.arm.com/100701/0100/armv8_m_processor_exception_handlin… (section 1.10). > > In general, once TF-M has finished booting and has jumped to the NS state, the OS initialisation should take place (you can see as an example in the NS app how the RTX kernel initialisation happens). If the OS manipulates directly the Link Register, it needs to be aware that it's running from the NS state (this can imply a build time configuration step) so that it will set up correctly the default value of the EXC_RETURN when an exception happens. You can find more details in docs/user_guides/os_migration_guide_armv8m.md . > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Thomas Törnblom via TF-M > Sent: 25 February 2019 15:34 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] SecureFault when starting the OS > > In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code. > > I'm now running into an issue where I get a SecureFault when attempting to start the OS. > > The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault. > > SFSR indicates that it is an INVER (Invalid Exception Return): > --- > Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are: > 0 Error has not occurred. > 1 Error has occurred. > -- > > LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception. > > What am I missing here? > > Is the OS supposed to be started from NS mode? > > I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, > ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs. > > Thanks, > /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> > -- > 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. -- *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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 4 months

1
0
0 0

Re: [TF-M] SecureFault when starting the OS

by Thomas Törnblom

Thanks Miklos and Antonio, You were both spot on. Turned out I had not define DOMAIN_NS=1, which change the last byte from FD to BC. I need to figure out why I need to add that when the documentation says __DOMAIN_NS=1 should be sufficient. Cheers, /Thomas Den 2019-02-25 kl. 17:13, skrev Antonio De Angelis via TF-M: > Hi Thomas, > > As you correctly identified, the value of the EXC_RETURN is not appropriate for the state the exception was taken from. As a quick double check, you can set it manually from a debugger to 0xFFFFFFBC before the exception return takes place and in that case the exception return will happen correctly. You can find more details on the meaning of each bit of the EXC_RETURN register at the following link: https://static.docs.arm.com/100701/0100/armv8_m_processor_exception_handlin… (section 1.10). > > In general, once TF-M has finished booting and has jumped to the NS state, the OS initialisation should take place (you can see as an example in the NS app how the RTX kernel initialisation happens). If the OS manipulates directly the Link Register, it needs to be aware that it's running from the NS state (this can imply a build time configuration step) so that it will set up correctly the default value of the EXC_RETURN when an exception happens. You can find more details in docs/user_guides/os_migration_guide_armv8m.md . > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M > Sent: 25 February 2019 15:34 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] SecureFault when starting the OS > > In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code. > > I'm now running into an issue where I get a SecureFault when attempting to start the OS. > > The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault. > > SFSR indicates that it is an INVER (Invalid Exception Return): > --- > Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are: > 0 Error has not occurred. > 1 Error has occurred. > -- > > LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception. > > What am I missing here? > > Is the OS supposed to be started from NS mode? > > I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, > ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs. > > Thanks, > /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> > -- > 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. -- *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>

7 years, 4 months

1
0
0 0

Re: [TF-M] SecureFault when starting the OS

by Antonio De Angelis

Hi Thomas, As you correctly identified, the value of the EXC_RETURN is not appropriate for the state the exception was taken from. As a quick double check, you can set it manually from a debugger to 0xFFFFFFBC before the exception return takes place and in that case the exception return will happen correctly. You can find more details on the meaning of each bit of the EXC_RETURN register at the following link: https://static.docs.arm.com/100701/0100/armv8_m_processor_exception_handlin… (section 1.10). In general, once TF-M has finished booting and has jumped to the NS state, the OS initialisation should take place (you can see as an example in the NS app how the RTX kernel initialisation happens). If the OS manipulates directly the Link Register, it needs to be aware that it's running from the NS state (this can imply a build time configuration step) so that it will set up correctly the default value of the EXC_RETURN when an exception happens. You can find more details in docs/user_guides/os_migration_guide_armv8m.md . Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 25 February 2019 15:34 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] SecureFault when starting the OS In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code. I'm now running into an issue where I get a SecureFault when attempting to start the OS. The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault. SFSR indicates that it is an INVER (Invalid Exception Return): --- Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are: 0 Error has not occurred. 1 Error has occurred. -- LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception. What am I missing here? Is the OS supposed to be started from NS mode? I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs. Thanks, /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> -- 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.

7 years, 4 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M