Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
To: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Sumit Garg <sumit.garg@kernel.org>
Cc: <devicetree@vger.kernel.org>, <linux-remoteproc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<op-tee@lists.trustedfirmware.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Jens Wiklander <jens.wiklander@linaro.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Bjorn Andersson <andersson@kernel.org>
Subject: Re: [Linux-stm32] [PATCH v22 0/7] Introduction of a remoteproc tee to load signed firmware
Date: Tue, 19 May 2026 08:58:57 +0200	[thread overview]
Message-ID: <c57479c8-6d86-4c64-bbee-629d51890a38@foss.st.com> (raw)
In-Reply-To: <617b40df-6e51-44d0-9803-60b2e47217ff@foss.st.com>

Hello Krzysztof, Rob, and Sumit,

This series is still awaiting your review of the bindings.

Please let me know if you are waiting for anything from my side before 
reviewing it.

Thank you in advance,
Arnaud


On 5/6/26 09:20, Arnaud POULIQUEN wrote:
> Hello,
> 
> Just a gentle reminder: as a first step, I would appreciate it if we 
> could at least finalize the discussion on the bindings based on phandles.
> 
> Thanks,
> Arnaud
> 
> On 4/14/26 17:28, Arnaud Pouliquen wrote:
>> Main updates from version V21[1]:
>> --------------------------------
>> This version removes the st,stm32mp1-m4-tee compatibility string,
>> which no longer seems to be accepted by the Devicetree maintainers.
>> As a consequence, the stm32-rproc-tee driver, introduced to simplify
>> the code, is removed. The STM32 integration reuses the existing
>> stm32_rproc driver implemented in V19.
>>
>> The devicetree is now structured as follows:
>>
>>      firmware {
>>          tee_rproc: optee-rproc {
>>              compatible = "80a4c275-0a47-4905-8285-1486a9771a08";
>>          };
>>      };
>>
>>      m4: m4@10000000 {
>>        compatible = "st,stm32mp1-m4";
>>        reg = <0x10000000 0x40000>,
>>              <0x30000000 0x40000>,
>>              <0x38000000 0x10000>;
>>
>>        mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>, <&ipcc 3>;
>>        mbox-names = "vq0", "vq1", "shutdown", "detach";
>>
>>        memory-region = <&vdev0vring0>, <&m_ipc_shm>, <&mcuram2>,
>>                        <&vdev0vring1>, <&vdev0buffer>, <&retram>;
>>
>>        interrupt-parent = <&exti>;
>>        interrupts = <68 1>;
>>
>>        st,rproc-tee = <&tee_rproc 0>;
>>
>>        status = "okay";
>>      };
>>
>> As a consequence, this version:
>> - reintroduce v19 commits for stm32_rproc.c driver , adding the support
>>    of the st,rproc-tee binding.
>> - drops the dedicated remoteproc-tee.yaml and st,stm32-rproc-tee.yaml
>>    bindings from the series.
>> - extends st,stm32-rproc.yaml with st,rproc-tee to describe the link to
>>    the TEE remoteproc backend.
>> - removes the dedicated stm32_rproc_tee.c driver and reuses stm32_rproc.c
>>    for both native and TEE-controlled cases.
>> - keeps remoteproc_tee.c aligned with the phandle-based lookup introduced
>>    in v21 and uses a device_link between the STM32 remoteproc instance 
>> and
>>    the TEE backend device.
>>
>> More details are available in each patch commit message.
>>
>> Main updates from version V20[3]:
>> --------------------------------
>> To address Rob’s concern on v20concerning resource declaration under the
>> tee node, the device tree is now structured as follows,replacing the
>> child-parent hierarchy with a phandle:
>>
>>      firmware {
>>          tee_rproc: optee-rproc {
>>              compatible = "80a4c275-0a47-4905-8285-1486a9771a08";
>>          };
>>      };
>>
>>      m4: m4@0 {
>>        compatible = "st,stm32mp1-m4-tee";
>>        reg = <0 0>;
>>
>>        mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
>>        mbox-names = "vq0", "vq1", "shutdown";
>>
>>        memory-region = <&vdev0vring0>, <&m_ipc_shm>, <&mcuram2>,
>>                        <&vdev0vring1>, <&vdev0buffer>, <&retram>;
>>
>>        interrupt-parent = <&exti>;
>>        interrupts = <68 1>;
>>
>>        rproc-tee-phandle = <&tee_rproc 0>;
>>        st,auto-boot;
>>        wakeup-source;
>>
>>        status = "okay";
>>      };
>>
>> As a consequence, this version:
>> - Updates the device tree and bindings to:
>>    - Change the compatible property from
>>      "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08" to
>>      "80a4c275-0a47-4905-8285-1486a9771a08".
>>    - Use the rproc-tee-phandle to avoid the parent-child hierarchy.
>> - Updates stm32_rproc_tee.c and remoteproc_tee.c to adapt to the new 
>> bindings.
>> - Updates remoteproc_tee.c to compute the device tree compatible 
>> string from
>>    the TEE UUID.
>>
>> Main updates from version V19[4]:
>> --------------------------------
>> The devicetree is now structured as follows:
>>
>>     firmware {
>>         optee {
>>             compatible = "linaro,optee-tz";
>>             method = "smc";
>>             #address-cells = <1>;
>>             #size-cells = <0>;
>>             rproc-service@0 {
>>                 compatible = "rproc- 
>> service-80a4c275-0a47-4905-8285-1486a9771a08";
>>                 reg = <0>;
>>                 #address-cells = <1>;
>>                 #size-cells = <0>;
>>                 status = "okay";
>>                 m4: m4@0 {
>>                     compatible = "st,stm32mp15-m4-tee";
>>                     reg = <0>;
>>                     mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
>>                     mbox-names = "vq0", "vq1", "shutdown";
>>                     memory-region = <&vdev0vring0>,    <&m_ipc_shm>, 
>> <&mcuram2>,
>>                             <&vdev0vring1>, <&vdev0buffer>, <&retram>;
>>                     interrupt-parent = <&exti>;
>>                     interrupts = <68 1>;
>>                     status = "okay";
>>                 };
>>             };
>>         };
>>     };
>>
>> As a consequence, this version:
>>
>> - Introduces a new stm32_rproc_tee.c remoteproc driver.
>>
>>    Instead of further complicating the existing stm32_rproc.c driver, a
>>    dedicated TEE-based driver is added. Both drivers are intended to also
>>    support the STM32MP2x Cortex-M33 remote processor in a next step.
>>
>> - Reworks the bindings:
>>    - Drop the st,stm32-rproc.yaml updates that were introduced in 
>> previous
>>      revisions.
>>    - Add remoteproc-tee.yaml for the
>>      "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08" compatible.
>>    - Add st,stm32-rproc-tee.yaml for the "st,stm32mp15-m4-tee" 
>> compatible.
>>
>> - Reworks the probing sequence:
>>
>>    The m4@0 device is now probed by the remoteproc-tee driver, which 
>> itself
>>    is instantiated by the TEE (OP-TEE) bus.
>>
>> More details are available in each patch commit message.
>>
>> [1] https://lore.kernel.org/linux-remoteproc/20260317180329.1207625-1- 
>> arnaud.pouliquen@foss.st.com/
>> [2] https://lore.kernel.org/linux-remoteproc/20251217153917.3998544-1- 
>> arnaud.pouliquen@foss.st.com/
>> [3] https://lore.kernel.org/linux-devicetree/20250625094028.758016-1- 
>> arnaud.pouliquen@foss.st.com/
>>
>>
>> Tested-on:
>> ---------
>> commit 591cd656a1bf ("Linux 7.0-rc7")
>>
>> Description of the feature:
>> --------------------------
>> This series proposes the implementation of a remoteproc tee driver to
>> communicate with a TEE trusted application responsible for authenticating
>> and loading the remoteproc firmware image in an Arm secure context.
>>
>> 1) Principle:
>>
>> The remoteproc tee driver provides services to communicate with the 
>> OP-TEE
>> trusted application running on the Trusted Execution Context (TEE).
>> The trusted application in TEE manages the remote processor lifecycle:
>>
>> - authenticating and loading firmware images,
>> - isolating and securing the remote processor memories,
>> - supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33),
>> - managing the start and stop of the firmware by the TEE.
>>
>> 2) Format of the signed image:
>>
>> Refer to:
>> https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/ 
>> remoteproc_core.c#L18-L57
>>
>> 3) OP-TEE trusted application API:
>>
>> Refer to:
>> https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ 
>> ta_remoteproc.h
>>
>> 4) OP-TEE signature script
>>
>> Refer to:
>> https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py
>>
>> Example of usage:
>> sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> 
>> --key ${OP-TEE_PATH}/keys/default.pem
>>
>>
>> 5) Impact on User space Application
>>
>> No sysfs impact. The user only needs to provide the signed firmware image
>> instead of the ELF image.
>>
>>
>> For more information about the implementation, a presentation is 
>> available here
>> (note that the format of the signed image has evolved between the 
>> presentation
>> and the integration in OP-TEE).
>>
>> https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds
>>
>> Arnaud Pouliquen (7):
>>    dt-bindings: firmware: Add TEE remoteproc service binding
>>    dt-bindings: remoteproc: st,stm32-rproc: add st,rproc-tee
>>    remoteproc: core: Introduce rproc_pa_to_va helper
>>    remoteproc: Introduce optional release_fw operation
>>    remoteproc: Add TEE support
>>    remoteproc: stm32: Create sub-functions to request shutdown and
>>      release
>>    remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
>>
>>   .../bindings/remoteproc/remoteproc-tee.yaml   |  36 +
>>   .../bindings/remoteproc/st,stm32-rproc.yaml   |  55 +-
>>   drivers/remoteproc/Kconfig                    |  10 +
>>   drivers/remoteproc/Makefile                   |   1 +
>>   drivers/remoteproc/remoteproc_core.c          |  56 ++
>>   drivers/remoteproc/remoteproc_internal.h      |   6 +
>>   drivers/remoteproc/remoteproc_tee.c           | 789 ++++++++++++++++++
>>   drivers/remoteproc/stm32_rproc.c              | 249 ++++--
>>   include/linux/remoteproc.h                    |   6 +
>>   include/linux/remoteproc_tee.h                |  98 +++
>>   10 files changed, 1220 insertions(+), 86 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/remoteproc/ 
>> remoteproc-tee.yaml
>>   create mode 100644 drivers/remoteproc/remoteproc_tee.c
>>   create mode 100644 include/linux/remoteproc_tee.h
>>
>>
>> base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
> 
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32



      reply	other threads:[~2026-05-19  6:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 15:28 [PATCH v22 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
2026-04-14 15:28 ` [PATCH v22 1/7] dt-bindings: firmware: Add TEE remoteproc service binding Arnaud Pouliquen
2026-04-14 15:28 ` [PATCH v22 2/7] dt-bindings: remoteproc: st,stm32-rproc: add st,rproc-tee Arnaud Pouliquen
2026-04-14 15:28 ` [PATCH v22 3/7] remoteproc: core: Introduce rproc_pa_to_va helper Arnaud Pouliquen
2026-04-14 15:28 ` [PATCH v22 4/7] remoteproc: Introduce optional release_fw operation Arnaud Pouliquen
2026-04-14 15:29 ` [PATCH v22 5/7] remoteproc: Add TEE support Arnaud Pouliquen
2026-04-14 15:29 ` [PATCH v22 6/7] remoteproc: stm32: Create sub-functions to request shutdown and release Arnaud Pouliquen
2026-04-14 15:29 ` [PATCH v22 7/7] remoteproc: stm32: add OP-TEE backend support Arnaud Pouliquen
2026-05-06  7:20 ` [PATCH v22 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud POULIQUEN
2026-05-19  6:58   ` Arnaud POULIQUEN [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c57479c8-6d86-4c64-bbee-629d51890a38@foss.st.com \
    --to=arnaud.pouliquen@foss.st.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jens.wiklander@linaro.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=robh+dt@kernel.org \
    --cc=sumit.garg@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox