- TF-M - lists.trustedfirmware.org

Re: [TF-M] Create another branch for feature development

by Soby Mathew

On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew

6 years, 3 months

2
1
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Ken Liu (Arm Technology China)

Hi Reinhard, Guess this diagram for a long time ago design since the latest version there is no need for NS SVC. (Check diagram attached in the ticket). I think the existing library model implementation is almost the one you described, just some points: - We use a secure SVC in SPM for sanitization input/output buffers. - We do secure partition maintenance in SPM (forward call, maintain state). The TZ API implementation under SFC is for the purpose that some services have bound the client with policies so they need to know which client is calling. It can be skipped if there is no such client-orient policy. And one thing to mention, even we propose to use locks in RTOS for locking the interface, there would be a chance that some RTOS has a limitation on these lock APIs, or someone just acts as an attacker who skips the necessary locking operations, then we need to provide some detection in the secure side as countermeasures, and this part needs to be documented to remind users that, please make sure there is only one ongoing secure call or a panic is generated. Then it would be RTOS' choice to decide if they want to avoid this panic by locking. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, December 12, 2019 11:22 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution) As the picture got lost, I did create also https://developer.trustedfirmware.org/T615 This contains the picture Reinhard 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

6 years, 3 months

1
0
0 0

MPU issues, was Re: Regression test issues with IAR port

by Thomas Törnblom

Next issue. For some reason the secure image runs into a MemManage exception fairly early in the irq test of the ConfigRegressionIPCTfmLevel2 config and I have not yet been able to figure out why. It happens in the psa_wait() call in: --- int32_t tfm_irq_test_1_init(void) { tfm_enable_irq(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ); #ifdef TFM_PSA_API psa_signal_t signals = 0; while (1) { signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK); --- The exact point of the exception is the SVC call in: --- __attribute__((naked, section("SFN"))) psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout) { __ASM volatile("SVC %0 \n" "BX LR \n" : : "I" (TFM_SVC_PSA_WAIT)); } --- The cause is IACCVIOL, "The processor attempted an instruction fetch from a location that does not permit execution." The stack frame indicates that it happened on the SVC instruction, but I as far as I can see none of the MPU regions maps the address so I assumed it should be allowed as it should be handled by the background map, which should allow secure access. If I don't enable the mpu (just skipping the enable call) then all tests run without problems. I have tried to compare it with an image built with ARMCLANG, and I don't see anything obviously different. The regions are roughly the same, all regions with fixed addresses are the same, the enable bits are the same and the SVC handler is not mapped to any MPU region there either. I wish there were an MPU status register that would tell exactly what region was causing the exception. The odd thing is that there is an SVC call in the tfm_enable_irq() call prior to the psa_wait() call, and that works. This is on a Musca A by the way. Ideas? -- *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>

6 years, 3 months

1
0
0 0

TF-M Technical Forum call - 19th December

by Anton Komlev

Hello, To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics. 1. The time slot. Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=… Please share your thoughts and alternatives. The related question: shall we fix the time or rotating? You can play with the time slot here: https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea… 2. Agenda as a proposal - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - Cryptocell integration - ? Best regards, Anton Komlev

6 years, 3 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Gyorgy Szing

Hi, Sorry the image did not got trough. One way to share the image could be to create a ticket here https://developer.trustedfirmware.org/maniphest/ where the image can be uploaded. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 12 December 2019 13:13 To: tf-m(a)lists.trustedfirmware.org Cc: Bruno Mendes <Bruno.Mendes(a)arm.com> Subject: [TF-M] Simplify RTOS / TF-M interface (single thread execution) When using TF-M on v8-M with Secure Function Call SFC (aka Library) mode, the entry to the secure side is protected by a Mutex. Thus only one thread at the time is calling a secure service. The picture below should therefore represent the execution flow (Level 1 isolation). [cid:image003.jpg@01D5B0ED.DEEA6A60] Under this assumption there is no need to implement TZ_context management in the RTOS (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…). Any RTOS could be used, provided that the Mutex capability is sufficient. Moreover this design should create a really simple secure side: * Only one stack is needed on the secure side for Thread mode execution * No multi-threading issues that need to be resolved (i.e. with access of hardware crypto accelerators) The drawback of course is that only one task at a time can use a secure service. However an RTOS with priority inversion will ensure that the Secure service is executed as fast as possible, once a scheduling conflict arises. I would like to gather feedback on that approach. Let me know what you think. Reinhard 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

6 years, 3 months

2
1
0 0

Simplify RTOS / TF-M interface (single thread execution)

by Reinhard Keil

When using TF-M on v8-M with Secure Function Call SFC (aka Library) mode, the entry to the secure side is protected by a Mutex. Thus only one thread at the time is calling a secure service. The picture below should therefore represent the execution flow (Level 1 isolation). [cid:image003.jpg@01D5B0ED.DEEA6A60] Under this assumption there is no need to implement TZ_context management in the RTOS (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…). Any RTOS could be used, provided that the Mutex capability is sufficient. Moreover this design should create a really simple secure side: * Only one stack is needed on the secure side for Thread mode execution * No multi-threading issues that need to be resolved (i.e. with access of hardware crypto accelerators) The drawback of course is that only one task at a time can use a secure service. However an RTOS with priority inversion will ensure that the Secure service is executed as fast as possible, once a scheduling conflict arises. I would like to gather feedback on that approach. Let me know what you think. Reinhard 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.

6 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Secure Interrupt handling - RE: TF-M technical Forum slides and recording

by DeMars, Alan

Ken, Task scheduling (context switching) in our RTOS is always performed in thread mode, even when asynchronous pre-emption occurs resulting from an ISR readying a higher priority task. All kernel-managed interrupts are routed to a common interrupt dispatcher that, just prior to returning from an interrupt, will invoke the task scheduler when it determines that there are no more interrupts pending and there is scheduling work to do. In that case, an artificial interrupt context is created so that thread mode can be "returned to" from handler mode. The task scheduler is then invoked in thread mode from the stack of the pre-empted task. Regarding secure interrupts, our use cases only employ secure interrupts as a consequence of a psa_call() initiating a process that completes when an interrupt goes off sometime later. Rather than spin-waiting for the interrupt-completion signal, or parking in a WFI, we simply return from the psa_call() with a special return code indicating that the process has started and that the calling thread will be notified of completion by the secure callback mechanism I described at the conference in Lyon. The calling thread then pends on a semaphore. When the secure interrupt goes off later on, a dedicated non-secure interrupt is triggered that ultimately ends up posting the semaphore that the NS thread is pended on. Upon returning from the pend, the NS thread then re-enters the SP (using psa_call()) to complete the transaction. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, December 10, 2019 8:04 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] Secure Interrupt handling - RE: TF-M technical Forum slides and recording Thank Bill for updating this. I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs). About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time? And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts? Thanks. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M technical Forum slides and recording Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020 -- 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, 3 months

