- TF-M - lists.trustedfirmware.org

by Kevin Peng (Arm Technology China)

Hi, I made some changes to the tfm_ns_interface_ functions. They have common implementations that call os_wrapper_ functions. With these changes, RTOSes only need to implement the OS dependent functions defined in os_wrappers rather than the tfm_ns_interface_ functions. There are several changes with a same topic: https://review.trustedfirmware.org/q/topic:%22refine_ns_interface_functions… Please help on reviewing. Thanks. - Kevin

5 years, 10 months

1
0
0 0

Non-secure SVC handling

by Miklos Balint

[from thread: RE: Adding a platform specific tfm_svc_number_t] Hi Andrej, Please note that non-secure SVC handling is independent of secure SVC handling - the two are implemented separately in the code base and hardware resources are banked for their execution. The original discussion is about secure SVC handling type and functions, which are unrelated to NS RTOS dependency on (NS) SVC. I'm starting a separate discussion thread for NS SVC occupancy to avoid blurring the lines between the two. Please note that any example code in the TF-M repository on NS SVC handling is for demonstration purposes and not, strictly speaking, part of TF-M core implementation. It shows how a non-secure privileged entity needs to register a client ID to the SPM on task creation, if multiple client IDs are managed by the RTOS. Whether a specific implementation uses SVC or another method for running the corresponding privileged code is out of scope of the design, only one possible option is shown, but this is an RTOS-specific problem. Meaning that in an RTOS where the adaptation layer mustn't use SVC and is relying on some other method, there's no design limitation in TF-M that is in conflict with that - the implementation can be adjusted in line with the RTOS's method of choice, but where the NS RTOS has no such restriction, the adaptation layer can rely on SVC for this feature. Thanks Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 26 July 2019 08:29 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>; DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Adding a platform specific tfm_svc_number_t Just another use-case, FreeRTOS is using the non-secure SVC. It does not expect that it may be used by somebody else (not RTOS). Ideally, if TFM will not occupy SVC. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, July 26, 2019 3:49 AM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Adding a platform specific tfm_svc_number_t Hi Alan, Can you share us your usage details? This could help us on defining the svc number things you mentioned. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: Friday, July 26, 2019 6:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Adding a platform specific tfm_svc_number_t > > I need to define platform specific SPM APIs that will be invoked by our SPs. > > Is there a convention for 'cleanly' adding platform specific SVC > enumerations to the tfm_svc_number_t typedef in tfm_svc.h as well as > platform specific 'case's to SVCHandler_main() and/or SVC_Handler_IPC()? > > Alan > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C42c1df29f3b84ac62f5708d7116b749e%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636997025530401902&sdata=vO0tq34jt > zFFn9D3cnrDP3a4fnrkq4h5jvzZmob2HnU%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 10 months

2
2
0 0

[RFC] Code restructure of core/spm

by Ken Liu (Arm Technology China)

Hi, Several patches for code restructure is coming. Before I post the gerrit items, I want to collect your feedback on this. These changes contain: - Move header files into dedicated directory for easy include, and clean the included headers in sources; - Change some files' name to let them make more sense. - Move SPM related files into 'spm' folder instead of putting them in 'core'. - Move some interface files into 'ns_callable' since they are interfaces. - Remove 'ipc' folder after all files in it are well arranged. I will try to do these patches together so they can be merged together. But before that I want to request for comments about this, feel free to reply in this thread or comment on the task (add yourself if you are missing as subscribers): https://developer.trustedfirmware.org/T426 BR /Ken

5 years, 10 months

1
0
0 0

Re: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py

by Kevin Townsend

As a follow-up, mcuboot has removed the pycrypto dependency, so I will put an update together for TF-M for review: https://github.com/JuulLabs-OSS/mcuboot/tree/master/scripts/imgtool Best regards, Kevin On Wed, 31 Jul 2019 at 16:27, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > As part of an effort to enable automatic builds of TF-M in Zephyr, > I've been trying to get the TF-M + Zephyr S/NS images building and > passing on Zephyr's CI system. > > The only missing requirements for building TF-M in a clean > Zephyr SDK 0.10.1 based environment is the pycrypto module, which > is used in the imgtool.py utility, specifically: > > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… > > My concern is that this module is no longer actively maintained > (last release was 2013!), and it seems like a poor decision to rely > on something that isn't actively maintained when more recent > alternative are available. > > Is there a specific reason to keep this module in the script in favour > of something more modern? > > Best regards, > Kevin > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 10 months

1
0
0 0

Re: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py

