I guess that could fit under the "power domain management" functionality of the SCMI interface ("the ability to place a given device or domain into the various power-saving states that it supports"). There's a minimalist implementation of the SCMI partition (without power domain management functionality) at https://git.trustedfirmware.org/plugins/gitiles/TF-M/tf-m-extras/+/refs/head...

Chris

From: Nicola Mazzucato via TF-M tf-m@lists.trustedfirmware.org Sent: Friday, February 14, 2025 12:57 AM To: tf-m@lists.trustedfirmware.org; Quach, Brian brian@ti.com Subject: [TF-M] Re: Adding Platform power control

Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guidehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx to help you identify Phishing email.

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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 13 February 2025 22:56 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto: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.

Hi Nicola,

Here’s an example use case (somewhat non-standard):

* Assume all peripheral power and clock control registers are mapped to SPE and there is a power driver/clk within the SPE (e.g. it handles turning on/off peripherals and tracks usage to decide when low power modes can be entered, clocks gated, etc) * Assume asynchronous HW operations are supported within the SPE. The SPE could turn on power to the associated peripheral and start an operation and return to NSPE. Then NSPE could request enabling power to another peripheral for use by a driver in the NSPE.

Regards, Brian

From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Monday, February 17, 2025 10:13 AM To: tf-m@lists.trustedfirmware.org; Quach, Brian brian@ti.com; Chris.Brand@infineon.com Subject: [EXTERNAL] Re: Adding Platform power control

Hi, Yes, it could be an option to have/add power mgmt as part of the SCMI interface. However, I see that a use-case when the consumer is on a separate PE from TF-M, so the communication channel is already done via a payload (mailbox for example).  ZjQcmQRYFpfptBannerStart This message was sent from outside of Texas Instruments.

Do not click links or open attachments unless you recognize the source of this email and know the content is safe.

Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!trdkMXejei0aJagk3FODXEYsUKQvHG50L77wxOQTsg_iClk_eCXYo8e8UKu-GUXt-Uh7oYdIVXm1tyLDb2ffiAwFMKa7_nziZt9BBsPmu_kkr9UC8nAMx87oGmvUdPp_B1Hx$ ‌

ZjQcmQRYFpfptBannerEnd Hi, Yes, it could be an option to have/add power mgmt as part of the SCMI interface. However, I see that a use-case when the consumer is on a separate PE from TF-M, so the communication channel is already done via a payload (mailbox for example). Otherwise, if only local clients (same PE) are in need of power controls, then we're probably better off with a direct psa_call, so we avoid the overhead of payload + SCMI despatching. Either way we still need a driver to perform the actual power change. If we implement the interfaces nicely, SCMI partition "could" in the future use the interface into the platform_sp ( or whatever power-SP) to perform the required power changes.

Or at least, that's the way I see it.

@Brian, would you be able to provide a basic example of your use case for this need of NSPE to change some power settings?

Thanks in advnace Hope it help Nicola

________________________________ From: Chris.Brand--- via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 14 February 2025 16:19 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; brian@ti.commailto:brian@ti.com <brian@ti.commailto:brian@ti.com> Subject: [TF-M] Re: Adding Platform power control

I guess that could fit under the “power domain management” functionality of the SCMI interface (“the ability to place a given device or domain into the various power-saving states that it supports”). There’s a minimalist implementation of the SCMI partition (without power domain management functionality) at https://git.trustedfirmware.org/plugins/gitiles/TF-M/tf-m-extras/+/refs/head...https://urldefense.com/v3/__https:/git.trustedfirmware.org/plugins/gitiles/TF-M/tf-m-extras/*/refs/heads/main/docs/partitions/scmi_comms.rst__;Kw!!G3vK!QjWgoyDMIo8QeYS25G_Cef6PPs3S48WcgzjRAETBKFMRWO4glKTLaDfDDdKcOd49xiZf6cD61vZINeIeFA$

Chris

From: Nicola Mazzucato via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, February 14, 2025 12:57 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Quach, Brian <brian@ti.commailto:brian@ti.com> Subject: [TF-M] Re: Adding Platform power control

Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guidehttps://urldefense.com/v3/__https:/intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx__;!!G3vK!QjWgoyDMIo8QeYS25G_Cef6PPs3S48WcgzjRAETBKFMRWO4glKTLaDfDDdKcOd49xiZf6cD61vagGrfu3g$ to help you identify Phishing email.

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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 13 February 2025 22:56 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto: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.

Hi Nicola,

Unfortunately, I have a re-occuring team meeting which conflicts with the TF-M tech forum calls. But I’m happy to join a separate meeting or provide my inputs via e-mail thread.

Currently, the only additional feature I would request is for PRoT partitions to have low overhead when calling the SPM power functions (i.e. avoid IPC mechanism at all isolation levels if at all possible). Power functions will be called quite frequently so adding a few thousand cycles of latency would add up quickly.

Regards, Brian

From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Thursday, February 20, 2025 2:44 PM To: Quach, Brian brian@ti.com; tf-m@lists.trustedfirmware.org Cc: Chris.Brand@infineon.com Subject: [EXTERNAL] Re: Adding Platform power control

