- TF-M - lists.trustedfirmware.org

by Thomas Törnblom

I have just uploaded the first of a set of changes to allow building TF-M with the IAR toolchain. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2560 Please review. 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>

5 years, 11 months

1
0
0 0

Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode

by DeMars, Alan

I don't know that the SPE needs to be restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. I just assumed that these 2 rules required it: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR (I assumed that this rule applies to the SP while it is processing the ISR as well). Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 12:58 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have one question, why the SPE needs restored to its IDLE state prior to a thread pre-empting NS interrupt occurring? About a secure interrupt is configured with a lower priority than pendsv, I do not think it is a good idea. The pendsv is used to trigger the scheduler to switch thread. The normal interrupt process should like this: Interrupt happen -> jump into related ISR -> do necessary process such as mask interrupt status, send even or signal to related SP. -> set pendsv to trigger scheduler -> jump out ISR -> scheduler to decide which thread to run. In these sequences, if there are many interrupts happen at the same time, and high priority interrupt will interrupt low priority interrupt. Each ISR will trigger pendsv. But only one pendsv hander function needs to be processed. If we set the pendsv with high priority. Each interrupt will trigger pendsv and the pendsv handler will be processed every time. It will be more complex and spend more CPU time. Sorry that I do not know what is your detail scenario, and it will be more clear and helpful if you can provide more information. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 3:12 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have created the cooperative scheduling doc link here for comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2466 BR /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:44 AM To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: Re: [EXTERNAL] RE: secure interrupt handlng in IPC mode Mate, Apart from the surprising behavior actually working to my benefit, my concern is the implications of violating the Cooperative Scheduling Rules I quoted below. The normal behavior (ie the SP running in thread mode with no exception priority when servicing a secure interrupt) seems to violate those rules. Is this a problem for the scheduler? Alan > On Nov 13, 2019, at 5:08 AM, Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> wrote: > > Hi Alan, > > That's a quite difficult question I think. > > At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. > > However implementing this seems to be a nontrivial task. > > The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. > > The phenomenon we observed with your setup was the following: > 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. > 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. > 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. > 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' > > Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. > > To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. > > The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. > > Regards, > Mate > > From: DeMars, Alan <ademars(a)ti.com> > Sent: 12 November 2019 17:47 > To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> > Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Subject: RE: secure interrupt handlng in IPC mode > > You can CC the tf-m mailing list. > > From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] > Sent: Tuesday, November 12, 2019 8:02 AM > To: DeMars, Alan > Cc: Ken Liu (Arm Technology China) > Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode > > Hi Alan > > Would it be OK to you if I cc the TF-M mailing list in my answer? > > Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. > > Thanks, > Mate > > > From: DeMars, Alan <mailto:ademars@ti.com> > Sent: 11 November 2019 21:05 > To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> > Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> > Subject: secure interrupt handlng in IPC mode > > Hi Mate! > > I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. > > I think the below statements in the Cooperative Scheduling Rules discussion: > > a. All of the SPE interrupts must have higher priority than NSPE > interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must > extend to the priority level of the SP as it services the interrupt while in thread mode. > > Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. > > So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. > > Is this correct thinking? > > Alan > > 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

2
1
0 0

Re: [TF-M] Commonly accepted default documentation layout

by Christopher Brand

