[PATCH v3 0/4] remoteproc: add Cortex-A Core remoteproc support on i.MX platforms

[PATCH v3 0/4] remoteproc: add Cortex-A Core remoteproc support on i.MX platforms

[Jiafei Pan]

This patch series is to add remoteproc support on Cortex-A Core of i.MX platforms:
1. Adding dts binding for Cortex-A Core remoteproc
2. Enable Cortex-A Core remoteproc support in remoteproc driver
3. Adding dts example on imx93 platforms.

Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>

---
Changes in v3:
- Fixed dt_binding_check warnings
- Updated prefix of patch subject

Changes in v2:
- Update arch/arm64/boot/dts/freescale/Makefile to add new dts

---
Hou Zhiqiang (1):
  remoteproc: imx_rproc: add autoboot support for A-core

Jiafei Pan (3):
  dt-bindings: remoteproc: add imx-rproc-psci
  remoteproc: imx_rproc: add support for Cortex-A Core
  arm64: dts: imx93: Cortex-A Core remoteproc device node

 .../remoteproc/fsl,imx-rproc-psci.yaml        |  51 ++++++
 arch/arm64/boot/dts/freescale/Makefile        |   2 +
 .../imx93-11x11-evk-multicore-rtos.dts        |  39 +++++
 .../imx93-14x14-evk-multicore-rtos.dts        |  39 +++++
 .../boot/dts/freescale/imx93-rproc-ca55.dtsi  |  14 ++
 drivers/remoteproc/imx_rproc.c                | 150 ++++++++++++++++++
 drivers/remoteproc/imx_rproc.h                |   2 +
 7 files changed, 297 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-14x14-evk-multicore-rtos.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi

-- 
2.43.0

[PATCH v3 1/4] dt-bindings: remoteproc: add imx-rproc-psci

[Jiafei Pan]

Add compatible string "fsl,imx-rproc-psci" for i.MX Cortex-A Core's
remoteproc support.

Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>

---
Changes in v3:
- Fixed dt_binding_check warnings

---
 .../remoteproc/fsl,imx-rproc-psci.yaml        | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
new file mode 100644
index 000000000000..28d00dbf8bc7
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/fsl,imx-rproc-psci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX Cortex-A Core Remote Processor via PSCI
+
+maintainers:
+  - Jiafei Pan <Jiafei.Pan@nxp.com>
+
+description:
+  This binding provides support for managing Cortex-A cores as remote
+  processors on i.MX platforms using the PSCI (Power State Coordination
+  Interface) for CPU power management operations. This allows single
+  Cortex-A core or multiple Cortex-A cores to be controlled by Linux as
+  a remote processor, enabling them to run RTOS or bare-metal applications.
+
+properties:
+  compatible:
+    const: fsl,imx-rproc-psci
+
+  fsl,cpus-mask:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Bitmask indicating which CPU cores are assigned to this remote
+      processor instance. Each bit represents a CPU core, where bit N
+      corresponds to CPU N. For example, 0x2 (0b10) assigns CPU core 1,
+      while 0x6 (0b110) assigns CPU cores 1 and 2.
+
+  memory-region:
+    maxItems: 1
+    description:
+      Phandle to a reserved memory region to be used for the remote
+      processor's code and data.
+
+required:
+  - compatible
+  - fsl,cpus-mask
+  - memory-region
+
+additionalProperties: false
+
+examples:
+  - |
+        remoteproc-ca55-1 {
+            compatible = "fsl,imx-rproc-psci";
+            /* bitmask: 0b10, assign A55 Core 1 */
+            fsl,cpus-mask = <0x2>;
+            memory-region = <&rtos_ca55_reserved>;
+        };
-- 
2.43.0

[PATCH v3 2/4] remoteproc: imx_rproc: add support for Cortex-A Core

[Jiafei Pan]

Add Cortex-A Core remoteproc support, it use PSCI and SIP SMC call
to manage Cortex-A Core to be on or off.

Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
---

Changes in v3:
- Updated prefix of patch subject

---
 drivers/remoteproc/imx_rproc.c | 134 +++++++++++++++++++++++++++++++++
 drivers/remoteproc/imx_rproc.h |   2 +
 2 files changed, 136 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 0dd80e688b0e..8a3de27c96b7 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -6,6 +6,7 @@
 #include <dt-bindings/firmware/imx/rsrc.h>
 #include <linux/arm-smccc.h>
 #include <linux/clk.h>
+#include <linux/cpu.h>
 #include <linux/err.h>
 #include <linux/firmware/imx/sci.h>
 #include <linux/firmware/imx/sm.h>
@@ -20,12 +21,17 @@
 #include <linux/platform_device.h>
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
+#include <linux/psci.h>
 #include <linux/reboot.h>
 #include <linux/regmap.h>
 #include <linux/remoteproc.h>
 #include <linux/scmi_imx_protocol.h>
 #include <linux/workqueue.h>
 
