- TF-M - lists.trustedfirmware.org

Re: [TF-M] Including board-specific libraries in TF-M

by Tamas Ban

Hi Kevin, Currently there is no established pattern how to link a library to secure code on platform level. Currently only services and crypto libraries are built as libraries but not platform code. I think the suggested solution (put a `target_link_libraries` entry in that platform/ext/*.cmake file) is feasible, because the platform level cmake files are included by the secure_fw/CMakeList.txt (through CommonConfig.cmake) and in this way the library will be linked to secure code. We have similar solution in case of CC312 library integration: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2526/6/platform… Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 25 November 2019 16:47 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Including board-specific libraries in TF-M Hi, While working on upstreaming support for a new MCU in TF-M, I've bumped into a requirement to link against an external library that's required for the device init sequence. I may (or may not) be able to remove this dependency, but is there currently a cross-platform mechanism to link .a files (etc.) during the build process at the platform/ext/*.cmake level? It's possible to put something together for this one target ('target_link_libraries'???), but I was wondering if I'm missing an instance where this is handled at a higher level, similar to how the RTX library is handled in the same makefiles: if (DEFINED CMSIS_5_DIR) # Not all projects define CMSIS_5_DIR, only the ones that use it. set(RTX_LIB_PATH "${CMSIS_5_DIR}/CMSIS/RTOS2/RTX/Library/GCC/libRTX_V8MMN.a") endif() Best regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Qixiang Xu (Arm Technology China)

Correct the mail list address to send it again. -----Original Message----- From: Qixiang Xu (Arm Technology China) Sent: Tuesday, November 26, 2019 2:18 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org. Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, When we add a platform into the TF-M, we need modify the top makefile to add it into build the system build, maybe we can consider to fix this issue at the same time. My proposal has changed a little from your proposal: ├── ext │ ├── arm │ │ ├── common │ │ │ └── arm_common.c │ │ ├── mps2 │ │ │ ├── an519 │ │ │ │ ├── an519.c │ │ │ │ └── plat.cmake │ │ │ ├── an521 │ │ │ │ ├── an521.c │ │ │ │ └── plat.cmake │ │ │ ├── an539 │ │ │ │ ├── an539.c │ │ │ │ └── plat.cmake │ │ │ ├── mps2.cmake │ │ │ └── mps2_common.c │ │ ├── mps3 │ │ │ ├── an524 │ │ │ │ ├── an524.c │ │ │ │ └── plat.cmake │ │ │ ├── mps3.cmake │ │ │ └── mps3_common.c │ │ └── musca │ │ ├── a │ │ │ ├── a.c │ │ │ └── plat.cmake │ │ ├── b1 │ │ │ ├── b1.c │ │ │ └── plat.cmake │ │ ├── musca.cmake │ │ ├── musca_common.c │ │ └── s1 │ │ ├── plat.cmake │ │ └── s1.c │ └── vendor1 │ ├── board1 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ ├── board2 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ └── common │ └── vendor1_common.c In the different vendor, we have different boards and the board have different variants, so the plat.cmake can include the boardx.cmake and the boardx.cmake can include the vendorx.cmake. To build the TF-M, we change the command line from PLAT=xxxx to PLAT=vendorX/boardY/varZ. The top makefile finds the plat.cmake from the platform directory with PLAT variable which passed by command line. So we don't need touch the top makefile when we add a new platform. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 26, 2019 11:05 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Edison, IMO, `target` folder is still required to separate the platforms from common files and drivers. Best regards, Hu Ziji -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Monday, November 25, 2019 11:48 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Z` The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- 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 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.

4 years, 10 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Edison Ai (Arm Technology China)

Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

2
1
0 0

Including board-specific libraries in TF-M

by Kevin Townsend

Hi, While working on upstreaming support for a new MCU in TF-M, I've bumped into a requirement to link against an external library that's required for the device init sequence. I may (or may not) be able to remove this dependency, but is there currently a cross-platform mechanism to link .a files (etc.) during the build process at the platform/ext/*.cmake level? It's possible to put something together for this one target ('target_link_libraries'???), but I was wondering if I'm missing an instance where this is handled at a higher level, similar to how the RTX library is handled in the same makefiles: if (DEFINED CMSIS_5_DIR) # Not all projects define CMSIS_5_DIR, only the ones that use it. set(RTX_LIB_PATH "${CMSIS_5_DIR}/CMSIS/RTOS2/RTX/Library/GCC/libRTX_V8MMN.a") endif() Best regards, Kevin

4 years, 10 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Devaraj Ranganna

Hi, Thanks for your inputs. The original intention of the script was to not to modify the origin of the information i.e rst file as Minos quoted and also to avoid duplication of information. Considering all the new information, I think we should try to separate build and post-build dependencies (ex: srec_cat). This separation will allow us to handle all the build dependencies using "cmake" and then we can explore the possible option on how to handle post-build dependencies. @Minos, I believe all sw dependencies defined in https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… are already validated in cmake. Adding other library dependencies into it will make it complete. This way we don’t need mention library dependency in document anymore and still achieve single source of information. @George, I think first 3 question can be answered if we decide to go ahead with handling build dependencies with cmake. Thanks, Dev On 21/10/2019, 15:56, "TF-M on behalf of Gyorgy Szing via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We need to keep an eye on some factors which the current prototype ignores. Some that come to my mind: 1. which component shall be the owner of sw dependency info? (Documentation, cmake, something else?). 2. how does the solution scale? (i.e. be able to handle platform specific dependencies). 3. how we handle build configuration specific dependencies? (i.e. if I don't build a service then some dependency is not needed). 4. As Minos mentioned some environment verification is already done by CMake. Is it worth to extract all dependency info (tooling + SW) into a dedicated place? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 21 October 2019 16:47 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format Hi, Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) . So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 21 October 2019 15:25 To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- 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

4 years, 10 months

2
5
0 0

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

by Adrian Shaw

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

4 years, 10 months

2
1
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 10 months

1
0
0 0

Add hooks for build artifacts custom post-processing

by Andrei Narkevitch

Hi All, I'd like to propose a small change that allows to implement custom build artifacts post processing. In our case, we need to convert tfm_s and tfm_ns binaries into a different file format and implement our custom signing. I expect that other partners eventually may have the same need for build customization. With this, user has an option to implement compiler_custom_post_build command in platform/ext/<platform>.cmake file, and put there all additional custom operations. If command is not implemented, it will be simply ignored. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2588 thanks Andrei 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.

4 years, 10 months

1
0
0 0

Fix for broken AN539 build

by Jamie Fox

Hi all, The build is currently broken for AN539 due to a missing include, so I pushed a quick patch to fix it: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2607 Would appreciate it if anyone with a couple of minutes could review it so that we can merge it quickly. Many thanks, Jamie

4 years, 10 months

1
0
0 0

Re: [TF-M] The svcall switch-case vs function table

by Anton Komlev

Hi Ken, All, Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase. This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 14 November 2019 09:33 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The svcall switch-case vs function table Hi, I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros? This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros. Welcome to comment or propose patches for this. Thanks. /Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 10 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M