- TF-M - lists.trustedfirmware.org

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

by Edison Ai

Hi, Let's continue to discuss this topic. I agree with this, the CI is just a tool, we should not only rely on it. Thanks Gyorgy to point out the quality policy, we need to think about them when we discuss the version control. In the current status, there is only one master branch for most of the development work in TF-M. Of course, we can add a warning to say that the master is constantly changing, there may be some problems in building or test running, and let the user use the release tag. But it is not convenience and impossible if they are upstreaming patches. And even to TF-M developers, we had met several times of the master branch is broken. There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD. But this is very difficult to follow because there may be several maintainers could and need to merged patches at the same time. They need to align with each other to confirm their patches are on the TOP. But now, we often meet this case, while one patch rebases to TOP and waiting for the CI result, another patch is merged into master. The patch needs to rebase again. I do not want to give more examples here. Of course, it is a big change to involve a new branch, there must be many documents that need to be updated, and some policies need to be changed. And even this needs someone to maintain the alignment with 2 branches. But I think it is more useful and helpful for all users. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Friday, December 13, 2019 10:01 PM To: Minos Galanakis <Minos.Galanakis(a)arm.com>; Soby Mathew <Soby.Mathew(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, Hi, I agree, the CI shall not dictate how we use the version control system. It shall adapt. Regarding your suggestions, I think the main problem is we are mixing stuff, this time quality with version control. Before we make decisions we shall understand where we are. The current quality policy is that we only make releases for communication purposes. To give a clean interface for tf-m users and to allow planning their work. Releases allow them to execute their tf-m integration process less frequently. Only for each release or specific releases and not for each commit. The current quality policy identifies a single quality level only, and says any patch we publish is "golden quality", it matches the highest quality standard we can achieve (with sane constraints). Also to make our life easy we decided to use the master branch to hold these patches. At the same time we use the master branch for development. Any change we make is made against master. This means each pull request and thus each review targets master. For review purposes the best is to have a chain of small modifications, otherwise the review content becomes too large to follow. The TF-A "branching strategy" tries to address this issue by introducing an integration branch used for development. This allows master to be more release specific. I suggest to take the following approach (details to be discussed): - introduce more quality levels i.e.: - none: content of a topic branch, or content pushed to review. - bronze: content passed code review and patch specific testing. - silver: content passed a more though daily testing. - gold: a release. A pack of source-code, feature state document (release notes), reviewed documentation (user manual, reference manual), test evidence, documentation of test efforts to allow repeatability. The version control system can be used to store content, and to provide identification info (i.e. tagging), but most likely the release will need other kind of storage to be used (i.e. documentation). - platina: reaching extra quality level trough passing PSA or some FUSA qualification. Or we may simply use extra release for this. Naming the quality levels allows us to have a cleaner definition of what can be expected at a specific level (set of quality measures, i.e. static analysis, code review, test configuration). It would also allow us cleaner communication and to find how we use the version system for quality purposes. I also expect this discussion to help defining how the version system is used for development purposes. The current state works ok, but is a sort of naturally grown. We might have reached the point when more pragmatic approach may be needed. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 13 December 2019 12:23 To: Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi all. My personal comments on this. I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements. * No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that. * As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit. * Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master. * I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors. If I were to suggest some changes for stability purposes, I would start smaller: * Update documentation to instruct users to check out from release tags, warning then that master is constantly changing. * Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly. * Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state. Regards Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 December 2019 08:55 To: Soby Mathew <Soby.Mathew(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 Soby, Thanks for your detail description. > 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. I think it's a good method like this so that we can double confirm the "master" branch is stable. And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass. Any comment for this from others? For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now. Thanks, Edison -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Friday, December 13, 2019 5:14 AM 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: [TF-M] Create another branch for feature development 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 -- 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 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Thomas Törnblom