I think you're right that we need some rules like this, and the list below looks reasonable to me. The list should probably be a document in its own right... Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos > Galanakis via TF-M > Sent: Thursday, November 14, 2019 3:14 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Commonly accepted default documentation layout > > Hi > > With our documentation growing, and more people contributing to it, it is > quite essential to start a discussion on some basic commonly accepted rules > about the format of choice. > > Restructured text allows you to achieve similar looking results using multiple > approaches, but this makes it harder for tools like Sphinx to render properly, > since the rendering template can be applied on per project basis, not on a > per file basis. > I took the liberty of investigating the existing documentation, and mostly > looking for top level headers which can be done by using either > > > > #################### > > This is a top-level header > > #################### > > # Reference docs: > # design_documents/tfm_its_service.rst > # design_documents/secure_boot_hw_key_integration.rst > > # Reference docs: > # user_guides/tfm_secure_boot.rst > # user_guides/tfm_user_guide.rst > > > > > > or > > > ==================== > This is a top level header > ==================== > > # Reference docs: > # design_documents/tfm_its_service.rst > # design_documents/secure_boot_hw_key_integration.rst > > > > > Since we are looking for the path of least resistance, I would like to propose > that we follow the format the majority of document uses.This is the format > used in > `user_guides/tfm_user_guide.rst<https://git.trustedfirmware.org/trusted- > firmware-m.git/plain/docs/user_guides/tfm_user_guide.rst>` . > > When writing a document and coming across a requirement that has not > been defined yet, we should be aiming for compliance with official Python > guidelines<https://devguide.python.org/documenting/#style-guide> which > is the most commonly used notation. > > 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, if 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 go deeper 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). See the current version of the > `/user_guides/tfm_sw_requirement.rst<https://git.trustedfirmware.org/tru > sted-firmware-m.git/plain/docs/user_guides/tfm_sw_requirement.rst>` > and the proposed patch<https://review.trustedfirmware.org/c/trusted- > firmware-m/+/2456> > > Please let me know if you have any questions/objection or proposals or new > rules you would like to be considered. > > > Thanks, > Minos > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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, 11 months

1
0
0 0

New platform in TF-M: Musca-S1

by Mate Toth-Pal

Hi All, TF-M support for a new platform Musca-S1 is on review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2452/ We are planning to merge the patch this week. Comments are welcome on the review. Regards, Mate

5 years, 11 months

1
0
0 0

Commonly accepted default documentation layout

by Minos Galanakis

Hi With our documentation growing, and more people contributing to it, it is quite essential to start a discussion on some basic commonly accepted rules about the format of choice. Restructured text allows you to achieve similar looking results using multiple approaches, but this makes it harder for tools like Sphinx to render properly, since the rendering template can be applied on per project basis, not on a per file basis. I took the liberty of investigating the existing documentation, and mostly looking for top level headers which can be done by using either #################### This is a top-level header #################### # Reference docs: # design_documents/tfm_its_service.rst # design_documents/secure_boot_hw_key_integration.rst # Reference docs: # user_guides/tfm_secure_boot.rst # user_guides/tfm_user_guide.rst or ==================== This is a top level header ==================== # Reference docs: # design_documents/tfm_its_service.rst # design_documents/secure_boot_hw_key_integration.rst Since we are looking for the path of least resistance, I would like to propose that we follow the format the majority of document uses.This is the format used in `user_guides/tfm_user_guide.rst<https://git.trustedfirmware.org/trusted-firmware-m.git/plain/docs/user_guid…>` . When writing a document and coming across a requirement that has not been defined yet, we should be aiming for compliance with official Python guidelines<https://devguide.python.org/documenting/#style-guide> which is the most commonly used notation. 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, if 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 go deeper 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). See the current version of the `/user_guides/tfm_sw_requirement.rst<https://git.trustedfirmware.org/trusted-firmware-m.git/plain/docs/user_guid…>` and the proposed patch<https://review.trustedfirmware.org/c/trusted-firmware-m/+/2456> Please let me know if you have any questions/objection or proposals or new rules you would like to be considered. Thanks, Minos

5 years, 11 months

1
0
0 0

The svcall switch-case vs function table

by Ken Liu (Arm Technology China)

Hi, I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros? This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros. Welcome to comment or propose patches for this. Thanks. /Ken

5 years, 11 months

1
0
0 0

Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode

by Edison Ai (Arm Technology China)