+#include <uapi/linux/psci.h>
+
+#include <asm/smp_plat.h>
+
 #include "imx_rproc.h"
 #include "remoteproc_internal.h"
 
@@ -72,6 +78,8 @@
 #define IMX_SIP_RPROC_STARTED		0x01
 #define IMX_SIP_RPROC_STOP		0x02
 
+#define IMX_SIP_CPU_OFF			0xC2000012
+
 #define IMX_SC_IRQ_GROUP_REBOOTED	5
 
 /**
@@ -131,6 +139,9 @@ struct imx_rproc {
 	 * BIT 0: IMX_RPROC_FLAGS_SM_LMM_CTRL(RPROC LM is under Linux control )
 	 */
 	u32				flags;
+	/* used by Cortex-A Core remoteproc to manage all CPU Cores */
+	cpumask_t			cpus;
+	cpumask_t			offlined_cpus;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx95_m7[] = {
@@ -381,6 +392,45 @@ static int imx_rproc_sm_lmm_start(struct rproc *rproc)
 	return 0;
 }
 
+static int imx_rproc_psci_start(struct rproc *rproc)
+{
+	struct imx_rproc *priv = rproc->priv;
+	struct device *dev = priv->dev;
+	unsigned int cpu;
+	int ret;
+
+	if (cpumask_empty(&priv->cpus)) {
+		dev_err(dev, "No CPU Core assigned!\n");
+		return -ENODEV;
+	}
+
+	for_each_cpu(cpu, &priv->cpus) {
+		if (cpu_online(cpu)) {
+			ret = remove_cpu(cpu);
+			if (ret)
+				goto err;
+			cpumask_set_cpu(cpu, &priv->offlined_cpus);
+		}
+	}
+
+	cpu = cpumask_first(&priv->cpus);
+	ret = psci_ops.cpu_on(cpu_logical_map(cpu), rproc->bootaddr);
+	if (ret) {
+		dev_err(dev, "Boot failed on CPU Core %d\n", cpu);
+		goto err;
+	}
+
+	return 0;
+
+err:
+	for_each_cpu(cpu, &priv->cpus) {
+		if (!cpu_online(cpu) && add_cpu(cpu) == 0)
+			cpumask_clear_cpu(cpu, &priv->offlined_cpus);
+	}
+
+	return ret;
+}
+
 static int imx_rproc_start(struct rproc *rproc)
 {
 	struct imx_rproc *priv = rproc->priv;
@@ -456,6 +506,50 @@ static int imx_rproc_sm_lmm_stop(struct rproc *rproc)
 	return scmi_imx_lmm_operation(dcfg->lmid, SCMI_IMX_LMM_SHUTDOWN, 0);
 }
 