Hi Tamas, IAR provides C libraries in various configurations, depending on optimization levels, target types, needed features. Normally the linker selects the appropriate libraries depending on target, optimization, semihosting etc, but it can be told to not do that, in case there is a need to provide non-standard libraries. Cheers, /Thomas Den 2020-01-09 kl. 09:41, skrev Tamas Ban via TF-M: > > Hi Thomas, > > Just for my understanding: > > * Does IAR provide a C std. lib as part of IAR toolchain package? > * How the std C lib linked to the image? Does user provide an > explicit flag which std. C lib to linked to the image? > > Tamas > > *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Thomas Törnblom via TF-M > *Sent:* 08 January 2020 12:45 > *To:* tf-m(a)lists.trustedfirmware.org > *Subject:* Re: [TF-M] [Request For Comments] apply "-fno-builtin" as > default compiler flags > > The IAR toolchain does not produce any special "builtin" calls and > thus does not have any flag similar to "-fno-builtin". > > /Thomas > > Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: > > Hi, > > ï¿½ > > As TF-M needs runtime APIs so we are creating the Secure Partition > runtime library, code is ready but we have not forwarded all > necessary runtime APIs to the version TF-M implemented, this was > caused by the toolchain optimization for built-in APIs, such as: > > ï¿½ > > - Forward printf(%s) to puts if there is only one string parameter. > > - ARMCLANG would forward memxxx API into an optimized variant. > > ï¿½ > > With the '-fno-builtin' flags set in the toolchain, this > optimization would be disabled so that user just implement the > same name built-in to replace the toolchain version. > > ï¿½ > > Please help to check these point before applying '-fno-builtin' > and provide your feedback: > > ï¿½ > > - Could toolchains out of ARMCLANG and GNUARM have a similar flag? > > - Would it affect your project setting and how does it affect? > > ï¿½ > > Please help to feedback. I will keep this thread open for ~1 week > and let's get a conclusion after 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> > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. IMPORTANT NOTICE: The > contents of this email and any attachments are confidential and may > also be privileged. If you are not the intended recipient, please > notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information > in any medium. Thank you. > -- *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, 2 months

1
0
0 0

TF-M Technical Forum call - January 23

by Anton Komlev

Dear All, The next session of the Technical Forum is planned in 2 weeks, Thursday, January 23rd at 7:00-8:00 UTC. Please treat this email and an early invitation for agenda topic collection. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. A big or complicated topics are worth to preliminary discussed over a mailing list. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

Re: [TF-M] Code Protection between secure services

by Ken Liu

Hi, I assume the main purpose of isolation would be protect the code been seen by the AppRoT. Let's check with the FF author for detailed answers. The building instructions now is just create separate libraries and finally combine them together - since vendors can create Secure Partitions, these modularized building can't be avoided. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, January 9, 2020 4:00 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Code Protection between secure services I suggest we review the requirement of code isolation on the secure side. R/W data and R/O data should definitely be isolated, but code isolation has implications: * Code cannot be share between services (i.e. no linker optimization to reduce memory footprint) * Sharing library code * Overall the build instructions of the system are more complicated * Adding device specific driver code (i.e. to crypto) can become tricky 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. 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, 2 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Tamas Ban

Hi Thomas, Just for my understanding: * Does IAR provide a C std. lib as part of IAR toolchain package? * How the std C lib linked to the image? Does user provide an explicit flag which std. C lib to linked to the image? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 08 January 2020 12:45 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: Hi, ï¿½ As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: ï¿½ - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. ï¿½ With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. ï¿½ Please help to check these point before applying '-fno-builtin' and provide your feedback: ï¿½ - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? ï¿½ Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after 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> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Ken Liu

Hi, We have a prototype audit logging service and one of the purposes is to provide the event logging. The reason we keep printf first is that it is so direct and some projects reference it, for example, booting or services. Eventually, we need can investigate the possibility of forwarding all printf into event logging. One question is that there needs to be a buffer for collecting the events so it has limited capacity? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, January 9, 2020 3:42 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] The logging mechanism change in TF-M I recommend instead of using printf with plain text strings, to change the concept to event annotations. This is already implemented in several RTOS systems (i.e. FreeRTOS or RTX). Event annotations give you more flexibility: * can be mapped to memory buffer, printf output, or analysers like Event Recorder in MDK or Percepio * annotations are described in XML file using event groups. Can be mapped to test automation systems and reduce overhead * no direct mapping to a peripheral. UART may be not available on all systems. * overall less overhead in the system (as printf is expensive). Can remain in production code when it just goes to memory buffer Let me know if you want to have further pointers or information. 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. 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, 2 months

1
0
0 0

Code Protection between secure services

by Reinhard Keil

I suggest we review the requirement of code isolation on the secure side. R/W data and R/O data should definitely be isolated, but code isolation has implications: * Code cannot be share between services (i.e. no linker optimization to reduce memory footprint) * Sharing library code * Overall the build instructions of the system are more complicated * Adding device specific driver code (i.e. to crypto) can become tricky 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. 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, 2 months

1
0
0 0

The logging mechanism change in TF-M

by Reinhard Keil

