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@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: 30 July 2019 01:10 To: Adrian Shaw Adrian.Shaw@arm.com Cc: tf-m@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@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@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@ti.com Sent: 22 July 2019 17:23 To: tf-m@lists.trustedfirmware.org; Mate Toth-Pal Mate.Toth-Pal@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:
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"
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"
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@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@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@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m@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@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@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@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m