Hi Brian,

If the peripherals can only be accessed by the secure world, then my suggestion would be to include the power controls as part of a partition.

An example could be the platform_sp, where once the client call type has been found, the action taken is implemented in the platform code, via a defined HAL.
That way the partition could be fairly generic and each platform can implement - or not - the required functionalities.
Then the build follows the same flow as the platform partition and the corresponding implementation.

Hope it helps,
Thanks
Nicola

From: Quach, Brian via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 13 February 2025 22:56
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: Adding Platform power control
 

Hi,

 

I’m trying to add platform power control functions (to power off/on peripherials) to the SPM.  Are there any examples of this?  What is the cleanest way to implement?  Can it be done via adding code to source/third_party/tfm/platform/ext/target/<vendor>/ and compiling into the platform_s target?

 

Figure 3 from DEN0063 shows the connection between SPM and PRoT partitions is IMPLEMENTATION DEFINED.  How does the TF-M implement PRoT partitions to call the SPM?  Can it be a direct API call?  I did see platform_svc_handlers() but I assume that was for use by ARoT partitions (unpriviledged).

 

DEN0063 PSA Firmware Framework:

Some platforms include functionality that can only be accessed by firmware at the highest privilege level. For example, platform power control or control registers that are shared by secure and non-secure firmware. These Platform services must be implemented as part of the SPM, but the mechanism by which the NSPE firmware accesses these services is IMPLEMENTATION DEFINED.

 

Regards,

 

Brian Quach

SimpleLink MCU

Texas Instruments Inc.