I recommend instead of using printf with plain text strings, to change the concept to event annotations. This is already implemented in several RTOS systems (i.e. FreeRTOS or RTX). Event annotations give you more flexibility: * can be mapped to memory buffer, printf output, or analysers like Event Recorder in MDK or Percepio * annotations are described in XML file using event groups. Can be mapped to test automation systems and reduce overhead * no direct mapping to a peripheral. UART may be not available on all systems. * overall less overhead in the system (as printf is expensive). Can remain in production code when it just goes to memory buffer Let me know if you want to have further pointers or information. 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. 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, 2 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

Got 3 feedbacks till now all reports no problem. I am going to merge this one before end of today. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 1:56 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Thanks for the feedback, let me take a note. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Qixiang Xu via TF-M Sent: Monday, January 6, 2020 1:49 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 11:00 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken 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, 2 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Ken Liu

Thanks Thomas, then IAR won't be a difficult part for this. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, January 8, 2020 7:45 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: Hi, ï¿½ As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: ï¿½ - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. ï¿½ With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. ï¿½ Please help to check these point before applying '-fno-builtin' and provide your feedback: ï¿½ - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? ï¿½ Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after 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, 2 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Thomas Törnblom

The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: > > Hi, > > As TF-M needs runtime APIs so we are creating the Secure Partition > runtime library, code is ready but we have not forwarded all necessary > runtime APIs to the version TF-M implemented, this was caused by the > toolchain optimization for built-in APIs, such as: > > - Forward printf(%s) to puts if there is only one string parameter. > > - ARMCLANG would forward memxxx API into an optimized variant. > > With the '-fno-builtin' flags set in the toolchain, this optimization > would be disabled so that user just implement the same name built-in > to replace the toolchain version. > > Please help to check these point before applying '-fno-builtin' and > provide your feedback: > > - Could toolchains out of ARMCLANG and GNUARM have a similar flag? > > - Would it affect your project setting and how does it affect? > > Please help to feedback. I will keep this thread open for ~1 week and > let's get a conclusion after 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, 2 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Anton Komlev

Hi All, Thanks, Ken and Edison for offering the topics for tomorrow's Tech forum. The agenda (always open) starts from: 1. Secure Partition Runtime Library 2. PSA FF 1.0.0 alignment Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: 07 January 2020 08:19 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - January 9 Hi Anton, I will share something about the PSA FF 1.0.0 alignment. About 10 - 15 minutes. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 7, 2020 3:33 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M Technical Forum call - January 9 Hi Anton, I can share the status of Secure Partition Runtime Library in the tech forum. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, January 7, 2020 1:56 AM To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M Technical Forum call - January 9 Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

[Request For Comments] apply "-fno-builtin" as default compiler flags

by Ken Liu

Hi, As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. Please help to check these point before applying '-fno-builtin' and provide your feedback: - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after this. Thanks! /Ken

6 years, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Soby Mathew

On 07/01/2020 01:23, Ken Liu via TF-M wrote: > Hi Soby, > > Thanks for providing the reference - we have investigated the version in TF-A earlier, the difference part is we are facing the problem about how to flush the formatted data into device - TF-A has full control to the device so it could just output_char() but the secure partition cannot do this due to some driver sharing consideration. We can reference the TF-A implementation after the logging device mechanism is settled down. > > One question, the ARM Complier built-in would change printf to puts or some other variants in RVCT like __2printf, I searched TF-A sources found there is no '--fbulit-in' or 'no_scanlib' flags for the compiler but looks like TF-A has not met the scenarios TF-M met? Or...the runtime library mechanism for A and M are different? > > /Ken Hi Ken, The TF-A uses -fno-builtin compiler flag. Hence it doesn't face this problem. If the goal is to not to pull in compiler builtin libraries, setting this flag would be the right approach. The TF-M source tree would need to provide libc. Best Regards Soby Mathew

6 years, 2 months

2
1
0 0

Last call for reviewing TIMER IRQ naming

by Alamy Liu

Hi all, Please help to review the patch, and it would be merged soon if there is no other comment https://review.trustedfirmware.org/c/trusted-firmware-m/+/2687 Best Regards, Alamy

6 years, 2 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Edison Ai

Hi Anton, I will share something about the PSA FF 1.0.0 alignment. About 10 - 15 minutes. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 7, 2020 3:33 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - January 9 Hi Anton, I can share the status of Secure Partition Runtime Library in the tech forum. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, January 7, 2020 1:56 AM To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M Technical Forum call - January 9 Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Ken Liu

Hi Anton, I can share the status of Secure Partition Runtime Library in the tech forum. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, January 7, 2020 1:56 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - January 9 Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Ken Liu

