[PATCH] arm64: dts: qcom: nord: Add EL2 overlay for remoteproc SMMU mappings

[PATCH] arm64: dts: qcom: nord: Add EL2 overlay for remoteproc SMMU mappings

[Anurag Pateriya]

Nord boards currently boot Linux under a hypervisor that manages the
IOMMU streams of the remote processor firmware. When Linux boots
directly at EL2 without the hypervisor, it owns the SMMU and must
describe the remoteproc firmware streams itself.

This path adds nord-embedded-el2.dtso overlay carrying the iommus
of the ADSP, CDSPs and SoCCP, and apply it to nord-ride-embedded
and nord-rrd to build the -el2.dtb variants.

The base DTBs are unchanged, so the existing hypervisor boot flow
is unaffected.

Signed-off-by: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>
---
Dependencies:

[PATCH v2 0/2] Add binding and driver for Nord SoCCP
https://lore.kernel.org/all/20261014-soccp_driver_dtbinding-v2-0-09d9c1378e9e@oss.qualcomm.com/

[PATCH v4 0/3] arm64: dts: qcom: nord: Enable SoCCP remoteproc support
https://lore.kernel.org/all/20261112-nord-soccp-dt-v4-0-af6e44e9f397@oss.qualcomm.com/

[PATCH RFC 0/2] Add binding and fix SoCCP carveout for booting Nord devices at EL2
https://lore.kernel.org/all/20261113-nord_embedded_el2-v1-0-48f717e97066@oss.qualcomm.com/
(allows two iommus entries for the SoCCP and maps its carveout
privileged-only; both are needed for the SoCCP entries in this overlay
to work)

To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
To: Abel Vesa <abelvesa@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Cc: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile               |  8 +++++++
 arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso | 32 +++++++++++++++++++++++++
 2 files changed, 40 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 8329c06b60a3..2e68993907ab 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -190,7 +190,15 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-poplar.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-xiaomi-sagit.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= nord-ride.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= nord-ride-embedded.dtb
+
+nord-ride-embedded-el2-dtbs	:= nord-ride-embedded.dtb nord-embedded-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM)	+= nord-ride-embedded-el2.dtb
+
 dtb-$(CONFIG_ARCH_QCOM)	+= nord-rrd.dtb
+
+nord-rrd-el2-dtbs	:= nord-rrd.dtb nord-embedded-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM)	+= nord-rrd-el2.dtb
+
 dtb-$(CONFIG_ARCH_QCOM)	+= purwa-iot-evk.dtb
 
 purwa-iot-evk-edp-dtbs	:= purwa-iot-evk.dtb purwa-iot-evk-edp.dtbo
diff --git a/arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso b/arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso
new file mode 100644
index 000000000000..50c5057f6683
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+&remoteproc_adsp {
+	iommus = <&apps_smmu_0 0x09e0 0x0>;
+};
+
+&remoteproc_cdsp0 {
+	iommus = <&apps_smmu_2 0x0360 0x0>;
+};
+
+&remoteproc_cdsp1 {
+	iommus = <&apps_smmu_2 0x0760 0x0>;
+};
+
+&remoteproc_cdsp2 {
+	iommus = <&apps_smmu_2 0x0b60 0x0>;
+};
+
+&remoteproc_cdsp3 {
+	iommus = <&apps_smmu_2 0x0f60 0x0>;
+};
+
+&remoteproc_soccp {
+	iommus = <&apps_smmu_0 0x1960 0x5>,
+		 <&apps_smmu_0 0x1966 0x0>;
+};

---
base-commit: 84470eed3bf92713b51cfb2ab38d62be932b2c09
change-id: 20261113-nord_soccp_el2_dt_change-b2e8231deab4

Best regards,
-- 
Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>

Re: [PATCH] arm64: dts: qcom: nord: Add EL2 overlay for remoteproc SMMU mappings

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] arm64: dts: qcom: unresolved remoteproc_soccp target in
  nord-embedded-el2.dtso
- [High] arm64: dts: qcom: remoteproc_adsp iommus conflicts with
  early_boot attach
- [Medium] arm64: dts: qcom: remoteproc_soccp iommus exceeds PAS binding
  maxItems
--

commit 7c3911549648c2c9a04bb237b67646f8107b1680
Author: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>

arm64: dts: qcom: nord: Add EL2 overlay for remoteproc SMMU mappings

This commit adds the nord-embedded-el2.dtso overlay to define IOMMU
streams for the ADSP, CDSP, and SoCCP remoteprocs when booting Nord
boards at EL2, and builds -el2.dtb variants for nord-ride-embedded and
nord-rrd.

> diff --git a/arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso b/arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso
> new file mode 100644
> index 0000000000000..50c5057f6683a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&remoteproc_adsp {
> +	iommus = <&apps_smmu_0 0x09e0 0x0>;
> +};

[Severity: High]
Does adding iommus to remoteproc_adsp break ADSP bringup when booting at
EL2?

In drivers/remoteproc/qcom_q6v5_pas.c, nord_adsp_resource sets
.early_boot = true, so qcom_pas_probe() sets pas->rproc->state to
RPROC_DETACHED and rproc_boot() calls rproc_attach() instead of
rproc_fw_boot().  Because rproc->has_iommu is now true, rproc_attach() ->
rproc_enable_iommu() attaches an empty IOMMU paging domain to stream
0x09e0, while qcom_pas_attach() never calls qcom_pas_map_carveout(),
causing immediate SMMU translation faults if the bootloader started ADSP.
If ADSP was not pre-started, qcom_pas_attach() resets state to
RPROC_OFFLINE and returns -EINVAL, and rproc_boot() exits without falling
back to rproc_fw_boot().

> +
> +&remoteproc_cdsp0 {
> +	iommus = <&apps_smmu_2 0x0360 0x0>;
> +};
> +
> +&remoteproc_cdsp1 {
> +	iommus = <&apps_smmu_2 0x0760 0x0>;
> +};
> +
> +&remoteproc_cdsp2 {
> +	iommus = <&apps_smmu_2 0x0b60 0x0>;
> +};
> +
> +&remoteproc_cdsp3 {
> +	iommus = <&apps_smmu_2 0x0f60 0x0>;
> +};
> +
> +&remoteproc_soccp {
> +	iommus = <&apps_smmu_0 0x1960 0x5>,
> +		 <&apps_smmu_0 0x1966 0x0>;
> +};

[Severity: High]
Does targeting &remoteproc_soccp break the dtbs build when
CONFIG_ARCH_QCOM is enabled?

Neither nord.dtsi, nord-embedded.dtsi, nord-ride-embedded.dts, nor
nord-rrd.dts defines a remoteproc_soccp label yet.  When Makefile builds
nord-ride-embedded-el2.dtb and nord-rrd-el2.dtb, fdtoverlay fails in
overlay_fixup_phandle() with -FDT_ERR_NOTFOUND because remoteproc_soccp
is missing from /__symbols__ in the base DTBs.

[Severity: Medium]
Does specifying two iommus entries on remoteproc_soccp violate the PAS
Devicetree binding and driver expectations?

Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
restricts iommus to maxItems: 1, which causes dtbs_check to fail.  In
addition, qcom_q6v5_pas has no Nord SoCCP match entry yet, and
qcom_pas_map_carveout() maps carveouts with IOMMU_READ | IOMMU_WRITE
without the IOMMU_PRIV flag needed for the privileged SoCCP stream.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113-nord_soccp_el2_dt_change-v1-1-2a7aa55d97dd@oss.qualcomm.com?part=1