2
1
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by lg

Hi Edison, Thanks for your quick reply. I will try to upstream a patch later. Thanks, Matt At 2019-12-12 11:15:51, "Edison Ai \\(Arm Technology China\\) via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: >Hi Matt, > >Thanks very much for your mail. It looks like it is indeed a problem here. >Can you upstream a patch to help to fix them directly? > >Thanks, >Edison > >-----Original Message----- >From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M >Sent: Thursday, December 12, 2019 9:43 AM >To: tf-m(a)lists.trustedfirmware.org >Subject: [TF-M] Secure storage and Internal trusted storage code logic check > >Hi TFM Secure storage & Internal trusted storage experts, > > > It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. > There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: > > > for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i); > } > This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. > If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START > is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. > Should it be the following logic? > > > for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); > } > It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. > > > Please help to check. > > >Thanks. >Matt. > >-- >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, 3 months

1
0
0 0

Please review the patch set to extract duplicated template files from platforms

by David Hu (Arm Technology China)

Hi all, I submit a patch set to extract the duplicated identical template files dummy_xxx.c from targets and put them under platform/ext/common/template folder. The purpose is to collect a common template of booting/attestation example for platforms and each platform doesn't need to keep a copy under its folder anymore. Since it is a general change related to all platforms using template files, I'd like to ask for review here. Any comments would be appreciated. Please check the patch details in https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(statu… The background is described in https://developer.trustedfirmware.org/T539. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by Edison Ai (Arm Technology China)

Hi Matt, Thanks very much for your mail. It looks like it is indeed a problem here. Can you upstream a patch to help to fix them directly? Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Thursday, December 12, 2019 9:43 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Secure storage and Internal trusted storage code logic check Hi TFM Secure storage & Internal trusted storage experts, It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i); } This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. Should it be the following logic? for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); } It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. Please help to check. Thanks. Matt. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Secure storage and Internal trusted storage code logic check

