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:

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@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