Hi Yann,

It is better to introduce the abstract the MHU communication.

The current communication between the platform and RSE is tightly coupled with MHU. This layer would abstract the communication interface, allowing different underlying mechanisms (such as MHU, or alternative protocols) to be used seamlessly without altering the higher-level logic. By decoupling the communication mechanism from MHU, you can make these psa call available for every platform. The abstraction layer can provide a unified API , which would internally select the appropriate method (MHU or other) based on the platform's capabilities.

I agree with David that using the existing flag PLAT_MHU_VERSION could be misleading. It would be better to repurpose this macro as PLAT_MHU=<NO_MHU, MHUv1, MHUv2, ...> and use it accordingly in the code. Adding another option on top of the existing PLAT_MHU_VERSION macro may unnecessarily clutter the macros.

I'm curious to know where you plan to use these psa_call functions, as the current definition of this is in rse_comm.c, which I believe may not be right place for your needs if you want to generalise this definition.

Thanks, Manish Badarkhe ________________________________ From: David Vincze David.Vincze@arm.com Sent: 24 September 2024 08:41 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org; Yann Gautier yann.gautier@foss.st.com Cc: Tamas Ban Tamas.Ban@arm.com; Raef Coles Raef.Coles@arm.com; Manish Badarkhe Manish.Badarkhe@arm.com; Olivier Deprez Olivier.Deprez@arm.com Subject: Re: [TF-A] PSA calls with RSE comms and MHU

Hi Yann,

You are right, the RSE comms is basically a custom RPC protocol between the application processor and RSE which is coupled

with MHUs (acting as the data link layer). The RSE comms sounds like it’s specific to this platform component (RSE) but the protocol itself could be extended to other platforms as well I believe. The platform dependency here is the MHU, how the data is transferred.

Your approach could work, adding an extra data layer between the abstract MHU communication (include/drivers/arm/mhu.h) and the RSE comms protocol – hiding the platform specifics of the data transfer. However, setting PLAT_MHU_VERSION to 0 would be misleading to some extent I think.

I would rather introduce a new build option for clarity.

What others think?

Regards, David

From: Olivier Deprez Olivier.Deprez@arm.com Date: Monday, 23 September 2024 at 14:14 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org, Yann Gautier yann.gautier@foss.st.com Cc: Tamas Ban Tamas.Ban@arm.com, Raef Coles Raef.Coles@arm.com, David Vincze David.Vincze@arm.com, Manish Badarkhe Manish.Badarkhe@arm.com Subject: Re: [TF-A] PSA calls with RSE comms and MHU

+few stakeholders in Cc

________________________________

From: Yann Gautier via TF-A tf-a@lists.trustedfirmware.org Sent: 23 September 2024 11:28

To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org

Subject: [TF-A] PSA calls with RSE comms and MHU

Hello,

I would like to use PSA calls for an application on STM32MP2 platform. I've seen the psa_call() API that I could use, in drivers/arm/rse/rse_comms.c.

The problem is that it is based on MHU mailbox, which I don't have on STM32MP2. So I was planning plan to disentangle RSE comms and MHU, having a new file in the same directory to manage MHU. This code should then be under a flag, I could re-use PLAT_MHU_VERSION. Setting it to 0, would mean no MHU.

AFAICT TF-M uses that split with a dedicated file: rse_comms_hal.c: Abstracts MHU message sending and receiving. (see https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html).

Do you think this approach sounds right?

Thanks, Yann -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

Hi,

I've pushed 2 patches there: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/31258 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/31259

I've preferred putting the flag renaming in a dedicated patch, as it is a breaking change.

Best regards, Yann

On 9/24/24 14:33, Yann Gautier via TF-A wrote:

Hi,

Thanks for your answers!

I agree having PLAT_MHU_VERSION=0 could be misleading. I'll try with your proposition Manish. I have a first patch almost ready. I can post it as a WIP in the afternoon, to check if it is in line with what you have in mind. The documentation will also need update, I haven't done that part yet.