Hi Soby, Thanks for providing the reference - we have investigated the version in TF-A earlier, the difference part is we are facing the problem about how to flush the formatted data into device - TF-A has full control to the device so it could just output_char() but the secure partition cannot do this due to some driver sharing consideration. We can reference the TF-A implementation after the logging device mechanism is settled down. One question, the ARM Complier built-in would change printf to puts or some other variants in RVCT like __2printf, I searched TF-A sources found there is no '--fbulit-in' or 'no_scanlib' flags for the compiler but looks like TF-A has not met the scenarios TF-M met? Or...the runtime library mechanism for A and M are different? /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: Monday, January 6, 2020 9:35 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] The logging mechanism change in TF-M On 06/01/2020 11:45, Anton Komlev via TF-M wrote: > Hi Ken, All, > > I like your approach of providing a minimalistic version of printf() > for the logging purpose only. > > This would benefit to code size and performance while rich print > formatting has no practical needs in this project. > > Best regards, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Ken Liu via TF-M > *Sent:* 27 December 2019 03:38 > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] The logging mechanism change in TF-M > > Hi, > > We met some issues while implementing logging APIs like printf: > > * The build-in symbol optimization references other toolchain provided > symbols into image (like change ‘printf’ to ‘puts’ or ‘xxxprintf’), > this would happen in both we are implementing your ‘printf’ and > referencing toolchain ‘printf’. Use a -fno-builtin would suppress > this but this needs a compiler flag requirement for developers. > * If we don’t provide necessary symbol but somewhere in program > referenced it, ARMCLANG would provide one for us which contains the > semihosting things, this increases the code size and cause trouble > while the device is not running under semihosting env. > * Also there are CMSIS user reports that __stdout would affect > multiple thread object initialization. (No detail about the root > cause, anyone could help provide something?) > > So it would be better that we remove the reference to toolchain stdout > APIs, this could simplify the logging implementation since firmware > logging MAY not need rich format (Comments?). A customized printf-like > API is provided for logging but not being named as ‘printf’ directly. > > Due to the default logging device (UART) driver may be implemented for > threads only, the logging functionality in exceptions is going to be > suppressed for a while until we figure out how the logging in > exceptions can be – there is a trade-off between security > consideration (isolation) and performance (Routing the logging API to somewhere costs). > > Please provide your thinking, or what kind of logging API you are using. > > Thanks > > /Ken > The TF-A code base provides a reduced printf() functionality due to similar concerns and to reduce stack/memory usage https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/libc/p… Also be aware that mbedTLS requires snprintf() so if printf() is being custom implemented, then it makes sense to do the same to snprintf() as well. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Updated invitation: TF-M Tech Forum @ Thu 9 Jan 2020 07:00 - 08:00 (GMT) (tf-m@lists.trustedfirmware.org)

by bill.fletcher＠linaro.org

This event has been changed. Title: TF-M Tech Forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings.Initially we propose a bi-weekly call and then we'll change cadence depending on interest Feel free to forward it to colleagues.──────────Bill Fletcher is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New York)+16699009128,,5810428000# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042 8000Find your local number: https://zoom.us/u/aerUYXPhSL────────── When: Thu 9 Jan 2020 07:00 – 08:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=NTZtNXZwM3BsaGltanJkb… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years, 2 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 9 Jan 2020 07:00 - 08:00 (GMT) (tf-m@lists.trustedfirmware.org)

by bill.fletcher＠linaro.org

You have been invited to the following event. Title: TF-M Tech Forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings.Initially we propose a bi-weekly call and then we'll change cadence depending on interest Feel free to forward it to colleagues.──────────Bill Fletcher is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New York)+16699009128,,5810428000# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042 8000Find your local number: https://zoom.us/u/aerUYXPhSL────────── When: Thu 9 Jan 2020 07:00 – 08:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Joining info: Join Hangouts Meet https://meet.google.com/xdb-txmc-xje Or dial: +44 20 3956 3237 (PIN:: 515715720) More phone numbers: https://tel.meet/xdb-txmc-xje?pin=7033981256503&hs=0 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=NTZtNXZwM3BsaGltanJkb… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years, 2 months

1
0
0 0

TF-M Technical Forum call - January 9

by Anton Komlev

Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Andrew Thoelke

> Just a question: For Isolation Level 1, the hardware features of v8-M should be sufficient to implement interrupts natively. Is this correct understanding or did I miss anything? This is essentially correct. As this is outside of the PSA-FF at present, TF-M would need to design and document how to integrate such IRQ handlers with its interrupt management framework, and how the interrupt handler can interact with the secure service code. For example, this might be achieved by resuming a SFC call that is waiting for a hardware operation to complete or delivering a signal to an IPC mode Secure Partition. 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, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Soby Mathew