Hi Brian, Thanks a lost for the additional information. I am also interested in contributing to adding support for having some platform power controls. Would you find it useful to have a loose conversation in one of the next TF-M Tech Forum? ZjQcmQRYFpfptBannerStart This message was sent from outside of Texas Instruments.

Do not click links or open attachments unless you recognize the source of this email and know the content is safe.

Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!trdkMXejei0aJagk3FODXChN8UTvHeDU7v6whApTHAEHb2yJazE81mkxhORdLiJ5sw5sMX78F5ZoYCgMDL5Dw0ggfQrUD9gt3Mkh-YgzMELxZ6e3lDnnNwccws45LCq1WxZp$ ‌

ZjQcmQRYFpfptBannerEnd Hi Brian,

Thanks a lost for the additional information. I am also interested in contributing to adding support for having some platform power controls.

Would you find it useful to have a loose conversation in one of the next TF-M Tech Forum? That way we could start capturing the most important features and information, to help us finding the best solutions to our needs.

Many thanks Best regards, Nicola

________________________________ From: Quach, Brian <brian@ti.commailto:brian@ti.com> Sent: 18 February 2025 16:35 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com <Chris.Brand@infineon.commailto:Chris.Brand@infineon.com> Subject: RE: Adding Platform power control

Hi Nicola,

Here’s an example use case (somewhat non-standard):

* Assume all peripheral power and clock control registers are mapped to SPE and there is a power driver/clk within the SPE (e.g. it handles turning on/off peripherals and tracks usage to decide when low power modes can be entered, clocks gated, etc) * Assume asynchronous HW operations are supported within the SPE. The SPE could turn on power to the associated peripheral and start an operation and return to NSPE. Then NSPE could request enabling power to another peripheral for use by a driver in the NSPE.

Regards, Brian

From: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com> Sent: Monday, February 17, 2025 10:13 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Quach, Brian <brian@ti.commailto:brian@ti.com>; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com Subject: [EXTERNAL] Re: Adding Platform power control

Hi, Yes, it could be an option to have/add power mgmt as part of the SCMI interface. However, I see that a use-case when the consumer is on a separate PE from TF-M, so the communication channel is already done via a payload (mailbox for example).

ZjQcmQRYFpfptBannerStart

This message was sent from outside of Texas Instruments.

Do not click links or open attachments unless you recognize the source of this email and know the content is safe.

Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!trdkMXejei0aJagk3FODXEYsUKQvHG50L77wxOQTsg_iClk_eCXYo8e8UKu-GUXt-Uh7oYdIVXm1tyLDb2ffiAwFMKa7_nziZt9BBsPmu_kkr9UC8nAMx87oGmvUdPp_B1Hx$ ‌

ZjQcmQRYFpfptBannerEnd

Hi,

Yes, it could be an option to have/add power mgmt as part of the SCMI interface. However, I see that a use-case when the consumer is on a separate PE from TF-M, so the communication channel is already done via a payload (mailbox for example). Otherwise, if only local clients (same PE) are in need of power controls, then we're probably better off with a direct psa_call, so we avoid the overhead of payload + SCMI despatching. Either way we still need a driver to perform the actual power change. If we implement the interfaces nicely, SCMI partition "could" in the future use the interface into the platform_sp ( or whatever power-SP) to perform the required power changes.

Or at least, that's the way I see it.

@Brian, would you be able to provide a basic example of your use case for this need of NSPE to change some power settings?

Thanks in advnace

Hope it help

Nicola

________________________________

From: Chris.Brand--- via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 14 February 2025 16:19 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; brian@ti.commailto:brian@ti.com <brian@ti.commailto:brian@ti.com> Subject: [TF-M] Re: Adding Platform power control

I guess that could fit under the “power domain management” functionality of the SCMI interface (“the ability to place a given device or domain into the various power-saving states that it supports”). There’s a minimalist implementation of the SCMI partition (without power domain management functionality) at https://git.trustedfirmware.org/plugins/gitiles/TF-M/tf-m-extras/+/refs/head...https://urldefense.com/v3/__https:/git.trustedfirmware.org/plugins/gitiles/TF-M/tf-m-extras/*/refs/heads/main/docs/partitions/scmi_comms.rst__;Kw!!G3vK!QjWgoyDMIo8QeYS25G_Cef6PPs3S48WcgzjRAETBKFMRWO4glKTLaDfDDdKcOd49xiZf6cD61vZINeIeFA$

Chris

From: Nicola Mazzucato via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, February 14, 2025 12:57 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Quach, Brian <brian@ti.commailto:brian@ti.com> Subject: [TF-M] Re: Adding Platform power control

Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guidehttps://urldefense.com/v3/__https:/intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx__;!!G3vK!QjWgoyDMIo8QeYS25G_Cef6PPs3S48WcgzjRAETBKFMRWO4glKTLaDfDDdKcOd49xiZf6cD61vagGrfu3g$ to help you identify Phishing email.

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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 13 February 2025 22:56 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto: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.