by Antonio De Angelis

Hi Kevin, We are open to scope what would be needed to move to more supported alternatives, for example: https://pypi.org/project/cryptography/ If you have any specific idea, please submit it. As far as I can see now, there is not a specific reason to stick with the old pycrypto module. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 31 July 2019 15:28 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py Hi, As part of an effort to enable automatic builds of TF-M in Zephyr, I've been trying to get the TF-M + Zephyr S/NS images building and passing on Zephyr's CI system. The only missing requirements for building TF-M in a clean Zephyr SDK 0.10.1 based environment is the pycrypto module, which is used in the imgtool.py utility, specifically: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… My concern is that this module is no longer actively maintained (last release was 2013!), and it seems like a poor decision to rely on something that isn't actively maintained when more recent alternative are available. Is there a specific reason to keep this module in the script in favour of something more modern? Best regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

1
0
0 0

Outdated pycrypto dependency in BL2's imgtool.py

by Kevin Townsend

Hi, As part of an effort to enable automatic builds of TF-M in Zephyr, I've been trying to get the TF-M + Zephyr S/NS images building and passing on Zephyr's CI system. The only missing requirements for building TF-M in a clean Zephyr SDK 0.10.1 based environment is the pycrypto module, which is used in the imgtool.py utility, specifically: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… My concern is that this module is no longer actively maintained (last release was 2013!), and it seems like a poor decision to rely on something that isn't actively maintained when more recent alternative are available. Is there a specific reason to keep this module in the script in favour of something more modern? Best regards, Kevin

5 years, 10 months

1
0
0 0

Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

by DeMars, Alan

I cherry-picked the commit into my build area and confirmed that it behaves properly. Alan > On Jul 29, 2019, at 7:57 PM, DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Looks fine to me! > > On Jul 29, 2019, at 7:19 PM, Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> wrote: > > Hi, > > The related patch is pushed into https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1669/ > Please help to review if you have time. > > Thanks, > Summer > ________________________________ > From: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> > Sent: Tuesday, July 30, 2019 6:45 AM > To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@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>>; nd <nd(a)arm.com<mailto:nd@arm.com>> > Subject: RE: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment > > > It would be good to get this fix into master ASAP so master doesn’t remain broken for long. > > > > Alan > > > > From: Summer Qin (Arm Technology China) [mailto:Summer.Qin@arm.com] > Sent: Sunday, July 28, 2019 11:18 PM > To: DeMars, Alan > Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd > Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment > > > > Hi Alan, > > > > Yeah, I see your proposed changes in the email. > > We will make the corrections under my task T435. > > > > > > Thanks, > > Summer > > > > ________________________________ > > From: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> > Sent: Monday, July 29, 2019 11:30 AM > To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@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>>; nd <nd(a)arm.com<mailto:nd@arm.com>> > Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment > > > > Summer, > > The email I sent with the attachment was bounced back so I sent another one afterwards that detailed the changes I had to make. I’d rather someone on your team make the corrections to make sure they’re sufficient. > > Alan > >> On Jul 28, 2019, at 7:41 PM, Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> wrote: >> >> Hi Alan, >> >> Thanks for pointing out this issue. >> >> The patch related to PSA APIs alignment task is the first patch to align the PSA APIs, we will have some following patches to update. >> In your last email, I didn't see the attachment, maybe blocked by the system. If it is convenient for you, could you push your patch to https://review.trustedfirmware.org , or you can create one ticket in https://developer.trustedfirmware.org and upload your changes as attachment in the new created task. Attached the change under my task T435 is also OK. We can help to submit the changes for you. >> >> >> Thanks, >> Summer >> >> On 7/28/19, 4:39 PM, "TF-M on behalf of DeMars, Alan via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: >> >> I found several other code points in tfm_svcalls.c that need to be enhanced to handle 'type' >= PSA_IPC_CALL. >> >> Attached is my modified tfm_svcalls.c file. With these modifications, the 'type' argument makes its way through the system without causing tfm_panic() to be invoked. >> >> Alan >> >> -----Original Message----- >> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M >> Sent: Friday, July 26, 2019 2:28 PM >> To: Ken Liu (Arm Technology China) >> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> >> Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment >> >> In order to pass along the new ‘type’ argument in psa_call, it seems that this line in tfm_svcalls.c: >> >> msg = tfm_spm_create_msg(service, handle, PSA_IPC_CALL, ns_caller, invecs, >> in_num, outvecs, out_num, outptr); >> >> Should be: >> >> msg = tfm_spm_create_msg(service, handle, type, ns_caller, invecs, >> in_num, outvecs, out_num, outptr); >> >> Otherwise the receiving SP will always see msg.type == PSA_IPC_CALL. >> >> Alan >> >> From: Summer-ARM (Summer Qin) [mailto:noreply@developer.trustedfirmware.org] >> Sent: Thursday, July 25, 2019 7:14 PM >> To: DeMars, Alan >> Subject: [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment >> >> Summer-ARM closed this task as "Resolved". >> >> >> TASK DETAIL >> https://developer.trustedfirmware.org/T435 >> >> EMAIL PREFERENCES >> https://developer.trustedfirmware.org/settings/panel/emailpreferences/ >> >> To: Summer-ARM >> Cc: edison-ai, matetothpal, adeaarm, wmnt, ashutoshksingh, KenLSoft, Summer-ARM, akiannillo, ademars, zhengwang721, BabaYB, karl-zh, shebuk, zbh, qixiang, DarshpreetSabharwal, jamesking1, mmorenobarm, abhishek-pandit >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> >> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 10 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by Mate Toth-Pal

