As the ‘psa_irq_status_t’ is a implementation-defined value, is it possible let the implementation-define the status encoding?
Then the status and its checking code needs to be define by implementation, too:
PSA_IRQ_STATUS_NOCHANGE
PSA_IRQ_STATUS_DISABLE
PSA_IRQ_STATUS_ENABLE
PSA_IRQ_STAUTS_IS_ENABLED(status)
This would make everything implementation-defined and this affects the headers, and one extra header: psa_impdef.h needs to be created by implementations. With this the ffm based applications just use preprocessors to get status and check
them; the enable/disable can be out of ‘true’ and ‘false’ values.
/Ken
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Kevin Peng via TF-M
Sent: Tuesday, January 26, 2021 11:08 AM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification
Hi all,
Per the off-line discussion with Andrew, I’d like to start a wider discussion on the interrupt APIs, specifically the Secure Partition API changes for interrupt control in chapter 6.3.3.
There are the following APIs:
This API returns 0 if the interrupt is disabled and 1 if the interrupt is enabled.
This API returns the status of the interrupt prior to this call with an implementation defined value
Note the return type of the interrupt status is different.
The first one is only to tell whether the interrupt is enabled (1) or not (0) – an equivalent to
bool type.
The second one could be any value to indicate an interrupt status. And that value is intended to be passed to
psa_irq_restore to write to the interrupt control register directly.
The typical usage:
psa_irq_status irq2_state = psa_irq_disable(IRQ2_SIGNAL) ;
// manipulate data shared with IRQ2 …
psa_irq_restore(IRQ2_SIGNAL, irq2_state);
This is a very efficient design as the 'saved status value' can be the exact value that needs to be written to an interrupt control register to restore the previous state.
But TF-M seems to be unable to take that advantage.
Because the most common interrupt controller is the NVIC provided by the core.
The NVIC takes 1/0 to enable or disable the interrupt and one register for 32 interrupts.
The underlying NVIC operation provided by CMSIS is NVIC_Enable/DisableIRQ.
So the psa_irq_status_t in TF-M would simply 1 or 0 for a specific interrupt signal.
Then the psa_irq_restore could be unnecessary if
psa_irq_disable returns uint32_t just like psa_irq_is_enabled:
uint32_t irq_status = psa_irq_disable(IRQ);
... // critical section
if (irq_status)
psa_irq_enable(IRQ);
Any thoughts on the necessity of the psa_irq_restore API?
The draft implementation of the current APIs for easy understanding:
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M
Sent: Friday, January 15, 2021 1:25 AM
To: tf-m@lists.trustedfirmware.org; nd <nd@arm.com>
Subject: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification
Hi all,
The PSA Firmware Framework for M 1.1 Extensions specification is now published on Arm Developer.
This document introduces a set of updates and extensions to the Arm® Platform Security Architecture Firmware Framework (FF-M) specification, designed to build on the capabilities provided in version 1.0.
This is an initial ALPHA release in order to enable wider review and feedback on the changes proposed to be included in the v1.1 specification. At this quality level, the changes and interfaces defined are not stable enough for product
development. When the proposed extensions are sufficiently stable to be classed as Beta, they will be integrated into the FF-M version 1.1 specification.
The 1.1 Extensions document can be downloaded from:
https://developer.arm.com/documentation/aes0039/latest
Both the 1.0 Specification and the 1.1 Extensions document are linked from the main PSA architecture page:
Ken and I have presented a number of times at last year's Tech Forums on the proposals in the specification, most recently I provided a summary of the whole document on 10th December 2020.
If you have any feedback, please provide it to
arm.psa-feedback@arm.com, or discuss the proposals here in the TF-M mailing list.
Regards,
Andrew
--
TF-M mailing list