Hi Alan, I have one question, why the SPE needs restored to its IDLE state prior to a thread pre-empting NS interrupt occurring? About a secure interrupt is configured with a lower priority than pendsv, I do not think it is a good idea. The pendsv is used to trigger the scheduler to switch thread. The normal interrupt process should like this: Interrupt happen -> jump into related ISR -> do necessary process such as mask interrupt status, send even or signal to related SP. -> set pendsv to trigger scheduler -> jump out ISR -> scheduler to decide which thread to run. In these sequences, if there are many interrupts happen at the same time, and high priority interrupt will interrupt low priority interrupt. Each ISR will trigger pendsv. But only one pendsv hander function needs to be processed. If we set the pendsv with high priority. Each interrupt will trigger pendsv and the pendsv handler will be processed every time. It will be more complex and spend more CPU time. Sorry that I do not know what is your detail scenario, and it will be more clear and helpful if you can provide more information. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 3:12 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have created the cooperative scheduling doc link here for comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2466 BR /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:44 AM To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: Re: [EXTERNAL] RE: secure interrupt handlng in IPC mode Mate, Apart from the surprising behavior actually working to my benefit, my concern is the implications of violating the Cooperative Scheduling Rules I quoted below. The normal behavior (ie the SP running in thread mode with no exception priority when servicing a secure interrupt) seems to violate those rules. Is this a problem for the scheduler? Alan > On Nov 13, 2019, at 5:08 AM, Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> wrote: > > Hi Alan, > > That's a quite difficult question I think. > > At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. > > However implementing this seems to be a nontrivial task. > > The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. > > The phenomenon we observed with your setup was the following: > 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. > 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. > 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. > 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' > > Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. > > To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. > > The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. > > Regards, > Mate > > From: DeMars, Alan <ademars(a)ti.com> > Sent: 12 November 2019 17:47 > To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> > Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Subject: RE: secure interrupt handlng in IPC mode > > You can CC the tf-m mailing list. > > From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] > Sent: Tuesday, November 12, 2019 8:02 AM > To: DeMars, Alan > Cc: Ken Liu (Arm Technology China) > Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode > > Hi Alan > > Would it be OK to you if I cc the TF-M mailing list in my answer? > > Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. > > Thanks, > Mate > > > From: DeMars, Alan <mailto:ademars@ti.com> > Sent: 11 November 2019 21:05 > To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> > Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> > Subject: secure interrupt handlng in IPC mode > > Hi Mate! > > I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. > > I think the below statements in the Cooperative Scheduling Rules discussion: > > a. All of the SPE interrupts must have higher priority than NSPE > interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must > extend to the priority level of the SP as it services the interrupt while in thread mode. > > Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. > > So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. > > Is this correct thinking? > > Alan > > 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

5 years, 11 months

1
0
0 0

Re: [TF-M] secure interrupt handlng in IPC mode

by Mate Toth-Pal

Hi Alan, That's a quite difficult question I think. At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. However implementing this seems to be a nontrivial task. The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. The phenomenon we observed with your setup was the following: 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. Regards, Mate From: DeMars, Alan <ademars(a)ti.com> Sent: 12 November 2019 17:47 To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: RE: secure interrupt handlng in IPC mode You can CC the tf-m mailing list. From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] Sent: Tuesday, November 12, 2019 8:02 AM To: DeMars, Alan Cc: Ken Liu (Arm Technology China) Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan Would it be OK to you if I cc the TF-M mailing list in my answer? Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. Thanks, Mate From: DeMars, Alan <mailto:ademars@ti.com> Sent: 11 November 2019 21:05 To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Subject: secure interrupt handlng in IPC mode Hi Mate! I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. I think the below statements in the Cooperative Scheduling Rules discussion: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must extend to the priority level of the SP as it services the interrupt while in thread mode. Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. Is this correct thinking? Alan 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.

5 years, 11 months

3
2
0 0

Moving design documents from wiki into source folder with rst format

by Ken Liu (Arm Technology China)