Hi Alan, The interface call from ' tfm_core_init() ' to 'tfm_spm_hal_set_secure_irq_priority()' is planned to be left there as it is now. If a certain platform implementation doesn't allow interrupt priorities to be set, it can leave the implementation of 'tfm_spm_hal_set_secure_irq_priority()' function empty. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 30 July 2019 01:10 To: Adrian Shaw <Adrian.Shaw(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] including platform specific interrupt definitions Adrian, Yes, I noticed this. I guess that means that the handler name will be derived from the 'source' string. Sadly, it appears that the CMSIS convention for naming IRQ numbers is 'PeripheralX_IRQn'. Given your handler naming convention, that means that the handler names I have to put in my platform's vector table must be 'PeripheralX_IRQn_Handler'. I prefer 'PeripheralX_Handler' myself and that is what I've telegraphed to our development team. I'm thinking we will honor the PSA FF convention that if ONLY the 'source' attribute is provided for an IRQ, your name mangling rule will be followed for generating the ISR function name. Additionally, we will modify the template such that if a custom attribute of 'handler_name' (or some such) is ALSO provided, we will use our own name mangling rules for generating the ISR function name so that we are free to populate the vector table with whatever function names we want. Similarly, it appears that support for the 'tfm_irq_priority' attribute will be a platform-specific extension. Does this mean that the logic currently in tfm_core_init() that calls tfm_spm_hal_set_secure_irq_priority() for each interrupt will be removed from the standard code base? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Adrian Shaw via TF-M Sent: Monday, July 29, 2019 7:49 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Just as a heads up for future consideration. In the final version of the PSA-FF spec we replaced the `line_num` and `line_name` attributes with a new single attribute called “source”. You can use numbers or string identifiers with it (see change log in Appendix E of PSA-FF 1.0.0). Best, Adrian > On 29 Jul 2019, at 15:37, Mate Toth-Pal via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > When I created the templates, I was thinking that it is a good idea to have the '_Handler' postfix on the privileged interrupt handler names in both cases (e.g. 'line_num' or 'line_name' is provided.). This would keep the names aligned to the current pattern applied in the existing platform implementations. > > If I understand your proposal correctly, that means, in case a 'line_name' is provided in the partition manifest, there would be two different entities in the code, which are referred by the same name: > - The IRQ handler function > - A macro which is substituted to the number of that IRQ line > > I'm not completely sure that it will not happen that the header file containing the macro gets included in a file that defines or declares the function which would break the privileged handler declaration or definition. Although I didn't check this situation occurs in the current implementation. > > Is my understanding correct? Is there a benefit of this proposal that I missed? > > Thanks, > Mate > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: 22 July 2019 17:23 > To: tf-m(a)lists.trustedfirmware.org; Mate Toth-Pal > <Mate.Toth-Pal(a)arm.com> > Subject: RE: including platform specific interrupt definitions > > After pulling in all the latest commits, I have the following suggestion regarding the use of the 'irqs' manifest properties: > > 1) Use the 'line_num' property unchanged within the 'tfm_core_irq_signals[]' structure array and as the third argument to tfm_irq_handler(). This is consistent with the PSA FF definition for this property: "line_num: A valid IRQ number for the platform" > > 2) When/if it is provided, use the 'line_name' property UNCHANGED as the name of the privileged IRQ handler functions. This is consistent with the PSA FF definition for this property: "line_name: A named IRQ, represented by a string identifier. The string identifier references an external definition, which is resolved in an IMPLEMENTATION DEFINED manner. This is helpful for implementations that do not wish to duplicate information already provided by an existing platform abstraction layer. The string identifiers are not defined in this specification and, as a result, are not portable" > > 3) Only if the 'line_name' property is NOT provided, derive the privileged IRQ handler function name by appending '_Handler' to the 'line_num' property. > > I achieved the above functionality by simply changing this logic in 'tfm_secure_irq_handlers_ipc.inc.template': > > {% if handler.line_num %} > void irq_{{handler.line_num}}_Handler(void) > {% elif handler.line_name %} void > {{handler.line_name}}_Handler(void) > > To this: > > {% if handler.line_name %} > void {{handler.line_name}}(void) > {% elif handler.line_num %} void > {{handler.line_num}}_Handler(void) > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf > Of DeMars, Alan via TF-M > Sent: Friday, July 19, 2019 1:36 PM > To: Mate Toth-Pal > Cc: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt > definitions > > Mate, > > Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. > > Thanks again, > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf > Of Mate Toth-Pal via TF-M > Sent: Friday, July 19, 2019 1:22 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt > definitions > > Hi Alan, > > I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ > This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. > > Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. > This replaces the manually created IPC model signal definitions to the generated signals: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ > > This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ > > This, and the related changes remove the manually created signal files. > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ > > So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. > > As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. > > Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. > > Regards, > Mate > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: 19 July 2019 18:35 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] including platform specific interrupt definitions > > I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. > > What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? > > Alan > -- > 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 10 months

