Message ID | 20240115135249.296822-3-arnaud.pouliquen@foss.st.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-26057-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp1714417dyc; Mon, 15 Jan 2024 05:55:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IF2ECbR1CTDWNx0pTq2uCjCVcu++iOckYXKNTFqIPnEzQdNK3H1v3xHmlt2kSY9huvaBANx X-Received: by 2002:a05:6a20:1008:b0:19a:2daf:1f86 with SMTP id gs8-20020a056a20100800b0019a2daf1f86mr4269367pzc.123.1705326908760; Mon, 15 Jan 2024 05:55:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705326908; cv=none; d=google.com; s=arc-20160816; b=W1HWn6OD1RTkSsfM6XX/cAavllHjFPrNLNEjH0T7AQN8aRhEYf73VN6tFHk4k3ZQiW 9XDWLkyCKfG0caSrXrtJOEywXFTsPyz7peT/s5RzSmDh48XK+Eq+8nM2Mbd73O1I9TbP gKFZ7e15jKHsnyIVfF8ZHYJwiccxio6rIFWnKukC+XBhIud0of6MHjH7QPEiDd7ISkxe bKV5+rHr5Aw9ue7zk5aBHLvdETCVryt92aaE9/pspYvDIYRrysyXvTpNc2f/A4Fdrz3G uCP5Uy6mJ5MzWtsymiEXtY9iRYzA4w3QmvGenFB7RCi77gcpfS7EO22j/KpJE1Cuk6FB KxcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=sxQobYGUiCH3u40trshtn0GkDMW94xPV+Pu/7IQRPbM=; fh=v3NBvV5+vj//chOYHzS5ZDleqozbh7nyGvHDjEWDUSE=; b=MLyfeWtxhQKnFnd7Kg96tzG+rUcVBH0CwxN9ZoirABEUk2/IVh+g2yMtZ1UOX94Mi1 kBR1FEvPJNuOVnuWwyUrCOSAIGEPrheNSEa+ykopwCDzv0Ba8zgbk9njYYF1TaSHrjGc HY4sXZIrlzy2e+Y5KckU9tfemouzpIAvFel97Mw3rL7zBEeebFc6ElkqEqBCSW3tCDCS ROFP6pMky0CVtmPHVPUv1Bwvtgul4TJs+TMfM95H9IbHFdSKfn2fKDfJYpIPpcB6kCMe jpVEWbCDw8oGiMDXesiT/KLP5Mz5yPl6PvxkWrX950B6fTalZaXj4m5EUkwDaIjD1o82 bw8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=1iVouvkt; spf=pass (google.com: domain of linux-kernel+bounces-26057-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26057-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id p12-20020a17090a868c00b0028cfa2f740asi11523781pjn.12.2024.01.15.05.55.08 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 05:55:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-26057-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=1iVouvkt; spf=pass (google.com: domain of linux-kernel+bounces-26057-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26057-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 5D37628286D for <ouuuleilei@gmail.com>; Mon, 15 Jan 2024 13:55:08 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3CC871775F; Mon, 15 Jan 2024 13:54:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=foss.st.com header.i=@foss.st.com header.b="1iVouvkt" Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B769817543; Mon, 15 Jan 2024 13:54:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 40FDQbYZ022593; Mon, 15 Jan 2024 14:53:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s= selector1; bh=sxQobYGUiCH3u40trshtn0GkDMW94xPV+Pu/7IQRPbM=; b=1i VouvktE8O1Jap+NVWRSLMClxDqeqrMGNQw3t6I4SmPk1oaLDSvLuMGKK98GzjfeO F6HFF1cOypBfkIhSW14qq6p6BUkxSBMQY8jXLZF2HtTjf7NPysJoIkmBcSfwmqFn E0KdM+M8XQNG3mHCXteB8DuddIvNH0tQXEBP0pxys38cjk9LnN37jn2cwtIFWnBR o5ucVKuAdvADFW63sLR3hfYsj/dGklo3plo6Z0i8RkUhs951nxbkfeQ2B26vi0Vf 5O6Wp9XCkLx6dSEVtV2J2SN7wiAt40VsT5g3hwMHECMVduv/gR/SM+m32a2UChck wyICAUDCvQn69SRdPpmA== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3vkmbh0se3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Jan 2024 14:53:59 +0100 (CET) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 13E68100058; Mon, 15 Jan 2024 14:53:59 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node2.st.com [10.75.129.70]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 0B95228EF81; Mon, 15 Jan 2024 14:53:59 +0100 (CET) Received: from localhost (10.201.20.75) by SHFDAG1NODE2.st.com (10.75.129.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Mon, 15 Jan 2024 14:53:58 +0100 From: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> To: Bjorn Andersson <andersson@kernel.org>, Mathieu Poirier <mathieu.poirier@linaro.org>, Jens Wiklander <jens.wiklander@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> CC: <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, <linux-remoteproc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <op-tee@lists.trustedfirmware.org>, <devicetree@vger.kernel.org>, Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Subject: [PATCH 2/4] dt-bindings: remoteproc: add compatibility for TEE support Date: Mon, 15 Jan 2024 14:52:47 +0100 Message-ID: <20240115135249.296822-3-arnaud.pouliquen@foss.st.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240115135249.296822-1-arnaud.pouliquen@foss.st.com> References: <20240115135249.296822-1-arnaud.pouliquen@foss.st.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: EQNCAS1NODE3.st.com (10.75.129.80) To SHFDAG1NODE2.st.com (10.75.129.70) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-05_08,2024-01-05_01,2023-05-22_02 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788164868494706923 X-GMAIL-MSGID: 1788164868494706923 |
Series |
Introduction of a remoteproc tee to load signed firmware
|
|
Commit Message
Arnaud POULIQUEN
Jan. 15, 2024, 1:52 p.m. UTC
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted execution Environment
(TEE).
This compatible is used in both the Linux and OP-TEE device-tree.
- In OP-TEE, a node is defined in the device tree with the
st,stm32mp1-m4-tee to support signed remoteproc firmware.
Based on DT properties, OP-TEE authenticates, loads, starts, and stops
the firmware.
- On Linux, when the compatibility is set, the Cortex-M resets should not
be declared in the device tree.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
---
.../bindings/remoteproc/st,stm32-rproc.yaml | 53 +++++++++++++++----
1 file changed, 44 insertions(+), 9 deletions(-)
Comments
On Mon, Jan 15, 2024 at 02:52:47PM +0100, Arnaud Pouliquen wrote: > The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration > where the Cortex-M4 firmware is loaded by the Trusted execution Environment > (TEE). > This compatible is used in both the Linux and OP-TEE device-tree. > - In OP-TEE, a node is defined in the device tree with the > st,stm32mp1-m4-tee to support signed remoteproc firmware. > Based on DT properties, OP-TEE authenticates, loads, starts, and stops > the firmware. > - On Linux, when the compatibility is set, the Cortex-M resets should not > be declared in the device tree. > > Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> > --- > .../bindings/remoteproc/st,stm32-rproc.yaml | 53 +++++++++++++++---- > 1 file changed, 44 insertions(+), 9 deletions(-) > > diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > index 370af61d8f28..9fdfa30eff20 100644 > --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > @@ -16,7 +16,12 @@ maintainers: > > properties: > compatible: > - const: st,stm32mp1-m4 > + enum: > + - st,stm32mp1-m4 > + - st,stm32mp1-m4-tee > + description: > + Use "st,stm32mp1-m4" for the Cortex-M4 coprocessor management by Linux What if other OSs want to manage the M4? > + Use "st,stm32mp1-m4-tee" for the Cortex-M4 coprocessor management by secure context > > reg: > description: > @@ -142,21 +147,41 @@ properties: > required: > - compatible > - reg > - - resets > > allOf: > - if: > properties: > - reset-names: > - not: > - contains: > - const: hold_boot > + compatible: > + contains: > + const: st,stm32mp1-m4 > + then: > + if: > + properties: > + reset-names: > + not: > + contains: > + const: hold_boot > + then: > + required: > + - st,syscfg-holdboot > + - resets > + else: > + properties: > + st,syscfg-holdboot: false > + required: > + - reset-names Looks like a new required property. > + - resets > + > + - if: > + properties: > + compatible: > + contains: > + const: st,stm32mp1-m4-tee > then: > - required: > - - st,syscfg-holdboot > - else: > properties: > st,syscfg-holdboot: false > + reset-names: false > + resets: false > > additionalProperties: false > > @@ -188,5 +213,15 @@ examples: > st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>; > st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>; > }; > + - | > + #include <dt-bindings/reset/stm32mp1-resets.h> > + m4@10000000 { > + compatible = "st,stm32mp1-m4-tee"; > + reg = <0x10000000 0x40000>, > + <0x30000000 0x40000>, > + <0x38000000 0x10000>; > + st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>; > + st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>; > + }; > > ... > -- > 2.25.1 >
On 1/16/24 20:21, Rob Herring wrote: > On Mon, Jan 15, 2024 at 02:52:47PM +0100, Arnaud Pouliquen wrote: >> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration >> where the Cortex-M4 firmware is loaded by the Trusted execution Environment >> (TEE). >> This compatible is used in both the Linux and OP-TEE device-tree. >> - In OP-TEE, a node is defined in the device tree with the >> st,stm32mp1-m4-tee to support signed remoteproc firmware. >> Based on DT properties, OP-TEE authenticates, loads, starts, and stops >> the firmware. >> - On Linux, when the compatibility is set, the Cortex-M resets should not >> be declared in the device tree. >> >> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> >> --- >> .../bindings/remoteproc/st,stm32-rproc.yaml | 53 +++++++++++++++---- >> 1 file changed, 44 insertions(+), 9 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml >> index 370af61d8f28..9fdfa30eff20 100644 >> --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml >> +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml >> @@ -16,7 +16,12 @@ maintainers: >> >> properties: >> compatible: >> - const: st,stm32mp1-m4 >> + enum: >> + - st,stm32mp1-m4 >> + - st,stm32mp1-m4-tee >> + description: >> + Use "st,stm32mp1-m4" for the Cortex-M4 coprocessor management by Linux > > What if other OSs want to manage the M4? Right, for instance this compatibles are also used by U-boot. I will change "by Linux" by "by non secure context" > >> + Use "st,stm32mp1-m4-tee" for the Cortex-M4 coprocessor management by secure context >> >> reg: >> description: >> @@ -142,21 +147,41 @@ properties: >> required: >> - compatible >> - reg >> - - resets >> >> allOf: >> - if: >> properties: >> - reset-names: >> - not: >> - contains: >> - const: hold_boot >> + compatible: >> + contains: >> + const: st,stm32mp1-m4 >> + then: >> + if: >> + properties: >> + reset-names: >> + not: >> + contains: >> + const: hold_boot >> + then: >> + required: >> + - st,syscfg-holdboot >> + - resets >> + else: >> + properties: >> + st,syscfg-holdboot: false >> + required: >> + - reset-names > > Looks like a new required property. I just realize that it does not make sense. We execute this only if "reset-names" contains "hold_boot". I will remove it Thanks! Arnaud > >> + - resets >> + >> + - if: >> + properties: >> + compatible: >> + contains: >> + const: st,stm32mp1-m4-tee >> then: >> - required: >> - - st,syscfg-holdboot >> - else: >> properties: >> st,syscfg-holdboot: false >> + reset-names: false >> + resets: false >> >> additionalProperties: false >> >> @@ -188,5 +213,15 @@ examples: >> st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>; >> st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>; >> }; >> + - | >> + #include <dt-bindings/reset/stm32mp1-resets.h> >> + m4@10000000 { >> + compatible = "st,stm32mp1-m4-tee"; >> + reg = <0x10000000 0x40000>, >> + <0x30000000 0x40000>, >> + <0x38000000 0x10000>; >> + st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>; >> + st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>; >> + }; >> >> ... >> -- >> 2.25.1 >>
diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 370af61d8f28..9fdfa30eff20 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -16,7 +16,12 @@ maintainers: properties: compatible: - const: st,stm32mp1-m4 + enum: + - st,stm32mp1-m4 + - st,stm32mp1-m4-tee + description: + Use "st,stm32mp1-m4" for the Cortex-M4 coprocessor management by Linux + Use "st,stm32mp1-m4-tee" for the Cortex-M4 coprocessor management by secure context reg: description: @@ -142,21 +147,41 @@ properties: required: - compatible - reg - - resets allOf: - if: properties: - reset-names: - not: - contains: - const: hold_boot + compatible: + contains: + const: st,stm32mp1-m4 + then: + if: + properties: + reset-names: + not: + contains: + const: hold_boot + then: + required: + - st,syscfg-holdboot + - resets + else: + properties: + st,syscfg-holdboot: false + required: + - reset-names + - resets + + - if: + properties: + compatible: + contains: + const: st,stm32mp1-m4-tee then: - required: - - st,syscfg-holdboot - else: properties: st,syscfg-holdboot: false + reset-names: false + resets: false additionalProperties: false @@ -188,5 +213,15 @@ examples: st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>; st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>; }; + - | + #include <dt-bindings/reset/stm32mp1-resets.h> + m4@10000000 { + compatible = "st,stm32mp1-m4-tee"; + reg = <0x10000000 0x40000>, + <0x30000000 0x40000>, + <0x38000000 0x10000>; + st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>; + st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>; + }; ...