+static int imx_rproc_psci_stop(struct rproc *rproc)
+{
+	struct imx_rproc *priv = rproc->priv;
+	struct device *dev = priv->dev;
+	struct arm_smccc_res res;
+	unsigned int cpu;
+	unsigned long start, end;
+	int err;
+
+	for_each_cpu(cpu, &priv->cpus) {
+		/* Check CPU status */
+		err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
+		if (err == PSCI_0_2_AFFINITY_LEVEL_OFF)
+			continue;
+
+		/* Bring CPU to be off */
+		arm_smccc_smc(IMX_SIP_CPU_OFF, cpu, 0,
+			0, 0, 0, 0, 0, &res);
+		start = jiffies;
+		end = start + msecs_to_jiffies(100);
+		do {
+			err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
+			if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
+				pr_info("CPU%d is killed (polled %d ms)\n", cpu,
+					jiffies_to_msecs(jiffies - start));
+				break;
+			}
+
+			usleep_range(100, 1000);
+		} while (time_before(jiffies, end));
+	}
+
+	/* Return back freed CPU Core to Linux kernel */
+	for_each_cpu(cpu, &priv->cpus) {
+		if (cpumask_test_cpu(cpu, &priv->offlined_cpus)) {
+			if (add_cpu(cpu) != 0)
+				dev_err(dev, "Failed to bring CPU %d back to be online", cpu);
+			cpumask_clear_cpu(cpu, &priv->offlined_cpus);
+		}
+	}
+
+	return 0;
+}
+
 static int imx_rproc_stop(struct rproc *rproc)
 {
 	struct imx_rproc *priv = rproc->priv;
@@ -480,6 +574,12 @@ static int imx_rproc_da_to_sys(struct imx_rproc *priv, u64 da,
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	int i;
 
+	/* No need to translate for Cortex-A Core */
+	if (dcfg->flags & IMX_RPROC_NO_ADDR_TRANS) {
+		*sys = da;
+		return 0;
+	}
+
 	/* parse address translation table */
 	for (i = 0; i < dcfg->att_size; i++) {
 		const struct imx_rproc_att *att = &dcfg->att[i];
@@ -1184,6 +1284,13 @@ static int imx_rproc_sm_detect_mode(struct rproc *rproc)
 	return imx_rproc_sm_lmm_check(rproc, started);
 }
 
+static int imx_rproc_psci_detect_mode(struct rproc *rproc)
+{
+	rproc->state = RPROC_OFFLINE;
+
+	return 0;
+}
+
 static int imx_rproc_detect_mode(struct imx_rproc *priv)
 {
 	/*
@@ -1228,6 +1335,8 @@ static int imx_rproc_probe(struct platform_device *pdev)
 	struct imx_rproc *priv;
 	struct rproc *rproc;
 	const struct imx_rproc_dcfg *dcfg;
+	unsigned int cpus;
+	unsigned long cpus_bits;
 	int ret;
 
 	/* set some other name then imx */
@@ -1274,6 +1383,17 @@ static int imx_rproc_probe(struct platform_device *pdev)
 	if (ret)
 		return dev_err_probe(dev, ret, "failed on imx_rproc_addr_init\n");
 
+	ret = of_property_read_u32(dev->of_node, "fsl,cpus-bits", &cpus);
+	if (ret) {
+		cpumask_clear(&priv->cpus);
+	} else {
+		cpus_bits = cpus;
+		bitmap_copy(cpumask_bits(&priv->cpus), &cpus_bits,
+				min((unsigned int)nr_cpumask_bits,
+				    (unsigned int)sizeof(unsigned long)));
+		rproc->auto_boot = false;
+	}
+
 	ret = imx_rproc_detect_mode(priv);
 	if (ret)
 		return dev_err_probe(dev, ret, "failed on detect mode\n");
@@ -1372,6 +1492,12 @@ static const struct imx_rproc_plat_ops imx_rproc_ops_sm_cpu = {
 	.stop		= imx_rproc_sm_cpu_stop,
 };
 
+static const struct imx_rproc_plat_ops imx_rproc_ops_psci = {
+	.start		= imx_rproc_psci_start,
+	.stop		= imx_rproc_psci_stop,
+	.detect_mode	= imx_rproc_psci_detect_mode,
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mn_mmio = {
 	.src_reg	= IMX7D_SRC_SCR,
 	.src_mask	= IMX7D_M4_RST_MASK,
@@ -1464,6 +1590,13 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
 	.lmid		= 1, /* Use 1 as Logical Machine ID where M7 resides */
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_psci = {
+	.att		= NULL,
+	.att_size	= 0,
+	.ops		= &imx_rproc_ops_psci,
+	.flags		= IMX_RPROC_NO_ADDR_TRANS,
+};
+
 static const struct of_device_id imx_rproc_of_match[] = {
 	{ .compatible = "fsl,imx7ulp-cm4", .data = &imx_rproc_cfg_imx7ulp },
 	{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
@@ -1479,6 +1612,7 @@ static const struct of_device_id imx_rproc_of_match[] = {
 	{ .compatible = "fsl,imx8ulp-cm33", .data = &imx_rproc_cfg_imx8ulp },
 	{ .compatible = "fsl,imx93-cm33", .data = &imx_rproc_cfg_imx93 },
 	{ .compatible = "fsl,imx95-cm7", .data = &imx_rproc_cfg_imx95_m7 },
+	{ .compatible = "fsl,imx-rproc-psci", .data = &imx_rproc_cfg_psci },
 	{},
 };
 MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
index d37e6f90548c..be6709971042 100644
--- a/drivers/remoteproc/imx_rproc.h
+++ b/drivers/remoteproc/imx_rproc.h
@@ -18,6 +18,8 @@ struct imx_rproc_att {
 /* dcfg flags */
 #define IMX_RPROC_NEED_SYSTEM_OFF	BIT(0)
 #define IMX_RPROC_NEED_CLKS		BIT(1)
+/* No need address translation */
+#define IMX_RPROC_NO_ADDR_TRANS		BIT(2)
 
 struct imx_rproc_plat_ops {
 	int (*start)(struct rproc *rproc);
-- 
2.43.0

[PATCH v3 3/4] remoteproc: imx_rproc: add autoboot support for A-core

[Jiafei Pan]

From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>

Add autoboot support for Cortex-A Core remoteproc.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
---

Changes in v3:
- Added my signed-of-by.

---
 drivers/remoteproc/imx_rproc.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 8a3de27c96b7..e8d239bef5c9 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -1286,7 +1286,24 @@ static int imx_rproc_sm_detect_mode(struct rproc *rproc)
 
 static int imx_rproc_psci_detect_mode(struct rproc *rproc)
 {
-	rproc->state = RPROC_OFFLINE;
+	struct imx_rproc *priv = rproc->priv;
+	unsigned int cpu;
+	int cpu_aff;
+
+	rproc->state = RPROC_DETACHED;
+	for_each_cpu(cpu, &priv->cpus) {
+		cpu_aff = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
+		if (cpu_aff == PSCI_0_2_AFFINITY_LEVEL_OFF) {
+			rproc->state = RPROC_OFFLINE;
+			break;
+		}
+
+		/* in psci on state but running Linux */
+		if (cpu_online(cpu)) {
+			rproc->state = RPROC_OFFLINE;
+			break;
+		}
+	}
 
 	return 0;
 }
@@ -1391,7 +1408,6 @@ static int imx_rproc_probe(struct platform_device *pdev)
 		bitmap_copy(cpumask_bits(&priv->cpus), &cpus_bits,
 				min((unsigned int)nr_cpumask_bits,
 				    (unsigned int)sizeof(unsigned long)));
-		rproc->auto_boot = false;
 	}
 
 	ret = imx_rproc_detect_mode(priv);
-- 
2.43.0

[PATCH v3 4/4] arm64: dts: imx93: Cortex-A Core remoteproc device node

[Jiafei Pan]

Create device tree for i.MX93 14x14 evk and 11x11 evk, add Cortex-A Core
remoteproc device nodes in these device tree.

Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
---
 arch/arm64/boot/dts/freescale/Makefile        |  2 +
 .../imx93-11x11-evk-multicore-rtos.dts        | 39 +++++++++++++++++++
 .../imx93-14x14-evk-multicore-rtos.dts        | 39 +++++++++++++++++++
 .../boot/dts/freescale/imx93-rproc-ca55.dtsi  | 14 +++++++
 4 files changed, 94 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-14x14-evk-multicore-rtos.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c99..f067e5c44dae 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -460,12 +460,14 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-i3c.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtb
 
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk-multicore-rtos.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm.dtb
 
 imx93-11x11-frdm-pixpaper-dtbs += imx93-11x11-frdm.dtb imx93-11x11-frdm-pixpaper.dtbo
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm-pixpaper.dtb
 
 dtb-$(CONFIG_ARCH_MXC) += imx93-14x14-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-14x14-evk-multicore-rtos.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-kontron-bl-osm-s.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts
new file mode 100644
index 000000000000..9fb2b94b83b4
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2023-2026 NXP
+ */
+
+/dts-v1/;
+#include "imx93-11x11-evk.dts"
+#include "imx93-rproc-ca55.dtsi"
+
+/ {
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/*
+		 * Reserve up to 16MB for one possible RTOS instances running on
+		 * one Cortex-A Cores when booting Linux on at least one Cortex-A Core.
+		 */
+		rtos_ca55_reserved: rtos-ca55@d0000000 {
+			no-map;
+			reg = <0 0xd0000000 0x0 0x1000000>;
+		};
+
+		/* Reserve 16MB for FreeRTOS on M33 */
+		m33_reserved: m33@a5000000 {
+			no-map;
+			reg = <0 0xa5000000 0 0x1000000>;
+		};
+	};
+};
+
+&lpuart2 {
+	status = "disabled";
+};
+
+&clk {
+	init-on-array = <IMX93_CLK_LPUART2_GATE>;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-14x14-evk-multicore-rtos.dts b/arch/arm64/boot/dts/freescale/imx93-14x14-evk-multicore-rtos.dts
new file mode 100644
index 000000000000..b2481bf19b4a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-14x14-evk-multicore-rtos.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2024-2026 NXP
+ */
+
+/dts-v1/;
+#include "imx93-14x14-evk.dts"
+#include "imx93-rproc-ca55.dtsi"
+
+/ {
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/*
+		 * Reserve up to 16MB for one possible RTOS instances running on
+		 * one Cortex-A Cores when booting Linux on at least one Cortex-A Core.
+		 */
+		rtos_ca55_reserved: rtos-ca55@d0000000 {
+			no-map;
+			reg = <0 0xd0000000 0x0 0x1000000>;
+		};
+
+		/* Reserve 16MB for FreeRTOS on M33 */
+		m33_reserved: m33@a5000000 {
+			no-map;
+			reg = <0 0xa5000000 0 0x1000000>;
+		};
+	};
+};
+
+&lpuart2 {
+	status = "disabled";
+};
+
+&clk {
+	init-on-array = <IMX93_CLK_LPUART2_GATE>;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi b/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
new file mode 100644
index 000000000000..549a9e762d6a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2024-2026 NXP
+ */
+
+/ {
+	ca55_1: remoteproc-ca55-1 {
+		compatible = "fsl,imx-rproc-psci";
+		/* bitmask:0b10, assign A55 Core 1 */
+		fsl,cpus-mask = <0x2>;
+		memory-region = <&rtos_ca55_reserved>;
+	};
+};
+
-- 
2.43.0

Re: [PATCH v3 0/4] remoteproc: add Cortex-A Core remoteproc support on i.MX platforms

[Peng Fan]

Hi Jiafei,

On Mon, May 11, 2026 at 10:39:24AM +0800, Jiafei Pan wrote:
>This patch series is to add remoteproc support on Cortex-A Core of i.MX platforms:
>1. Adding dts binding for Cortex-A Core remoteproc
>2. Enable Cortex-A Core remoteproc support in remoteproc driver
>3. Adding dts example on imx93 platforms.

Normally, we only keep one patch or patch series from the same author that
modifies the same file in the review queue at a time.

You already have a patch for imx_rproc.c currently under review(got R-b, but
need Mathieu to handle), so this patch series might be delayed to be reviewed.

As I have replied in internal, to make multiple OS run on Cortex-A SMP without
hypervsior, some GIC changes are required, without those GIC changes,
this patchset is not testable using upstream tree.

Thanks,
Peng

>
>Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
>
>---
>Changes in v3:
>- Fixed dt_binding_check warnings
>- Updated prefix of patch subject
>
>Changes in v2:
>- Update arch/arm64/boot/dts/freescale/Makefile to add new dts
>
>---
>Hou Zhiqiang (1):
>  remoteproc: imx_rproc: add autoboot support for A-core
>
>Jiafei Pan (3):
>  dt-bindings: remoteproc: add imx-rproc-psci
>  remoteproc: imx_rproc: add support for Cortex-A Core
>  arm64: dts: imx93: Cortex-A Core remoteproc device node
>
> .../remoteproc/fsl,imx-rproc-psci.yaml        |  51 ++++++
> arch/arm64/boot/dts/freescale/Makefile        |   2 +
> .../imx93-11x11-evk-multicore-rtos.dts        |  39 +++++
> .../imx93-14x14-evk-multicore-rtos.dts        |  39 +++++
> .../boot/dts/freescale/imx93-rproc-ca55.dtsi  |  14 ++
> drivers/remoteproc/imx_rproc.c                | 150 ++++++++++++++++++
> drivers/remoteproc/imx_rproc.h                |   2 +
> 7 files changed, 297 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
> create mode 100644 arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts
> create mode 100644 arch/arm64/boot/dts/freescale/imx93-14x14-evk-multicore-rtos.dts
> create mode 100644 arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
>
>-- 
>2.43.0
>

Re: [PATCH v3 0/4] remoteproc: add Cortex-A Core remoteproc support on i.MX platforms

[Mathieu Poirier]

On Mon, May 11, 2026 at 03:00:25PM +0800, Peng Fan wrote:
> Hi Jiafei,
> 
> On Mon, May 11, 2026 at 10:39:24AM +0800, Jiafei Pan wrote:
> >This patch series is to add remoteproc support on Cortex-A Core of i.MX platforms:
> >1. Adding dts binding for Cortex-A Core remoteproc
> >2. Enable Cortex-A Core remoteproc support in remoteproc driver
> >3. Adding dts example on imx93 platforms.
> 
> Normally, we only keep one patch or patch series from the same author that
> modifies the same file in the review queue at a time.
> 
> You already have a patch for imx_rproc.c currently under review(got R-b, but
> need Mathieu to handle), so this patch series might be delayed to be reviewed.
> 
> As I have replied in internal, to make multiple OS run on Cortex-A SMP without
> hypervsior, some GIC changes are required, without those GIC changes,
> this patchset is not testable using upstream tree.
>

If that is the case, please re-submit when the proper background work on GIC has
been merged.

Mathieu
 
> Thanks,
> Peng
> 
> >
> >Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
> >
> >---
> >Changes in v3:
> >- Fixed dt_binding_check warnings
> >- Updated prefix of patch subject
> >
> >Changes in v2:
> >- Update arch/arm64/boot/dts/freescale/Makefile to add new dts
> >
> >---
> >Hou Zhiqiang (1):
> >  remoteproc: imx_rproc: add autoboot support for A-core
> >
> >Jiafei Pan (3):
> >  dt-bindings: remoteproc: add imx-rproc-psci
> >  remoteproc: imx_rproc: add support for Cortex-A Core
> >  arm64: dts: imx93: Cortex-A Core remoteproc device node
> >
> > .../remoteproc/fsl,imx-rproc-psci.yaml        |  51 ++++++
> > arch/arm64/boot/dts/freescale/Makefile        |   2 +
> > .../imx93-11x11-evk-multicore-rtos.dts        |  39 +++++
> > .../imx93-14x14-evk-multicore-rtos.dts        |  39 +++++
> > .../boot/dts/freescale/imx93-rproc-ca55.dtsi  |  14 ++
> > drivers/remoteproc/imx_rproc.c                | 150 ++++++++++++++++++
> > drivers/remoteproc/imx_rproc.h                |   2 +
> > 7 files changed, 297 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
> > create mode 100644 arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts
> > create mode 100644 arch/arm64/boot/dts/freescale/imx93-14x14-evk-multicore-rtos.dts
> > create mode 100644 arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
> >
> >-- 
> >2.43.0
> >

Re: [PATCH v3 1/4] dt-bindings: remoteproc: add imx-rproc-psci

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Using an integer bitmask (`fsl,cpus-mask`) to reference CPU cores is a devicetree anti-pattern that breaks PSCI MPIDR resolution.
- [Low] The device tree example uses a non-generic node name `remoteproc-ca55-1`.
--

commit 8d7c3b674f34ab921c2ce0607326cdb7b149d310
Author: Jiafei Pan <Jiafei.Pan@nxp.com>

dt-bindings: remoteproc: add imx-rproc-psci

This commit introduces a new devicetree binding "fsl,imx-rproc-psci" for
managing Cortex-A cores as remote processors on i.MX platforms. It uses
PSCI for CPU power management, enabling the cores to run RTOS or bare-metal
applications.

> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
> new file mode 100644
> index 0000000000000..28d00dbf8bc7e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
[ ... ]
> +properties:
> +  compatible:
> +    const: fsl,imx-rproc-psci
> +
> +  fsl,cpus-mask:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      Bitmask indicating which CPU cores are assigned to this remote
> +      processor instance. Each bit represents a CPU core, where bit N
> +      corresponds to CPU N. For example, 0x2 (0b10) assigns CPU core 1,
> +      while 0x6 (0b110) assigns CPU cores 1 and 2.

Should this use a phandle array instead of a logical bitmask? In Devicetree,
relationships between hardware blocks are typically modeled using phandles.

Using a bitmask implies OS-specific logical CPU indexing that may not reflect
hardware topology reliably. If a CPU is intended to run an RTOS, it is
frequently excluded from Linux via status = "disabled" or isolated at boot.
This means Linux might not assign it a stable logical ID.

Could this break PSCI MPIDR resolution if the driver attempts to map the
logical ID to a physical MPIDR, but the CPU was isolated and unmapped?

A standard cpus array of phandles (e.g., cpus = <&cpu1>;) would allow the
driver to parse the CPU node's reg property directly for the correct MPIDR.

[ ... ]
> +examples:
> +  - |
> +        remoteproc-ca55-1 {

This isn't a bug, but should the node name be generic?

The Devicetree specification recommends node names reflect the primary
function of the device rather than the specific architecture. A standard
generic name like remoteproc (or remoteproc-1 if multiple siblings lack reg
properties) might be more appropriate than remoteproc-ca55-1.

> +            compatible = "fsl,imx-rproc-psci";
> +            /* bitmask: 0b10, assign A55 Core 1 */
> +            fsl,cpus-mask = <0x2>;
> +            memory-region = <&rtos_ca55_reserved>;
> +        };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511023928.39640-1-Jiafei.Pan@nxp.com?part=1

Re: [PATCH v3 2/4] remoteproc: imx_rproc: add support for Cortex-A Core

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [Critical] The CPU power-off polling loop in imx_rproc_psci_stop() silently ignores timeouts, leading to a critical Use-After-Free.
- [High] The error recovery path in imx_rproc_psci_start() improperly onlines CPUs that were administratively offline.
- [High] The IMX_SIP_CPU_OFF SMC call is passed a Linux logical CPU ID instead of the hardware MPIDR.
- [Medium] The driver references internal kernel symbols (psci_ops and cpu_logical_map) that are not exported, causing module build breakage.
- [Low] bitmap_copy is erroneously called with a byte count instead of a bit count, logically truncating the CPU mask.
--

commit 6acc0c2627860bf5f4e779a8968c861a2f039bd5
Author: Jiafei Pan <Jiafei.Pan@nxp.com>

remoteproc: imx_rproc: add support for Cortex-A Core

This commit adds Cortex-A remoteproc support. It uses PSCI and SIP SMC calls
to manage turning the Cortex-A cores on and off.

> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 0dd80e688b0ea..8a3de27c96b78 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
[ ... ]
> @@ -381,6 +392,45 @@ static int imx_rproc_sm_lmm_start(struct rproc *rproc)
>  	return 0;
>  }
>  
> +static int imx_rproc_psci_start(struct rproc *rproc)
> +{
[ ... ]
> +	cpu = cpumask_first(&priv->cpus);
> +	ret = psci_ops.cpu_on(cpu_logical_map(cpu), rproc->bootaddr);

Are the psci_ops and cpu_logical_map symbols exported for loadable modules?
If this driver is compiled as a module, will it cause linker errors due to
undefined symbols?

[ ... ]
> +err:
> +	for_each_cpu(cpu, &priv->cpus) {
> +		if (!cpu_online(cpu) && add_cpu(cpu) == 0)
> +			cpumask_clear_cpu(cpu, &priv->offlined_cpus);
> +	}
> +
> +	return ret;
> +}

Could this rollback path inadvertently bring up CPUs that were
administratively offline before the driver started?

In the stop path, it checks cpumask_test_cpu(cpu, &priv->offlined_cpus) to
verify ownership. Should this rollback path use the same check to avoid
overriding system power policies?

[ ... ]
> @@ -456,6 +506,50 @@ static int imx_rproc_sm_lmm_stop(struct rproc *rproc)
>  	return scmi_imx_lmm_operation(dcfg->lmid, SCMI_IMX_LMM_SHUTDOWN, 0);
>  }
>  
> +static int imx_rproc_psci_stop(struct rproc *rproc)
> +{
[ ... ]
> +	for_each_cpu(cpu, &priv->cpus) {
> +		/* Check CPU status */
> +		err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
> +		if (err == PSCI_0_2_AFFINITY_LEVEL_OFF)
> +			continue;
> +
> +		/* Bring CPU to be off */
> +		arm_smccc_smc(IMX_SIP_CPU_OFF, cpu, 0,
> +			0, 0, 0, 0, 0, &res);

Does the firmware expect a logical CPU index or a hardware MPIDR here?

The adjacent psci_ops.affinity_info() call uses cpu_logical_map(cpu) to
translate it. Would passing the logical index directly cause the firmware to
shut down the wrong physical core?

> +		start = jiffies;
> +		end = start + msecs_to_jiffies(100);
> +		do {
> +			err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
> +			if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
> +				pr_info("CPU%d is killed (polled %d ms)\n", cpu,
> +					jiffies_to_msecs(jiffies - start));
> +				break;
> +			}
> +
> +			usleep_range(100, 1000);
> +		} while (time_before(jiffies, end));
> +	}
> +
> +	/* Return back freed CPU Core to Linux kernel */
> +	for_each_cpu(cpu, &priv->cpus) {
[ ... ]
> +	}
> +
> +	return 0;
> +}

If the polling loop times out after 100ms without reaching
PSCI_0_2_AFFINITY_LEVEL_OFF, does this function still return 0?

If it returns success while the remote core is still executing, will the
remoteproc core proceed to unmap the IOMMU and free the carveouts, leading to
a use-after-free when the still-running core accesses that memory?

Should it return an error like -ETIMEDOUT instead?

[ ... ]
> @@ -1274,6 +1383,17 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  	if (ret)
>  		return dev_err_probe(dev, ret, "failed on imx_rproc_addr_init\n");
>  
> +	ret = of_property_read_u32(dev->of_node, "fsl,cpus-bits", &cpus);
> +	if (ret) {
> +		cpumask_clear(&priv->cpus);
> +	} else {
> +		cpus_bits = cpus;
> +		bitmap_copy(cpumask_bits(&priv->cpus), &cpus_bits,
> +				min((unsigned int)nr_cpumask_bits,
> +				    (unsigned int)sizeof(unsigned long)));

Is the third argument to bitmap_copy intended to be a bit count rather than
a byte count?

Passing sizeof(unsigned long) requests a copy of only 4 or 8 bits. Should
this use BITS_PER_LONG to prevent logical truncation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511023928.39640-1-Jiafei.Pan@nxp.com?part=2

Re: [PATCH v3 3/4] remoteproc: imx_rproc: add autoboot support for A-core

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] Unexported kernel symbols `psci_ops` and `cpu_logical_map()` are referenced, causing link errors when compiled as a module.
- [High] Unconditional invocation of `psci_ops.affinity_info` can lead to a NULL pointer dereference.
- [High] Negative error codes and pending states from `psci_ops.affinity_info()` are incorrectly treated as 'ON' state.
- [High] State detection logic is flawed for multi-core configurations, potentially booting an already running core.
- [High] Empty CPU mask logic error leads to incorrect auto-attaching to non-existent cores.
--

commit af57d4202637d4c4549d5d1bd6d7af8d8a4bbb7e
Author: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>

remoteproc: imx_rproc: add autoboot support for A-core

This commit adds autoboot support for Cortex-A Core remoteproc by
implementing PSCI state detection to manage CPU cores. It evaluates CPU
affinity and online status to set the remoteproc state accordingly.

> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 8a3de27c96b78..e8d239bef5c95 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -1286,7 +1286,24 @@ static int imx_rproc_sm_detect_mode(struct rproc *rproc)
>  
>  static int imx_rproc_psci_detect_mode(struct rproc *rproc)
>  {
> -	rproc->state = RPROC_OFFLINE;
> +	struct imx_rproc *priv = rproc->priv;
> +	unsigned int cpu;
> +	int cpu_aff;
> +
> +	rproc->state = RPROC_DETACHED;
> +	for_each_cpu(cpu, &priv->cpus) {
> +		cpu_aff = psci_ops.affinity_info(cpu_logical_map(cpu), 0);

Because CONFIG_IMX_REMOTEPROC can be built as a module, will referencing
psci_ops and cpu_logical_map() cause undefined reference errors during
modpost? Neither symbol appears to be exported to loadable modules.

Can psci_ops.affinity_info be NULL if the system runs an older PSCI version
like v0.1? Should we verify if psci_ops.affinity_info is populated before
dereferencing it to avoid a panic?

> +		if (cpu_aff == PSCI_0_2_AFFINITY_LEVEL_OFF) {

The affinity_info callback can return negative values for errors, such as
PSCI_RET_NOT_SUPPORTED, or 2 for PENDING. Does this logic safely handle
those cases, or will it bypass this check and inadvertently leave the state
as RPROC_DETACHED if the CPU is not online in Linux?

> +			rproc->state = RPROC_OFFLINE;
> +			break;
> +		}
> +
> +		/* in psci on state but running Linux */
> +		if (cpu_online(cpu)) {
> +			rproc->state = RPROC_OFFLINE;
> +			break;
> +		}

If there is a multi-core cluster where CPU 0 is ON and running the remote
OS, but CPU 1 is OFF, this loop will evaluate CPU 1, set the state to
RPROC_OFFLINE, and break. Will this cause the remoteproc framework to
incorrectly attempt to boot the primary core while it is already actively
running?

> +	}
>  
>  	return 0;
>  }

[ ... ]

> @@ -1391,7 +1408,6 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  		bitmap_copy(cpumask_bits(&priv->cpus), &cpus_bits,
>  				min((unsigned int)nr_cpumask_bits,
>  				    (unsigned int)sizeof(unsigned long)));
> -		rproc->auto_boot = false;
>  	}

If the device tree property fsl,cpus-bits is missing because the bindings
specify fsl,cpus-mask instead, the cpus mask will be cleared. With an empty
mask, the detection loop is bypassed, leaving the state as RPROC_DETACHED.
Will removing rproc->auto_boot = false here cause the framework to attempt
an attach on a remoteproc instance with no assigned CPUs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511023928.39640-1-Jiafei.Pan@nxp.com?part=3

Re: [PATCH v3 4/4] arm64: dts: imx93: Cortex-A Core remoteproc device node

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Use of undocumented and unsupported property `init-on-array` in the clock controller node.
- [Medium] Encoding software-specific use-cases into top-level static .dts files.
- [Medium] The `m33_reserved` memory is declared but not linked to any remoteproc node.
- [Low] Grammatical errors in the inline device tree comments.
--

commit 63c01069d7a6eb875616e06076ef323b131b3915
Author: Jiafei Pan <Jiafei.Pan@nxp.com>

arm64: dts: imx93: Cortex-A Core remoteproc device node

This commit creates new top-level device tree files for the i.MX93
14x14 and 11x11 EVKs to support a multicore RTOS configuration, adding
Cortex-A Core remoteproc device nodes.

> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 711e36cc2c990..f067e5c44daef 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
[ ... ]
>  dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk-multicore-rtos.dtb

Device trees are generally intended to describe the physical hardware
of a board rather than specific software deployment policies. Does
adding dedicated top-level device tree files for an RTOS use-case
risk a combinatoric explosion of files whenever the base hardware
changes?

Could these software-specific configurations be implemented as Device
Tree Overlays (.dtbo) or applied dynamically via bootloader fixups
instead?

[ ... ]
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts
> new file mode 100644
> index 0000000000000..9fb2b94b83b4f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts
[ ... ]
> +		/*
> +		 * Reserve up to 16MB for one possible RTOS instances running on
> +		 * one Cortex-A Cores when booting Linux on at least one Cortex-A Core.
> +		 */

This isn't a bug, but "instances" and "Cores" should probably be
singular ("RTOS instance" and "Cortex-A Core").

> +		rtos_ca55_reserved: rtos-ca55@d0000000 {
> +			no-map;
> +			reg = <0 0xd0000000 0x0 0x1000000>;
> +		};
> +
> +		/* Reserve 16MB for FreeRTOS on M33 */
> +		m33_reserved: m33@a5000000 {
> +			no-map;
> +			reg = <0 0xa5000000 0 0x1000000>;
> +		};

Is this memory-region intentionally left unlinked to any remoteproc
node?

Since it is not assigned to the cm33 node and is marked with no-map,
it will not be mapped by Linux. If the imx_rproc driver attempts to
parse an M33 firmware ELF and load segments into this memory, won't
it fail to validate or translate the physical address?

> +	};
> +};
> +
> +&lpuart2 {
> +	status = "disabled";
> +};
> +
> +&clk {
> +	init-on-array = <IMX93_CLK_LPUART2_GATE>;
> +};

Is init-on-array supported by the upstream Common Clock Framework?

This property appears to be absent from upstream dt-bindings and is
not parsed by mainline clock drivers. Because the framework will
silently ignore it, won't the late clk_disable_unused initcall
disable the LPUART2 clock, given the lpuart2 device is marked
disabled?

If the RTOS running on the remoteproc attempts to access the gated
UART, will it cause a bus fault and crash the remote processor?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511023928.39640-1-Jiafei.Pan@nxp.com?part=4