Hi, There are some design documents created earlier is put at wiki. Since they are useful and going to be updated later, we need to move them into source folder with rst format. I have created an issue link for this: https://developer.trustedfirmware.org/T579 The list is here (from link: https://developer.trustedfirmware.org/w/tf_m/): Code Generation With Jinja2 (ongoing) Cooperative Scheduling Rules (ongoing) Inter-Processes Communication Non-secure Client Management (ongoing) Non-Secure Interrupt Handling (ongoing) Secure Partition Interrupt Handling (ongoing) Secure Storage Service Service IPC compatibility - Attestation Service IPC compatibility - SST Trusted Boot Trusted Firmware-m Isolation Level 2 Twin-cpu Uniform Secure Service Signature (ongoing) Some are picked up, the rest are welcome for picking up or comment! Please check the T579 for progress and provide comments in your interested topic - if you found there are some place needs to be updated in these 'old' docs, it is a good chance to update them during the moving. Thanks. /Ken

5 years, 11 months

1
0
0 0

Re: [TF-M] out of tree build

by Kevin Peng (Arm Technology China)

Hi Alan, I'm following on this and will get you updated on any progress. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Thursday, November 7, 2019 12:42 PM To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] out of tree build Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. --- With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

1
1
0 0

Last call (for review) before merging linker script changes

by David Hu (Arm Technology China)

Hi all, I'm going to merge the following changes to common linker scripts to support dual-cpu platforms by the end of this week. https://review.trustedfirmware.org/q/topic:%22twincpu-merge-linker-script%2… Those changes mainly focus on making it easier and more comfortable to configure Armv6-M/Armv7-M MPU on a dual-cpu platform. As the changes touch the common linker scripts, I'm sorry if it affects your tasks in hand. Please let me know if the merging concerns you or breaks any urgent task. Thank you. Best regards, Hu Ziji

5 years, 11 months

1
0
0 0

Re: [TF-M] extending common linker command file template

by Mate Toth-Pal

Hi Alan, Currently the only way to have custom content in the platform linker config files is to create a platform specific template in the platform directory, and refer to that in the platform CMake file instead of the common one. Although this might not be the best solution, as keeping the platform specific files up to date with the common linker config files can be an extra work. Did you have any specific solution in mind that could handle this situation? Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 14:17 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] extending common linker command file template We've had to add two memory regions and section placements to the "tfm_common_s.ld.template". Rather than polluting this "common" template, is there a way to extend the functionality so that platform-specific content can be included in the generated linker command file? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

1
0
0 0

Re: [TF-M] irqs "source" field

by Ken Liu (Arm Technology China)

Hi Alan, I think the "source" combines the usage of "number" and "name" since a tooling is needed eventually and tool can decide the assigned value is a number or name. Something like: /* Init Secure Partition - here is the pseudo code and does not exist in real sources */ p_irq_ctx = get_interrupt_ctx_by_source (p_manifest->source); /* Tool has converted the number or name into specified source index type */ init_interrupt(p_irq_ctx, THIS_SP); /* SP-IRQ binding is needed */ The 'source' here is just a keyword for tool searching in the platform resource descriptions and be converted into a program recognizable index so that runtime code could know the interrupt context and do something. The irq_number you proposed is direct which is good; but for the name, if we need to do extra operations instead of just know where the handler is, a looking up is still needed based on the irq name provided. That is just my opinion, you can try the email in FF spec for collecting feedbacks: arm.psa-feedback(a)arm.com BR /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Saturday, November 9, 2019 2:38 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] irqs "source" field I think the PSA FF current definition of the "irqs" "source" attribute is needlessly opaque, confusing, and limiting. Why can't there simply be two attributes "irq_number" and "irq_name". "irq_number" corresponds to the CMSIS XYZ_IRQn convention in terms of its interpretation. It can be either a literal number or a manifest constant. "irq_name" is the symbolic name of the ISR as it appears in the user's vector table. That way there is no confusion regarding how they will be used. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by David Hu (Arm Technology China)