by lg

Hi TFM Secure storage & Internal trusted storage experts, It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i); } This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. Should it be the following logic? for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); } It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. Please help to check. Thanks. Matt.

6 years, 3 months

1
0
0 0

Re: [TF-M] IAR libc behavior?

by Ken Liu (Arm Technology China)

Thanks Thomas. Let me try that link. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, December 11, 2019 9:13 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IAR libc behavior? Hi Ken, There should be no difference from GNUARM or ARMCLANG in this respect. Should not need any special switches. If you wish to try out our tools, you can download a trial version until we have arranged for a permanent solution, see: https://www.iar.com/iar-embedded-workbench/#!?architecture=Arm Cheers, Thomas Den 2019-12-11 kl. 11:05, skrev Ken Liu (Arm Technology China) via TF-M: > Hi Thomas, > > I have a question about IAR compiler since we verify default GNUARM and ARMCLANG in the existing sources. > If we are trying to implementing some internal version of libc APIs like 'memcmp', would IAR link with this implemented version first, or it just report a link error of duplicated symbol? Any switches do we need to assign to support this? > > Thanks. > > /Ken -- *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

6 years, 3 months

1
0
0 0

Re: [TF-M] IAR libc behavior?

by Thomas Törnblom

Hi Ken, There should be no difference from GNUARM or ARMCLANG in this respect. Should not need any special switches. If you wish to try out our tools, you can download a trial version until we have arranged for a permanent solution, see: https://www.iar.com/iar-embedded-workbench/#!?architecture=Arm Cheers, Thomas Den 2019-12-11 kl. 11:05, skrev Ken Liu (Arm Technology China) via TF-M: > Hi Thomas, > > I have a question about IAR compiler since we verify default GNUARM and ARMCLANG in the existing sources. > If we are trying to implementing some internal version of libc APIs like 'memcmp', would IAR link with this implemented version first, or it just report a link error of duplicated symbol? Any switches do we need to assign to support this? > > Thanks. > > /Ken -- *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>

6 years, 3 months

1
0
0 0

IAR libc behavior?

by Ken Liu (Arm Technology China)

Hi Thomas, I have a question about IAR compiler since we verify default GNUARM and ARMCLANG in the existing sources. If we are trying to implementing some internal version of libc APIs like 'memcmp', would IAR link with this implemented version first, or it just report a link error of duplicated symbol? Any switches do we need to assign to support this? Thanks. /Ken

6 years, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Edison Ai (Arm Technology China)

Hi Gyorgy, Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. There are three branches in TF-A: - "integration" branch, should be used for new features. - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. @Soby Mathew Could you help to share more information about it? Thanks very much. Hi David W, Thanks for your comments. For your first comment, I will say yes. Sorry to give the CI problem as a reason. For your second comment, I think we can use " git merge <commit-id>" to merge up to a special commit of dev to the master branch. In this, we do not need to freeze the patch merging. Maybe other methods to do it. Sorry, I am not a git expert, please correct me if it is wrong. I agree with you that we need to think clearly about it. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, December 11, 2019 3:58 PM To: David Wang (Arm Technology China) <David.Wang(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi, Please sync up with the TF-A team on branching strategy. It would be preferred to keep the two projects aligned if possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 11 December 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Hotfix for GNUARM linker script

by David Hu (Arm Technology China)

Hi all, I uploaded a hotfix to fix a issue in GNUARM linker script. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2767 The XXX_ATTR_FN label is named as XXX_LD_ATTR_FN for Application RoT Secure Partitions in GNUARM linker script. Thus GNUARM cannot get the dedicated section address to place the XXX_ATTR_FN section defined in the source code. It may cause linking error and crash during running. Please help review the patch. Any comment is welcome and will speed up the fix. Thank you. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Gyorgy Szing

Hi, Please sync up with the TF-A team on branching strategy. It would be preferred to keep the two projects aligned if possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 11 December 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- 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, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by David Wang (Arm Technology China)

Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- 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, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Kevin Peng (Arm Technology China)

Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Create another branch for feature development

by Edison Ai (Arm Technology China)

Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison

6 years, 3 months

1
0
0 0

Secure Interrupt handling - RE: TF-M technical Forum slides and recording

by Ken Liu (Arm Technology China)

Thank Bill for updating this. I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs). About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time? And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts? Thanks. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M technical Forum slides and recording Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Support for optional build for secure partitions and test suites