On 06/01/2020 11:45, Anton Komlev via TF-M wrote: > Hi Ken, All, > > I like your approach of providing a minimalistic version of printf() for > the logging purpose only. > > This would benefit to code size and performance while rich print > formatting has no practical needs in this project. > > Best regards, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Ken > Liu via TF-M > *Sent:* 27 December 2019 03:38 > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] The logging mechanism change in TF-M > > Hi, > > We met some issues while implementing logging APIs like printf: > > * The build-in symbol optimization references other toolchain provided > symbols into image (like change ‘printf’ to ‘puts’ or ‘xxxprintf’), > this would happen in both we are implementing your ‘printf’ and > referencing toolchain ‘printf’. Use a -fno-builtin would suppress > this but this needs a compiler flag requirement for developers. > * If we don’t provide necessary symbol but somewhere in program > referenced it, ARMCLANG would provide one for us which contains the > semihosting things, this increases the code size and cause trouble > while the device is not running under semihosting env. > * Also there are CMSIS user reports that __stdout would affect > multiple thread object initialization. (No detail about the root > cause, anyone could help provide something?) > > So it would be better that we remove the reference to toolchain stdout > APIs, this could simplify the logging implementation since firmware > logging MAY not need rich format (Comments?). A customized printf-like > API is provided for logging but not being named as ‘printf’ directly. > > Due to the default logging device (UART) driver may be implemented for > threads only, the logging functionality in exceptions is going to be > suppressed for a while until we figure out how the logging in exceptions > can be – there is a trade-off between security consideration (isolation) > and performance (Routing the logging API to somewhere costs). > > Please provide your thinking, or what kind of logging API you are using. > > Thanks > > /Ken > The TF-A code base provides a reduced printf() functionality due to similar concerns and to reduce stack/memory usage https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/libc/p… Also be aware that mbedTLS requires snprintf() so if printf() is being custom implemented, then it makes sense to do the same to snprintf() as well. Best Regards Soby Mathew

6 years, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Anton Komlev

Hi Ken, All, I like your approach of providing a minimalistic version of printf() for the logging purpose only. This would benefit to code size and performance while rich print formatting has no practical needs in this project. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 27 December 2019 03:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The logging mechanism change in TF-M Hi, We met some issues while implementing logging APIs like printf: * The build-in symbol optimization references other toolchain provided symbols into image (like change 'printf' to 'puts' or 'xxxprintf'), this would happen in both we are implementing your 'printf' and referencing toolchain 'printf'. Use a -fno-builtin would suppress this but this needs a compiler flag requirement for developers. * If we don't provide necessary symbol but somewhere in program referenced it, ARMCLANG would provide one for us which contains the semihosting things, this increases the code size and cause trouble while the device is not running under semihosting env. * Also there are CMSIS user reports that __stdout would affect multiple thread object initialization. (No detail about the root cause, anyone could help provide something?) So it would be better that we remove the reference to toolchain stdout APIs, this could simplify the logging implementation since firmware logging MAY not need rich format (Comments?). A customized printf-like API is provided for logging but not being named as 'printf' directly. Due to the default logging device (UART) driver may be implemented for threads only, the logging functionality in exceptions is going to be suppressed for a while until we figure out how the logging in exceptions can be - there is a trade-off between security consideration (isolation) and performance (Routing the logging API to somewhere costs). Please provide your thinking, or what kind of logging API you are using. Thanks /Ken

6 years, 2 months

1
0
0 0

Re: [TF-M] System reset SPM HAL function

by Edison Ai

This patch will add a new system reset function for SPM without using the existing platform_hal_system_reset(). The basic thinking is to create a dedicated HAL function for SPM to split with services, and not affect the secure partition work. I am not sure if this will bring some problems or any potential risk for platform porting. Please give feedback about this in this mail thread. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: Monday, December 30, 2019 3:43 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] System reset SPM HAL function Hi All, To align with PSA FF 1.0.0, the SPM needs to restart the entire system when some programmer error or panics are detected. So I had upstream a patch to add a system reset HAL function for SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2780/. The basic idea is to add a weak common function so that the platform can use this weak function to do reset. Please note, the platform needs to add its own implementation if there is any different. Unfortunately, there is no such test to test the system reset function curreetly. So please call psa_panic() in secure services for simple testing based on the top of this link: https://review.trustedfirmware.org/#/q/topic:tfm_panic+(status:open+OR+stat…. You can send mail or add comments directly in patches if you have any questions or comments. Thanks, Edison

6 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M