Hi Reed, Thanks for the input. We name the dual-core/multi-core feature control option flag as `TFM_MULTI_CORE_TOPOLOGY` for a general model. But as Chris said, it would require additional work to design and support more complicated scenarios. Thus for the current particular patches for dual-core platform, I'd like to specify the topic a little as "dualcpu". Best regards, Hu Ziji -----Original Message----- From: Reed Hinkel <Reed.Hinkel(a)arm.com> Sent: Sunday, November 10, 2019 5:45 AM To: Christopher Brand <chris.brand(a)cypress.com>; Andrej Butok <andrey.butok(a)nxp.com>; David Hu (Arm Technology China) <David.Hu(a)arm.com> Subject: Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" Makes sense! All the best! Reed On 11/8/19, 11:05 AM, "Christopher Brand" <chris.brand(a)cypress.com> wrote: I think that's actually an argument in favour of "dualcpu" for what we have now, because I suspect there would be significant work needed to support an additional core. Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reed > Hinkel via TF-M > Sent: Friday, November 8, 2019 6:53 AM > To: Andrej Butok <andrey.butok(a)nxp.com>; David Hu (Arm Technology > China) <David.Hu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Change dual-core patch topic name "twincpu" to > "dualcpu" > > Just food for thought, but in the future some devices may have more than > two cores, but still with one core dedicated to RoT functions. > > -Reed > > On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m- > bounces(a)lists.trustedfirmware.org on behalf of tf- > m(a)lists.trustedfirmware.org> wrote: > > OK. We use "dual", so it's better ;) > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David > Hu (Arm Technology China) via TF-M > Sent: Friday, November 8, 2019 9:16 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" > > Hi all, > > As you know, the current topic for dual-core patches is “twincpu”. > In my very own opinion, keyword “twin” implies that the two cores are the > same in the system. However, the two cores can be in different archs or > even heterogeneous in a dual-core system. > > Thus I’d like to propose to change the topic name to “dualcpu” to > > * Cover larger scope of dual-core topology/system. > * Align with the description in dual PE-based isolation section in TBSA-M > spec > > Could you please let me know if you have any concern about that change? > Any feedback or suggestion is welcome. 😊 > Thank you. > > Best regards, > Hu Ziji > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.t > rustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C9dc8588da6e2436e > 754508d76423ef30%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63 > 7087977806556698&sdata=it6Hfh2Vk9A5FUFudmNn206LYO9Wb8lOattG > %2FWsm2%2Bo%3D&reserved=0 > -- > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

1
0
0 0

irqs "source" field

by DeMars, Alan

I think the PSA FF current definition of the "irqs" "source" attribute is needlessly opaque, confusing, and limiting. Why can't there simply be two attributes "irq_number" and "irq_name". "irq_number" corresponds to the CMSIS XYZ_IRQn convention in terms of its interpretation. It can be either a literal number or a manifest constant. "irq_name" is the symbolic name of the ISR as it appears in the user's vector table. That way there is no confusion regarding how they will be used. Alan

5 years, 12 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by Jay Fallah

Hi Reed; Is there a minimum spec in terms of MCU such as M0 or M0+ or anything else for the RoT functionality MCU? Jay Fallah | Chief Technology Officer | NXM 888-416-6555 | mobile 647-927-9990 | ca.linkedin.com/in/jayfallah CONFIDENTIALITY NOTICE: This email message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > On Nov 8, 2019, at 9:53 AM, Reed Hinkel via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Just food for thought, but in the future some devices may have more than two cores, but still with one core dedicated to RoT functions. > > -Reed > > On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: > > OK. We use "dual", so it's better ;) > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M > Sent: Friday, November 8, 2019 9:16 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" > > Hi all, > > As you know, the current topic for dual-core patches is “twincpu”. > In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. > > Thus I’d like to propose to change the topic name to “dualcpu” to > > * Cover larger scope of dual-core topology/system. > * Align with the description in dual PE-based isolation section in TBSA-M spec > > Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 > Thank you. > > Best regards, > Hu Ziji > -- > 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 > > > 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