by Kevin Peng (Arm Technology China)

Hi, I've made some patches to support optional build for secure partitions and test suites: https://review.trustedfirmware.org/q/topic:%22optional_build_sp_and_tests%2… With this patch set, you can optionally build secure partitions by setting the TFM_PARTITION_XXX in CommonConfig.cmake around line 152 - 162. And for test suites, by setting ENABLE_XXX_TESTS in test/TestConfig.cmake. I'm collecting for review comments. Thanks. Best Regards, Kevin

6 years, 3 months

1
0
0 0

TF-M technical Forum slides and recording

by Bill Fletcher

Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 3 months

1
0
0 0

Adding Cypress PSoC64 platform support

by Christopher Brand

Hi, I recently pushed patches to add support for a platform based on Cypress' PSoC64 SoC to gerrit. Given that this is the first non-Arm platform to be posted, it seems worth drawing attention to. Comments very much appreciated. I do anticipate a few small updates to the patchset, even in the absence of comments. In particular, there are some documentation improvements to come. There are four patches in total, ending with https://review.trustedfirmware.org/c/trusted-firmware-m/+/2728 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2725/1 adds files to the platform/ext/cmsis directory, and so will affect/be affected by https://review.trustedfirmware.org/c/trusted-firmware-m/+/2578 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.

6 years, 3 months

1
0
0 0

Re: [TF-M] Regression test issues with IAR port

by Jamie Fox

Hi Thomas, Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs. Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different. Kind regards, Jamie From: Thomas Törnblom <thomas.tornblom(a)iar.com> Sent: 02 December 2019 22:50 To: Jamie Fox <Jamie.Fox(a)arm.com>; Minos Galanakis <Minos.Galanakis(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Regression test issues with IAR port Hi Jamie, From tfm_sst_test_1018_task_2(): --- ... uint8_t read_data[] = READ_DATA; status = psa_ps_get(uid, offset, data_len, read_data); if (status != PSA_PS_ERROR_UID_NOT_FOUND) { TEST_FAIL("Get should not succeed with invalid thread name"); return; } /* Check that read data has not been modified */ if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) { TEST_FAIL("Read data should not have changed"); return; } ... --- The call to psa_ps_get() returns 0, which is a failure in this test. Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX". This appears to happen in the following call chain: sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy() As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related. sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req() I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get(). It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020. I'll continue debugging this... Cheers, Thomas Den 2019-11-28 kl. 17:37, skrev Jamie Fox: Hi Thomas, We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think. Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping. The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread. Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there? Kind regards, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 28 November 2019 15:45 To: Minos Galanakis <Minos.Galanakis(a)arm.com><mailto:Minos.Galanakis@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com><mailto:nd@arm.com> Subject: Re: [TF-M] Regression test issues with IAR port Sorry, I was being unclear. I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread. The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there. Cheers, Thomas Den 2019-11-28 kl. 16:00, skrev Minos Galanakis: Thomas, Tests are placed under the test -> suites -> service name directory. In your case you are looking at the Secure Storage Service non secure suite. For SST The logic is located at : * Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c * Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c Hope that helps Minos ---------------------------------------------------------------------- -- *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> *Sent:* 28 November 2019 14:49 *To:* tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> *Subject:* [TF-M] Regression test issues with IAR port In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con figs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, 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> <mailto:thomas.tornblom@iar.com><mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> <http://www.iar.com><http://www.iar.com> <http://www.iar.com><http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- 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>

6 years, 3 months

2
3
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M