1
0
0 0

Re: [TF-M] [EXTERNAL] RE: PSA API prototype update

by Mate Toth-Pal

Hi Alan, Currently there are no plans to deprecate the 'tfm_irq_priority' optional attribute. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 25 July 2019 04:44 To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] RE: PSA API prototype update Hi Alan, These attributes should be already included in 'test/test_services/tfm_irq_test_service_1' of latest master, you can check the sources. The alignment is a big task and the patch mentioned in this mail thread is the first one of prototype change. The whole FF 1.0.0 alignment (behaviors change e.g.) would come step by step later on. And the interrupt priority -- let me check with interrupt designers to know more details. Current from my point of view it is platform defined setting which is out of FF scope. Thanks. -Ken > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, July 25, 2019 9:53 AM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [EXTERNAL] RE: PSA API prototype update > > Ken, > > Will support for the new “source” attribute in “irqs” be included in > this API alignment? If not, when might it be supported? Also, is the “irqs” “priority” > attribute being deprecated? > > Alan > > > On Jul 24, 2019, at 6:12 PM, Ken Liu (Arm Technology China) > <Ken.Liu(a)arm.com> wrote: > > > > Hi Alan, > > > > Should by this weekend or early next week, depends on if there are > > new > comments. > > > > Thanks. > > > > -Ken > > > >> -----Original Message----- > >> From: DeMars, Alan <ademars(a)ti.com> > >> Sent: Wednesday, July 24, 2019 11:17 PM > >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > >> Cc: tf-m(a)lists.trustedfirmware.org > >> Subject: RE: PSA API prototype update > >> > >> When do you anticipate that this patch will be merged to master? > >> > >> -----Original Message----- > >> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On > >> Behalf Of Ken Liu (Arm Technology China) via TF-M > >> Sent: Tuesday, July 23, 2019 11:17 PM > >> To: tf-m(a)lists.trustedfirmware.org > >> Cc: nd > >> Subject: [EXTERNAL] [TF-M] PSA API prototype update > >> > >> Hi, > >> > >> A patch is pushed for couple of days reveals the update on PSA API > >> prototype and its related caller change: > >> https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 > >> > >> The most obvious part is a new parameter member 'type' is > >> introduced in 'psa_call'. This is the first step of our upgrading > >> to the latest PSA Firmware Framework Specification. The API > >> internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. > >> > >> The callers included in TF-M has been updated in this patch. > >> Developers who developed extra services should mention this change > >> and update PSA API related sources. > >> Any feedback please comment under the patch, or reply to this mail thread. > >> > >> Thanks. > >> > >> -Ken > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 10 months

1
0
0 0

Re: [TF-M] Uniform Secure Service Signature

by Mate Toth-Pal

Hi Alan, Yes, this should happen as part of the FF 1.0.0 alignment effort. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 25 July 2019 23:59 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Uniform Secure Service Signature With the introduction of the 'type' argument in psa_call(), will the 'Uniform Secure Service Signature' also be updated to include 'type' as its first argument? https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M