On STM32MP2, we can boot either on Cortex-A35 or on Cortex-M33. The first booting processor controls the security of the platform, and especially keys in OTP. If Cortex-M33 boots first, we then need a way to handle keys for FIP encryption for example. This would be done through PSA keys API. This would then be easier if we could use psa_call here.

Best regards, Yann

On 9/24/24 12:30, Manish Badarkhe wrote:

...

Hi Yann,

It is better to introduce the abstract the MHU communication.

The current communication between the platform and RSE is tightly coupled with MHU.  This layer would abstract the communication interface, allowing different underlying mechanisms (such as MHU, or alternative protocols) to be used seamlessly without altering the higher-level logic. By decoupling the communication mechanism from MHU, you can make these psa call available for every platform. The abstraction layer can provide a unified API , which would internally select the appropriate method (MHU or other) based on the platform's capabilities.

I agree with David that using the existing flag PLAT_MHU_VERSION could be misleading. It would be better to repurpose this macro as PLAT_MHU=<NO_MHU, MHUv1, MHUv2, ...> and use it accordingly in the code. Adding another option on top of the existing PLAT_MHU_VERSION macro may unnecessarily clutter the macros.

I'm curious to know where you plan to use these |psa_call| functions, as the current definition of this is in |rse_comm.c|, which I believe may not be right place for your needs if you want to generalise this definition.

Thanks, Manish Badarkhe

---

*From:* David Vincze David.Vincze@arm.com *Sent:* 24 September 2024 08:41 *To:* tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org; Yann Gautier yann.gautier@foss.st.com *Cc:* Tamas Ban Tamas.Ban@arm.com; Raef Coles Raef.Coles@arm.com; Manish Badarkhe Manish.Badarkhe@arm.com; Olivier Deprez Olivier.Deprez@arm.com *Subject:* Re: [TF-A] PSA calls with RSE comms and MHU

Hi Yann,

You are right, the RSE comms is basically a custom RPC protocol between the application processor and RSE which is coupled

with MHUs (acting as the data link layer). The RSE comms sounds like it’s specific to this platform component (RSE) but the protocol itself could be extended to other platforms as well I believe. The platform dependency here is the MHU, how the data is transferred.

Your approach could work, adding an extra data layer between the abstract MHU communication (include/drivers/arm/mhu.h) and the RSE comms protocol – hiding the platform specifics of the data transfer. However, setting PLAT_MHU_VERSION to 0 would be misleading to some extent I think.

I would rather introduce a new build option for clarity.

What others think?

Regards, David

*From: *Olivier Deprez Olivier.Deprez@arm.com *Date: *Monday, 23 September 2024 at 14:14 *To: *tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org, Yann Gautier yann.gautier@foss.st.com *Cc: *Tamas Ban Tamas.Ban@arm.com, Raef Coles Raef.Coles@arm.com, David Vincze David.Vincze@arm.com, Manish Badarkhe Manish.Badarkhe@arm.com *Subject: *Re: [TF-A] PSA calls with RSE comms and MHU

+few stakeholders in Cc

---

*From:* Yann Gautier via TF-A tf-a@lists.trustedfirmware.org *Sent:* 23 September 2024 11:28

*To:* tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org

*Subject:* [TF-A] PSA calls with RSE comms and MHU

Hello,

I would like to use PSA calls for an application on STM32MP2 platform. I've seen the psa_call() API that I could use, in drivers/arm/rse/rse_comms.c.

The problem is that it is based on MHU mailbox, which I don't have on STM32MP2. So I was planning plan to disentangle RSE comms and MHU, having a new file in the same directory to manage MHU. This code should then be under a flag, I could re-use PLAT_MHU_VERSION. Setting it to 0, would mean no MHU.

AFAICT TF-M uses that split with a dedicated file: rse_comms_hal.c: Abstracts MHU message sending and receiving. (see _https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html) https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html)_.

Do you think this approach sounds right?

Thanks, Yann -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org