5 years, 12 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by Reed Hinkel

Just food for thought, but in the future some devices may have more than two cores, but still with one core dedicated to RoT functions. -Reed On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: OK. We use "dual", so it's better ;) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 8, 2019 9:16 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" Hi all, As you know, the current topic for dual-core patches is “twincpu”. In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. Thus I’d like to propose to change the topic name to “dualcpu” to * Cover larger scope of dual-core topology/system. * Align with the description in dual PE-based isolation section in TBSA-M spec Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 Thank you. Best regards, Hu Ziji -- 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 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.

5 years, 12 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by Andrej Butok

OK. We use "dual", so it's better ;) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 8, 2019 9:16 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" Hi all, As you know, the current topic for dual-core patches is “twincpu”. In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. Thus I’d like to propose to change the topic name to “dualcpu” to * Cover larger scope of dual-core topology/system. * Align with the description in dual PE-based isolation section in TBSA-M spec Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 Thank you. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 12 months

1
0
0 0

Change dual-core patch topic name "twincpu" to "dualcpu"

by David Hu (Arm Technology China)

Hi all, As you know, the current topic for dual-core patches is “twincpu”. In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. Thus I’d like to propose to change the topic name to “dualcpu” to * Cover larger scope of dual-core topology/system. * Align with the description in dual PE-based isolation section in TBSA-M spec Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 Thank you. Best regards, Hu Ziji

5 years, 12 months

1
0
0 0

Re: [TF-M] out of tree build

by DeMars, Alan

Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. --- With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 12 months

1
0
0 0

Re: [TF-M] out of tree build

by DeMars, Alan

With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 12 months

1
0
0 0

Patches to share common code between TF-M ITS and SST services

by Jamie Fox

Hi all, The ITS and SST partitions in TF-M share a common implementation for the backend FS and flash layers, but currently this code is duplicated between the two partitions, increasing overall code size. To fix this, it was previously proposed to keep the common code in only the ITS partition, with SST making service requests to ITS to complete FS and flash operations. The patches to implement this are now available for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2425 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2426 The first patch refactors the FS and flash code in ITS to support multiple contexts, with multiple flash devices. The second refactors SST to make requests to ITS instead of calling the FS code directly, and modifies ITS to handle requests that originate from SST with SST's FS context and flash device. This is a fairly significant change to the architecture of the two services, so feedback would be particularly appreciated. Kind regards, Jamie

5 years, 12 months

1
0
0 0

Re: [TF-M] out of tree build

by Abhishek Pandit

Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years

2
1
0 0

Re: [TF-M] Weak symbols

by Grosen, Mark

Before deciding and documenting this, could we review and decide on the overall project's applicable standards? I am guessing that "more strict requirements" might hint at things like MISRAC. I would rather see a general framework for how coding standards are either inherited or defined than one-off choices. There are other questionable coding practices in the current code base that would have trouble with MISRAC. That said, if we will adopt MISRAC, we can also adopt deviations and waivers that allow for (limited) uses of general violations. A well-documented, reviewed and approved deviation is normal practice in most projects trying to adhere to formal quality standards. Mark -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 1, 2019 7:04 AM To: Abhishek Pandit; Christopher Brand; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Weak symbols Hi, In my own words, :) it is one of the steps to be compliant with some coding guidelines with more strict requirements. We are updating the doc to specify the details. Best regards, Hi Ziji ________________________________ From: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Sent: Friday, November 1, 2019 6:59:32 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Weak symbols Hi David, As this thread is specifically for weak symbols, it would be helpful to provide some more reasoning behind the new guidance. Could be a good opportunity to discuss further as well. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: 01 November 2019 10:24 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Weak symbols Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... 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. -- 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

6 years

2
1
0 0

out of tree build

by DeMars, Alan

Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan

6 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M