[PATCH 0/4] Introduce K3 remoteproc driver for M4 subsystem

[PATCH 0/4] Introduce K3 remoteproc driver for M4 subsystem

[Judith Mendez]

Some K3 devices like am62x and am64x have a M4 processor in the MCU
voltage domain. This patch series introduces remoteproc M4 driver which
will be used to load firmware into and start the M4 remote core.

This series also adds support for R5F cores on am64x SoCs in patch 2/4,
sets up environment to load FW in remote cores in patch 3/4, and enables
config options for R5F and M4 remoteproc support in patch 4/4.

This patch series was tested on am64x EVM using commands:

=> setenv dorprocboot 1
=> run boot_rprocs

Hari Nagalla (4):
  remoteproc: k3-m4: Introduce K3 remote proc driver for M4 subsystem
  remoteproc: k3-r5: Add support for R5F cores on AM64x SoCs
  env: ti: am64x: set rproc_fw_binaries
  configs: am64x_evm_a53_defconfig: Enable R5F and M4 remote proc
    support

 board/ti/am64x/am64x.env             |   6 +
 configs/am64x_evm_a53_defconfig      |   2 +
 drivers/remoteproc/Kconfig           |  10 +
 drivers/remoteproc/Makefile          |   1 +
 drivers/remoteproc/ti_k3_m4_rproc.c  | 411 +++++++++++++++++++++++++++
 drivers/remoteproc/ti_k3_r5f_rproc.c |   2 +
 6 files changed, 432 insertions(+)
 create mode 100644 drivers/remoteproc/ti_k3_m4_rproc.c

-- 
2.48.0

[PATCH 1/4] remoteproc: k3-m4: Introduce K3 remote proc driver for M4 subsystem

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

Some K3 devices like AM64, AM62 devices have a M4 processor in MCU
voltage domain.

Add a remote proc driver to support this subsystem to be able to load
and boot the M4 core.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
[Judith: Fixed comments explaining local resets]
Signed-off-by: Judith Mendez <jm@ti.com>
---
 drivers/remoteproc/Kconfig          |  10 +
 drivers/remoteproc/Makefile         |   1 +
 drivers/remoteproc/ti_k3_m4_rproc.c | 411 ++++++++++++++++++++++++++++
 3 files changed, 422 insertions(+)
 create mode 100644 drivers/remoteproc/ti_k3_m4_rproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 2790b168b19..e579c4e8371 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -80,6 +80,16 @@ config REMOTEPROC_TI_K3_R5F
 	  on various TI K3 family of SoCs through the remote processor
 	  framework.
 
+config REMOTEPROC_TI_K3_M4F
+	bool "TI K3 M4F remoteproc support"
+	select REMOTEPROC
+	depends on ARCH_K3
+	depends on TI_SCI_PROTOCOL
+	help
+	  Say y here to support TI's M4F remote processor subsystems
+	  on various TI K3 family of SoCs through the remote processor
+	  framework.
+
 config REMOTEPROC_TI_POWER
 	bool "Support for TI Power processor"
 	select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 3a092b7660e..f81e5009c5e 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
 obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
+obj-$(CONFIG_REMOTEPROC_TI_K3_M4F) += ti_k3_m4_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
 obj-$(CONFIG_REMOTEPROC_TI_PRU) += pru_rproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_rproc.c b/drivers/remoteproc/ti_k3_m4_rproc.c
new file mode 100644
index 00000000000..5a5ae2fa81d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_rproc.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments' K3 M4 Remoteproc driver
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - http://www.ti.com/
+ *	Hari Nagalla <hnagalla@ti.com>
+ */
+
+#include <dm.h>
+#include <log.h>
+#include <malloc.h>
+#include <remoteproc.h>
+#include <errno.h>
+#include <clk.h>
+#include <reset.h>
+#include <asm/io.h>
+#include <power-domain.h>
+#include <dm/device_compat.h>
+#include <linux/err.h>
+#include <linux/sizes.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address from remoteproc view
+ * @size: Size of the memory region
+ */
+struct k3_m4_mem {
+	void __iomem *cpu_addr;
+	phys_addr_t bus_addr;
+	phys_addr_t dev_addr;
+	size_t size;
+};
+
+/**
+ * struct k3_m4_mem_data - memory definitions for m4 remote core
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_mem_data {
+	const char *name;
+	const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_boot_data - internal data structure used for boot
+ * @boot_align_addr: Boot vector address alignment granularity
+ * @uses_lreset: Flag to denote the need for local reset management
+ */
+struct k3_m4_boot_data {
+	u32 boot_align_addr;
+	bool uses_lreset;
+};
+
+/**
+ * struct k3_m4_privdata - Structure representing Remote processor data.
+ * @m4_rst:		m4 rproc reset control data
+ * @tsp:		Pointer to TISCI proc contrl handle
+ * @data:		Pointer to DSP specific boot data structure
+ * @mem:		Array of available memories
+ * @num_mem:		Number of available memories
+ */
+struct k3_m4_privdata {
+	struct reset_ctl m4_rst;
+	struct ti_sci_proc tsp;
+	struct k3_m4_boot_data *data;
+	struct k3_m4_mem *mem;
+	int num_mems;
+};
+
+/*
+ * The M4 cores have a local reset that affects only the CPU, and a
+ * generic module reset that powers on the device and allows the M4 internal
+ * memories to be accessed while the local reset is asserted. This function is
+ * used to release the global reset on M4F to allow loading into the M4F
+ * internal RAMs. This helper function is invoked in k3_m4_load() before any
+ * actual firmware loading and is undone only in k3_m4_stop(). The local reset
+ * cannot be released on M4 cores until after the firmware images are loaded.
+ */
+static int k3_m4_prepare(struct udevice *dev)
+{
+	struct k3_m4_privdata *m4 = dev_get_priv(dev);
+	struct k3_m4_boot_data *data = m4->data;
+	int ret;
+
+	if (!data->uses_lreset)
+		return 0;
+
+	ret = ti_sci_proc_power_domain_on(&m4->tsp);
+	if (ret)
+		dev_err(dev, "cannot enable internal RAM loading, ret = %d\n",
+			ret);
+
+	return ret;
+}
+
+/*
+ * This function is the counterpart to k3_m4_prepare() and is used to assert
+ * the global reset on M4 cores. This completes the second step of powering
+ * down the M4 cores. The cores themselves are halted through the local reset
+ * in first step. This function is invoked in k3_m4_stop() after the local
+ * reset is asserted.
+ */
+static int k3_m4_unprepare(struct udevice *dev)
+{
+	struct k3_m4_privdata *m4 = dev_get_priv(dev);
+	struct k3_m4_boot_data *data = m4->data;
+
+	if (!data->uses_lreset)
+		return 0;
+
+	return ti_sci_proc_power_domain_off(&m4->tsp);
+}
+
+/**
+ * k3_m4_load() - Load up the Remote processor image
+ * @dev:	rproc device pointer
+ * @addr:	Address at which image is available
+ * @size:	size of the image
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_m4_load(struct udevice *dev, ulong addr, ulong size)
+{
+	struct k3_m4_privdata *m4 = dev_get_priv(dev);
+	void *image_addr = (void *)addr;
+	int ret;
+
+	ret = ti_sci_proc_request(&m4->tsp);
+	if (ret)
+		return ret;
+
+	ret = k3_m4_prepare(dev);
+	if (ret) {
+		dev_err(dev, "Prepare failed for core %d\n",
+			m4->tsp.proc_id);
+		goto proc_release;
+	}
+
+	ti_secure_image_post_process(&image_addr, &size);
+
+	ret = rproc_elf_load_image(dev, addr, size);
+	if (ret < 0) {
+		dev_err(dev, "Loading elf failed %d\n", ret);
+		goto unprepare;
+	}
+
+unprepare:
+	if (ret)
+		k3_m4_unprepare(dev);
+proc_release:
+	ti_sci_proc_release(&m4->tsp);
+	return ret;
+}
+
+/**
+ * k3_m4_start() - Start the remote processor
+ * @dev:	rproc device pointer
+ *
+ * Return: 0 if all went ok, else return appropriate error
+ */
+static int k3_m4_start(struct udevice *dev)
+{
+	struct k3_m4_privdata *m4 = dev_get_priv(dev);
+	struct k3_m4_boot_data *data = m4->data;
+	int ret;
+
+	ret = ti_sci_proc_request(&m4->tsp);
+	if (ret)
+		return ret;
+
+	if (!data->uses_lreset) {
+		ret = ti_sci_proc_power_domain_on(&m4->tsp);
+		if (ret)
+			goto proc_release;
+	}
+
+	ret = reset_deassert(&m4->m4_rst);
+	if (ret) {
+		if (!data->uses_lreset)
+			ti_sci_proc_power_domain_off(&m4->tsp);
+	}
+
+proc_release:
+	ti_sci_proc_release(&m4->tsp);
+
+	return ret;
+}
+
+static int k3_m4_stop(struct udevice *dev)
+{
+	struct k3_m4_privdata *m4 = dev_get_priv(dev);
+
+	ti_sci_proc_request(&m4->tsp);
+	reset_assert(&m4->m4_rst);
+	ti_sci_proc_power_domain_off(&m4->tsp);
+	ti_sci_proc_release(&m4->tsp);
+
+	return 0;
+}
+
+/**
+ * k3_m4_init() - Initialize the remote processor
+ * @dev:	rproc device pointer
+ *
+ * Return: 0 if all went ok, else return appropriate error
+ */
+static int k3_m4_init(struct udevice *dev)
+{
+	return 0;
+}
+
+static int k3_m4_reset(struct udevice *dev)
+{
+	return 0;
+}
+
+static void *k3_m4_da_to_va(struct udevice *dev, ulong da, ulong len)
+{
+	struct k3_m4_privdata *m4 = dev_get_priv(dev);
+	phys_addr_t bus_addr, dev_addr;
+	void __iomem *va = NULL;
+	size_t size;
+	u32 offset;
+	int i;
+
+	if (len <= 0)
+		return NULL;
+
+	for (i = 0; i < m4->num_mems; i++) {
+		bus_addr = m4->mem[i].bus_addr;
+		dev_addr = m4->mem[i].dev_addr;
+		size = m4->mem[i].size;
+
+		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
+			offset = da - dev_addr;
+			va = m4->mem[i].cpu_addr + offset;
+			return (__force void *)va;
+		}
+
+		if (da >= bus_addr && (da + len) <= (bus_addr + size)) {
+			offset = da - bus_addr;
+			va = m4->mem[i].cpu_addr + offset;
+			return (__force void *)va;
+		}
+	}
+
+	/* Assume it is DDR region and return da */
+	return map_physmem(da, len, MAP_NOCACHE);
+}
+
+static const struct dm_rproc_ops k3_m4_ops = {
+	.init = k3_m4_init,
+	.load = k3_m4_load,
+	.start = k3_m4_start,
+	.stop = k3_m4_stop,
+	.reset = k3_m4_reset,
+	.device_to_virt = k3_m4_da_to_va,
+};
+
+static int ti_sci_proc_of_to_priv(struct udevice *dev, struct ti_sci_proc *tsp)
+{
+	u32 ids[2];
+	int ret;
+
+	tsp->sci = ti_sci_get_by_phandle(dev, "ti,sci");
+	if (IS_ERR(tsp->sci)) {
+		dev_err(dev, "ti_sci get failed: %ld\n", PTR_ERR(tsp->sci));
+		return PTR_ERR(tsp->sci);
+	}
+
+	ret = dev_read_u32_array(dev, "ti,sci-proc-ids", ids, 2);
+	if (ret) {
+		dev_err(dev, "Proc IDs not populated %d\n", ret);
+		return ret;
+	}
+
+	tsp->ops = &tsp->sci->ops.proc_ops;
+	tsp->proc_id = ids[0];
+	tsp->host_id = ids[1];
+	tsp->dev_id = dev_read_u32_default(dev, "ti,sci-dev-id",
+					   TI_SCI_RESOURCE_NULL);
+	if (tsp->dev_id == TI_SCI_RESOURCE_NULL) {
+		dev_err(dev, "Device ID not populated %d\n", ret);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static const struct k3_m4_mem_data am6_m4_mems[] = {
+	{ .name = "iram", .dev_addr = 0x0 },
+	{ .name = "dram", .dev_addr = 0x30000 },
+};
+
+static int k3_m4_of_get_memories(struct udevice *dev)
+{
+	struct k3_m4_privdata *m4 = dev_get_priv(dev);
+	int i;
+
+	m4->num_mems = ARRAY_SIZE(am6_m4_mems);
+	m4->mem = calloc(m4->num_mems, sizeof(*m4->mem));
+	if (!m4->mem)
+		return -ENOMEM;
+
+	for (i = 0; i < m4->num_mems; i++) {
+		m4->mem[i].bus_addr = dev_read_addr_size_name(dev,
+							      am6_m4_mems[i].name,
+					  (fdt_addr_t *)&m4->mem[i].size);
+		if (m4->mem[i].bus_addr == FDT_ADDR_T_NONE) {
+			dev_err(dev, "%s bus address not found\n",
+				am6_m4_mems[i].name);
+			return -EINVAL;
+		}
+		m4->mem[i].cpu_addr = map_physmem(m4->mem[i].bus_addr,
+						  m4->mem[i].size,
+						  MAP_NOCACHE);
+		m4->mem[i].dev_addr = am6_m4_mems[i].dev_addr;
+	}
+
+	return 0;
+}
+
+/**
+ * k3_of_to_priv() - generate private data from device tree
+ * @dev:	corresponding k3 m4 processor device
+ * @m4:		pointer to driver specific private data
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_m4_of_to_priv(struct udevice *dev, struct k3_m4_privdata *m4)
+{
+	int ret;
+
+	ret = reset_get_by_index(dev, 0, &m4->m4_rst);
+	if (ret) {
+		dev_err(dev, "reset_get() failed: %d\n", ret);
+		return ret;
+	}
+
+	ret = ti_sci_proc_of_to_priv(dev, &m4->tsp);
+	if (ret)
+		return ret;
+
+	ret =  k3_m4_of_get_memories(dev);
+	if (ret)
+		return ret;
+
+	m4->data = (struct k3_m4_boot_data *)dev_get_driver_data(dev);
+
+	return 0;
+}
+
+/**
+ * k3_m4_probe() - Basic probe
+ * @dev:	corresponding k3 remote processor device
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_m4_probe(struct udevice *dev)
+{
+	struct k3_m4_privdata *m4;
+	int ret;
+
+	m4 = dev_get_priv(dev);
+	ret = k3_m4_of_to_priv(dev, m4);
+	if (ret)
+		return ret;
+
+	/*
+	 * The M4 local resets are deasserted by default on Power-On-Reset.
+	 * Assert the local resets to ensure the M4s don't execute bogus code
+	 * in .load() callback when the module reset is released to support
+	 * internal memory loading. This is needed for M4 cores.
+	 */
+	reset_assert(&m4->m4_rst);
+
+	return 0;
+}
+
+static int k3_m4_remove(struct udevice *dev)
+{
+	struct k3_m4_privdata *m4 = dev_get_priv(dev);
+
+	free(m4->mem);
+
+	return 0;
+}
+
+static const struct k3_m4_boot_data m4_data = {
+	.boot_align_addr = SZ_1K,
+	.uses_lreset = true,
+};
+
+static const struct udevice_id k3_m4_ids[] = {
+	{ .compatible = "ti,am64-m4fss", .data = (ulong)&m4_data, },
+	{}
+};
+
+U_BOOT_DRIVER(k3_m4) = {
+	.name = "k3_m4",
+	.of_match = k3_m4_ids,
+	.id = UCLASS_REMOTEPROC,
+	.ops = &k3_m4_ops,
+	.probe = k3_m4_probe,
+	.remove = k3_m4_remove,
+	.priv_auto = sizeof(struct k3_m4_privdata),
+};
-- 
2.48.0

Re: [PATCH 1/4] remoteproc: k3-m4: Introduce K3 remote proc driver for M4 subsystem

[Daniel Schultz]

Hey,

thanks for sending this driver! Tested it on our AM64x board. See two 
comments below.

On 23.01.25 02:07, Judith Mendez wrote:
> From: Hari Nagalla <hnagalla@ti.com>
>
> Some K3 devices like AM64, AM62 devices have a M4 processor in MCU
> voltage domain.
>
> Add a remote proc driver to support this subsystem to be able to load
> and boot the M4 core.
>
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> [Judith: Fixed comments explaining local resets]
> Signed-off-by: Judith Mendez <jm@ti.com>
Tested-by: Daniel Schultz <d.schultz@phytec.de>
> ---
>   drivers/remoteproc/Kconfig          |  10 +
>   drivers/remoteproc/Makefile         |   1 +
>   drivers/remoteproc/ti_k3_m4_rproc.c | 411 ++++++++++++++++++++++++++++
>   3 files changed, 422 insertions(+)
>   create mode 100644 drivers/remoteproc/ti_k3_m4_rproc.c
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 2790b168b19..e579c4e8371 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -80,6 +80,16 @@ config REMOTEPROC_TI_K3_R5F
>   	  on various TI K3 family of SoCs through the remote processor
>   	  framework.
>   
> +config REMOTEPROC_TI_K3_M4F
> +	bool "TI K3 M4F remoteproc support"
> +	select REMOTEPROC
> +	depends on ARCH_K3
> +	depends on TI_SCI_PROTOCOL
> +	help
> +	  Say y here to support TI's M4F remote processor subsystems
> +	  on various TI K3 family of SoCs through the remote processor
> +	  framework.
> +


this config is placed after REMOTEPROC_TI_K3_R5F and not ordered 
alphabetically ... not sure how important the order is in those Kconfig 
files.


>   config REMOTEPROC_TI_POWER
>   	bool "Support for TI Power processor"
>   	select REMOTEPROC
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 3a092b7660e..f81e5009c5e 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
>   obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
>   obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
>   obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
> +obj-$(CONFIG_REMOTEPROC_TI_K3_M4F) += ti_k3_m4_rproc.o
>   obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
>   obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
>   obj-$(CONFIG_REMOTEPROC_TI_PRU) += pru_rproc.o
> diff --git a/drivers/remoteproc/ti_k3_m4_rproc.c b/drivers/remoteproc/ti_k3_m4_rproc.c
> new file mode 100644
> index 00000000000..5a5ae2fa81d
> --- /dev/null
> +++ b/drivers/remoteproc/ti_k3_m4_rproc.c
> @@ -0,0 +1,411 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Texas Instruments' K3 M4 Remoteproc driver
> + *
> + * Copyright (C) 2024 Texas Instruments Incorporated - http://www.ti.com/
> + *	Hari Nagalla <hnagalla@ti.com>
> + */
> +
> +#include <dm.h>
> +#include <log.h>
> +#include <malloc.h>
> +#include <remoteproc.h>
> +#include <errno.h>
> +#include <clk.h>
> +#include <reset.h>
> +#include <asm/io.h>
> +#include <power-domain.h>
> +#include <dm/device_compat.h>
> +#include <linux/err.h>
> +#include <linux/sizes.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +#include "ti_sci_proc.h"
> +
> +/**
> + * struct k3_m4_mem - internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @dev_addr: Device address from remoteproc view
> + * @size: Size of the memory region
> + */
> +struct k3_m4_mem {
> +	void __iomem *cpu_addr;
> +	phys_addr_t bus_addr;
> +	phys_addr_t dev_addr;
> +	size_t size;
> +};
> +
> +/**
> + * struct k3_m4_mem_data - memory definitions for m4 remote core
> + * @name: name for this memory entry
> + * @dev_addr: device address for the memory entry
> + */
> +struct k3_m4_mem_data {
> +	const char *name;
> +	const u32 dev_addr;
> +};
> +
> +/**
> + * struct k3_m4_boot_data - internal data structure used for boot
> + * @boot_align_addr: Boot vector address alignment granularity
> + * @uses_lreset: Flag to denote the need for local reset management
> + */
> +struct k3_m4_boot_data {
> +	u32 boot_align_addr;
> +	bool uses_lreset;
> +};
> +
> +/**
> + * struct k3_m4_privdata - Structure representing Remote processor data.
> + * @m4_rst:		m4 rproc reset control data
> + * @tsp:		Pointer to TISCI proc contrl handle
> + * @data:		Pointer to DSP specific boot data structure
> + * @mem:		Array of available memories
> + * @num_mem:		Number of available memories
> + */
> +struct k3_m4_privdata {
> +	struct reset_ctl m4_rst;
> +	struct ti_sci_proc tsp;
> +	struct k3_m4_boot_data *data;
> +	struct k3_m4_mem *mem;
> +	int num_mems;
> +};
> +
> +/*
> + * The M4 cores have a local reset that affects only the CPU, and a
> + * generic module reset that powers on the device and allows the M4 internal
> + * memories to be accessed while the local reset is asserted. This function is
> + * used to release the global reset on M4F to allow loading into the M4F
> + * internal RAMs. This helper function is invoked in k3_m4_load() before any
> + * actual firmware loading and is undone only in k3_m4_stop(). The local reset
> + * cannot be released on M4 cores until after the firmware images are loaded.
> + */
> +static int k3_m4_prepare(struct udevice *dev)
> +{
> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
> +	struct k3_m4_boot_data *data = m4->data;
> +	int ret;
> +
> +	if (!data->uses_lreset)
> +		return 0;
> +
> +	ret = ti_sci_proc_power_domain_on(&m4->tsp);
> +	if (ret)
> +		dev_err(dev, "cannot enable internal RAM loading, ret = %d\n",
> +			ret);
> +
> +	return ret;
> +}
> +
> +/*
> + * This function is the counterpart to k3_m4_prepare() and is used to assert
> + * the global reset on M4 cores. This completes the second step of powering
> + * down the M4 cores. The cores themselves are halted through the local reset
> + * in first step. This function is invoked in k3_m4_stop() after the local
> + * reset is asserted.
> + */
> +static int k3_m4_unprepare(struct udevice *dev)
> +{
> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
> +	struct k3_m4_boot_data *data = m4->data;
> +
> +	if (!data->uses_lreset)
> +		return 0;
> +
> +	return ti_sci_proc_power_domain_off(&m4->tsp);
> +}
> +
> +/**
> + * k3_m4_load() - Load up the Remote processor image
> + * @dev:	rproc device pointer
> + * @addr:	Address at which image is available
> + * @size:	size of the image
> + *
> + * Return: 0 if all goes good, else appropriate error message.
> + */
> +static int k3_m4_load(struct udevice *dev, ulong addr, ulong size)
> +{
> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
> +	void *image_addr = (void *)addr;
> +	int ret;
> +
> +	ret = ti_sci_proc_request(&m4->tsp);
> +	if (ret)
> +		return ret;
> +
> +	ret = k3_m4_prepare(dev);
> +	if (ret) {
> +		dev_err(dev, "Prepare failed for core %d\n",
> +			m4->tsp.proc_id);
> +		goto proc_release;
> +	}
> +
> +	ti_secure_image_post_process(&image_addr, &size);
> +
> +	ret = rproc_elf_load_image(dev, addr, size);
> +	if (ret < 0) {
> +		dev_err(dev, "Loading elf failed %d\n", ret);
> +		goto unprepare;
> +	}
> +
> +unprepare:
> +	if (ret)
> +		k3_m4_unprepare(dev);
> +proc_release:
> +	ti_sci_proc_release(&m4->tsp);
> +	return ret;
> +}
> +
> +/**
> + * k3_m4_start() - Start the remote processor
> + * @dev:	rproc device pointer
> + *
> + * Return: 0 if all went ok, else return appropriate error
> + */
> +static int k3_m4_start(struct udevice *dev)
> +{
> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
> +	struct k3_m4_boot_data *data = m4->data;
> +	int ret;
> +
> +	ret = ti_sci_proc_request(&m4->tsp);
> +	if (ret)
> +		return ret;
> +
> +	if (!data->uses_lreset) {
> +		ret = ti_sci_proc_power_domain_on(&m4->tsp);
> +		if (ret)
> +			goto proc_release;
> +	}
> +
> +	ret = reset_deassert(&m4->m4_rst);
> +	if (ret) {
> +		if (!data->uses_lreset)
> +			ti_sci_proc_power_domain_off(&m4->tsp);
> +	}
> +
> +proc_release:
> +	ti_sci_proc_release(&m4->tsp);
> +
> +	return ret;
> +}
> +
> +static int k3_m4_stop(struct udevice *dev)
> +{
> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
> +
> +	ti_sci_proc_request(&m4->tsp);
> +	reset_assert(&m4->m4_rst);
> +	ti_sci_proc_power_domain_off(&m4->tsp);


Is is safe to call ti_sci_prop_power_domain_off when data->uses_lreset 
is set? The start function has a check included.

- Daniel

> +	ti_sci_proc_release(&m4->tsp);
> +
> +	return 0;
> +}
> +
> +/**
> + * k3_m4_init() - Initialize the remote processor
> + * @dev:	rproc device pointer
> + *
> + * Return: 0 if all went ok, else return appropriate error
> + */
> +static int k3_m4_init(struct udevice *dev)
> +{
> +	return 0;
> +}
> +
> +static int k3_m4_reset(struct udevice *dev)
> +{
> +	return 0;
> +}
> +
> +static void *k3_m4_da_to_va(struct udevice *dev, ulong da, ulong len)
> +{
> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
> +	phys_addr_t bus_addr, dev_addr;
> +	void __iomem *va = NULL;
> +	size_t size;
> +	u32 offset;
> +	int i;
> +
> +	if (len <= 0)
> +		return NULL;
> +
> +	for (i = 0; i < m4->num_mems; i++) {
> +		bus_addr = m4->mem[i].bus_addr;
> +		dev_addr = m4->mem[i].dev_addr;
> +		size = m4->mem[i].size;
> +
> +		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> +			offset = da - dev_addr;
> +			va = m4->mem[i].cpu_addr + offset;
> +			return (__force void *)va;
> +		}
> +
> +		if (da >= bus_addr && (da + len) <= (bus_addr + size)) {
> +			offset = da - bus_addr;
> +			va = m4->mem[i].cpu_addr + offset;
> +			return (__force void *)va;
> +		}
> +	}
> +
> +	/* Assume it is DDR region and return da */
> +	return map_physmem(da, len, MAP_NOCACHE);
> +}
> +
> +static const struct dm_rproc_ops k3_m4_ops = {
> +	.init = k3_m4_init,
> +	.load = k3_m4_load,
> +	.start = k3_m4_start,
> +	.stop = k3_m4_stop,
> +	.reset = k3_m4_reset,
> +	.device_to_virt = k3_m4_da_to_va,
> +};
> +
> +static int ti_sci_proc_of_to_priv(struct udevice *dev, struct ti_sci_proc *tsp)
> +{
> +	u32 ids[2];
> +	int ret;
> +
> +	tsp->sci = ti_sci_get_by_phandle(dev, "ti,sci");
> +	if (IS_ERR(tsp->sci)) {
> +		dev_err(dev, "ti_sci get failed: %ld\n", PTR_ERR(tsp->sci));
> +		return PTR_ERR(tsp->sci);
> +	}
> +
> +	ret = dev_read_u32_array(dev, "ti,sci-proc-ids", ids, 2);
> +	if (ret) {
> +		dev_err(dev, "Proc IDs not populated %d\n", ret);
> +		return ret;
> +	}
> +
> +	tsp->ops = &tsp->sci->ops.proc_ops;
> +	tsp->proc_id = ids[0];
> +	tsp->host_id = ids[1];
> +	tsp->dev_id = dev_read_u32_default(dev, "ti,sci-dev-id",
> +					   TI_SCI_RESOURCE_NULL);
> +	if (tsp->dev_id == TI_SCI_RESOURCE_NULL) {
> +		dev_err(dev, "Device ID not populated %d\n", ret);
> +		return -ENODEV;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct k3_m4_mem_data am6_m4_mems[] = {
> +	{ .name = "iram", .dev_addr = 0x0 },
> +	{ .name = "dram", .dev_addr = 0x30000 },
> +};
> +
> +static int k3_m4_of_get_memories(struct udevice *dev)
> +{
> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
> +	int i;
> +
> +	m4->num_mems = ARRAY_SIZE(am6_m4_mems);
> +	m4->mem = calloc(m4->num_mems, sizeof(*m4->mem));
> +	if (!m4->mem)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < m4->num_mems; i++) {
> +		m4->mem[i].bus_addr = dev_read_addr_size_name(dev,
> +							      am6_m4_mems[i].name,
> +					  (fdt_addr_t *)&m4->mem[i].size);
> +		if (m4->mem[i].bus_addr == FDT_ADDR_T_NONE) {
> +			dev_err(dev, "%s bus address not found\n",
> +				am6_m4_mems[i].name);
> +			return -EINVAL;
> +		}
> +		m4->mem[i].cpu_addr = map_physmem(m4->mem[i].bus_addr,
> +						  m4->mem[i].size,
> +						  MAP_NOCACHE);
> +		m4->mem[i].dev_addr = am6_m4_mems[i].dev_addr;
> +	}
> +
> +	return 0;
> +}
> +
> +/**
> + * k3_of_to_priv() - generate private data from device tree
> + * @dev:	corresponding k3 m4 processor device
> + * @m4:		pointer to driver specific private data
> + *
> + * Return: 0 if all goes good, else appropriate error message.
> + */
> +static int k3_m4_of_to_priv(struct udevice *dev, struct k3_m4_privdata *m4)
> +{
> +	int ret;
> +
> +	ret = reset_get_by_index(dev, 0, &m4->m4_rst);
> +	if (ret) {
> +		dev_err(dev, "reset_get() failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = ti_sci_proc_of_to_priv(dev, &m4->tsp);
> +	if (ret)
> +		return ret;
> +
> +	ret =  k3_m4_of_get_memories(dev);
> +	if (ret)
> +		return ret;
> +
> +	m4->data = (struct k3_m4_boot_data *)dev_get_driver_data(dev);
> +
> +	return 0;
> +}
> +
> +/**
> + * k3_m4_probe() - Basic probe
> + * @dev:	corresponding k3 remote processor device
> + *
> + * Return: 0 if all goes good, else appropriate error message.
> + */
> +static int k3_m4_probe(struct udevice *dev)
> +{
> +	struct k3_m4_privdata *m4;
> +	int ret;
> +
> +	m4 = dev_get_priv(dev);
> +	ret = k3_m4_of_to_priv(dev, m4);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * The M4 local resets are deasserted by default on Power-On-Reset.
> +	 * Assert the local resets to ensure the M4s don't execute bogus code
> +	 * in .load() callback when the module reset is released to support
> +	 * internal memory loading. This is needed for M4 cores.
> +	 */
> +	reset_assert(&m4->m4_rst);
> +
> +	return 0;
> +}
> +
> +static int k3_m4_remove(struct udevice *dev)
> +{
> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
> +
> +	free(m4->mem);
> +
> +	return 0;
> +}
> +
> +static const struct k3_m4_boot_data m4_data = {
> +	.boot_align_addr = SZ_1K,
> +	.uses_lreset = true,
> +};
> +
> +static const struct udevice_id k3_m4_ids[] = {
> +	{ .compatible = "ti,am64-m4fss", .data = (ulong)&m4_data, },
> +	{}
> +};
> +
> +U_BOOT_DRIVER(k3_m4) = {
> +	.name = "k3_m4",
> +	.of_match = k3_m4_ids,
> +	.id = UCLASS_REMOTEPROC,
> +	.ops = &k3_m4_ops,
> +	.probe = k3_m4_probe,
> +	.remove = k3_m4_remove,
> +	.priv_auto = sizeof(struct k3_m4_privdata),
> +};

Re: [PATCH 1/4] remoteproc: k3-m4: Introduce K3 remote proc driver for M4 subsystem

[Judith Mendez]

Hello Daniel,

On 1/29/25 7:24 AM, Daniel Schultz wrote:
> Hey,
> 
> thanks for sending this driver! Tested it on our AM64x board. See two
> comments below.
> 
> On 23.01.25 02:07, Judith Mendez wrote:
>> From: Hari Nagalla <hnagalla@ti.com>
>>
>> Some K3 devices like AM64, AM62 devices have a M4 processor in MCU
>> voltage domain.
>>
>> Add a remote proc driver to support this subsystem to be able to load
>> and boot the M4 core.
>>
>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>> [Judith: Fixed comments explaining local resets]
>> Signed-off-by: Judith Mendez <jm@ti.com>
> Tested-by: Daniel Schultz <d.schultz@phytec.de>
>> ---
>>    drivers/remoteproc/Kconfig          |  10 +
>>    drivers/remoteproc/Makefile         |   1 +
>>    drivers/remoteproc/ti_k3_m4_rproc.c | 411 ++++++++++++++++++++++++++++
>>    3 files changed, 422 insertions(+)
>>    create mode 100644 drivers/remoteproc/ti_k3_m4_rproc.c
>>
>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>> index 2790b168b19..e579c4e8371 100644
>> --- a/drivers/remoteproc/Kconfig
>> +++ b/drivers/remoteproc/Kconfig
>> @@ -80,6 +80,16 @@ config REMOTEPROC_TI_K3_R5F
>>    	  on various TI K3 family of SoCs through the remote processor
>>    	  framework.
>>    
>> +config REMOTEPROC_TI_K3_M4F
>> +	bool "TI K3 M4F remoteproc support"
>> +	select REMOTEPROC
>> +	depends on ARCH_K3
>> +	depends on TI_SCI_PROTOCOL
>> +	help
>> +	  Say y here to support TI's M4F remote processor subsystems
>> +	  on various TI K3 family of SoCs through the remote processor
>> +	  framework.
>> +
> 
> 
> this config is placed after REMOTEPROC_TI_K3_R5F and not ordered
> alphabetically ... not sure how important the order is in those Kconfig
> files.

I can fix it no problem. Not sure if it matters much but will fix
alphabetically.

> 
> 
>>    config REMOTEPROC_TI_POWER
>>    	bool "Support for TI Power processor"
>>    	select REMOTEPROC
>> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
>> index 3a092b7660e..f81e5009c5e 100644
>> --- a/drivers/remoteproc/Makefile
>> +++ b/drivers/remoteproc/Makefile
>> @@ -13,6 +13,7 @@ obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
>>    obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
>>    obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
>>    obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
>> +obj-$(CONFIG_REMOTEPROC_TI_K3_M4F) += ti_k3_m4_rproc.o
>>    obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
>>    obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
>>    obj-$(CONFIG_REMOTEPROC_TI_PRU) += pru_rproc.o
>> diff --git a/drivers/remoteproc/ti_k3_m4_rproc.c b/drivers/remoteproc/ti_k3_m4_rproc.c
>> new file mode 100644
>> index 00000000000..5a5ae2fa81d
>> --- /dev/null
>> +++ b/drivers/remoteproc/ti_k3_m4_rproc.c
>> @@ -0,0 +1,411 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Texas Instruments' K3 M4 Remoteproc driver
>> + *
>> + * Copyright (C) 2024 Texas Instruments Incorporated - http://www.ti.com/
>> + *	Hari Nagalla <hnagalla@ti.com>
>> + */
>> +
>> +#include <dm.h>
>> +#include <log.h>
>> +#include <malloc.h>
>> +#include <remoteproc.h>
>> +#include <errno.h>
>> +#include <clk.h>
>> +#include <reset.h>
>> +#include <asm/io.h>
>> +#include <power-domain.h>
>> +#include <dm/device_compat.h>
>> +#include <linux/err.h>
>> +#include <linux/sizes.h>
>> +#include <linux/soc/ti/ti_sci_protocol.h>
>> +#include "ti_sci_proc.h"
>> +
>> +/**
>> + * struct k3_m4_mem - internal memory structure
>> + * @cpu_addr: MPU virtual address of the memory region
>> + * @bus_addr: Bus address used to access the memory region
>> + * @dev_addr: Device address from remoteproc view
>> + * @size: Size of the memory region
>> + */
>> +struct k3_m4_mem {
>> +	void __iomem *cpu_addr;
>> +	phys_addr_t bus_addr;
>> +	phys_addr_t dev_addr;
>> +	size_t size;
>> +};
>> +
>> +/**
>> + * struct k3_m4_mem_data - memory definitions for m4 remote core
>> + * @name: name for this memory entry
>> + * @dev_addr: device address for the memory entry
>> + */
>> +struct k3_m4_mem_data {
>> +	const char *name;
>> +	const u32 dev_addr;
>> +};
>> +
>> +/**
>> + * struct k3_m4_boot_data - internal data structure used for boot
>> + * @boot_align_addr: Boot vector address alignment granularity
>> + * @uses_lreset: Flag to denote the need for local reset management
>> + */
>> +struct k3_m4_boot_data {
>> +	u32 boot_align_addr;
>> +	bool uses_lreset;
>> +};
>> +
>> +/**
>> + * struct k3_m4_privdata - Structure representing Remote processor data.
>> + * @m4_rst:		m4 rproc reset control data
>> + * @tsp:		Pointer to TISCI proc contrl handle
>> + * @data:		Pointer to DSP specific boot data structure
>> + * @mem:		Array of available memories
>> + * @num_mem:		Number of available memories
>> + */
>> +struct k3_m4_privdata {
>> +	struct reset_ctl m4_rst;
>> +	struct ti_sci_proc tsp;
>> +	struct k3_m4_boot_data *data;
>> +	struct k3_m4_mem *mem;
>> +	int num_mems;
>> +};
>> +
>> +/*
>> + * The M4 cores have a local reset that affects only the CPU, and a
>> + * generic module reset that powers on the device and allows the M4 internal
>> + * memories to be accessed while the local reset is asserted. This function is
>> + * used to release the global reset on M4F to allow loading into the M4F
>> + * internal RAMs. This helper function is invoked in k3_m4_load() before any
>> + * actual firmware loading and is undone only in k3_m4_stop(). The local reset
>> + * cannot be released on M4 cores until after the firmware images are loaded.
>> + */
>> +static int k3_m4_prepare(struct udevice *dev)
>> +{
>> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
>> +	struct k3_m4_boot_data *data = m4->data;
>> +	int ret;
>> +
>> +	if (!data->uses_lreset)
>> +		return 0;
>> +
>> +	ret = ti_sci_proc_power_domain_on(&m4->tsp);
>> +	if (ret)
>> +		dev_err(dev, "cannot enable internal RAM loading, ret = %d\n",
>> +			ret);
>> +
>> +	return ret;
>> +}
>> +
>> +/*
>> + * This function is the counterpart to k3_m4_prepare() and is used to assert
>> + * the global reset on M4 cores. This completes the second step of powering
>> + * down the M4 cores. The cores themselves are halted through the local reset
>> + * in first step. This function is invoked in k3_m4_stop() after the local
>> + * reset is asserted.
>> + */
>> +static int k3_m4_unprepare(struct udevice *dev)
>> +{
>> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
>> +	struct k3_m4_boot_data *data = m4->data;
>> +
>> +	if (!data->uses_lreset)
>> +		return 0;
>> +
>> +	return ti_sci_proc_power_domain_off(&m4->tsp);
>> +}
>> +
>> +/**
>> + * k3_m4_load() - Load up the Remote processor image
>> + * @dev:	rproc device pointer
>> + * @addr:	Address at which image is available
>> + * @size:	size of the image
>> + *
>> + * Return: 0 if all goes good, else appropriate error message.
>> + */
>> +static int k3_m4_load(struct udevice *dev, ulong addr, ulong size)
>> +{
>> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
>> +	void *image_addr = (void *)addr;
>> +	int ret;
>> +
>> +	ret = ti_sci_proc_request(&m4->tsp);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = k3_m4_prepare(dev);
>> +	if (ret) {
>> +		dev_err(dev, "Prepare failed for core %d\n",
>> +			m4->tsp.proc_id);
>> +		goto proc_release;
>> +	}
>> +
>> +	ti_secure_image_post_process(&image_addr, &size);
>> +
>> +	ret = rproc_elf_load_image(dev, addr, size);
>> +	if (ret < 0) {
>> +		dev_err(dev, "Loading elf failed %d\n", ret);
>> +		goto unprepare;
>> +	}
>> +
>> +unprepare:
>> +	if (ret)
>> +		k3_m4_unprepare(dev);
>> +proc_release:
>> +	ti_sci_proc_release(&m4->tsp);
>> +	return ret;
>> +}
>> +
>> +/**
>> + * k3_m4_start() - Start the remote processor
>> + * @dev:	rproc device pointer
>> + *
>> + * Return: 0 if all went ok, else return appropriate error
>> + */
>> +static int k3_m4_start(struct udevice *dev)
>> +{
>> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
>> +	struct k3_m4_boot_data *data = m4->data;
>> +	int ret;
>> +
>> +	ret = ti_sci_proc_request(&m4->tsp);
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (!data->uses_lreset) {
>> +		ret = ti_sci_proc_power_domain_on(&m4->tsp);
>> +		if (ret)
>> +			goto proc_release;
>> +	}
>> +
>> +	ret = reset_deassert(&m4->m4_rst);
>> +	if (ret) {
>> +		if (!data->uses_lreset)
>> +			ti_sci_proc_power_domain_off(&m4->tsp);
>> +	}
>> +
>> +proc_release:
>> +	ti_sci_proc_release(&m4->tsp);
>> +
>> +	return ret;
>> +}
>> +
>> +static int k3_m4_stop(struct udevice *dev)
>> +{
>> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
>> +
>> +	ti_sci_proc_request(&m4->tsp);
>> +	reset_assert(&m4->m4_rst);
>> +	ti_sci_proc_power_domain_off(&m4->tsp);
> 
> 
> Is is safe to call ti_sci_prop_power_domain_off when data->uses_lreset
> is set? The start function has a check included.

uses_lreset here is just a flag used in this driver which is always set
actually, so it does not really do anything. I see how this flag can
cause some confusion, let me cleanup this flag from the driver since it
will always be set.

Thanks for reviewing!

~ Judith


> 
> - Daniel
> 
>> +	ti_sci_proc_release(&m4->tsp);
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * k3_m4_init() - Initialize the remote processor
>> + * @dev:	rproc device pointer
>> + *
>> + * Return: 0 if all went ok, else return appropriate error
>> + */
>> +static int k3_m4_init(struct udevice *dev)
>> +{
>> +	return 0;
>> +}
>> +
>> +static int k3_m4_reset(struct udevice *dev)
>> +{
>> +	return 0;
>> +}
>> +
>> +static void *k3_m4_da_to_va(struct udevice *dev, ulong da, ulong len)
>> +{
>> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
>> +	phys_addr_t bus_addr, dev_addr;
>> +	void __iomem *va = NULL;
>> +	size_t size;
>> +	u32 offset;
>> +	int i;
>> +
>> +	if (len <= 0)
>> +		return NULL;
>> +
>> +	for (i = 0; i < m4->num_mems; i++) {
>> +		bus_addr = m4->mem[i].bus_addr;
>> +		dev_addr = m4->mem[i].dev_addr;
>> +		size = m4->mem[i].size;
>> +
>> +		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
>> +			offset = da - dev_addr;
>> +			va = m4->mem[i].cpu_addr + offset;
>> +			return (__force void *)va;
>> +		}
>> +
>> +		if (da >= bus_addr && (da + len) <= (bus_addr + size)) {
>> +			offset = da - bus_addr;
>> +			va = m4->mem[i].cpu_addr + offset;
>> +			return (__force void *)va;
>> +		}
>> +	}
>> +
>> +	/* Assume it is DDR region and return da */
>> +	return map_physmem(da, len, MAP_NOCACHE);
>> +}
>> +
>> +static const struct dm_rproc_ops k3_m4_ops = {
>> +	.init = k3_m4_init,
>> +	.load = k3_m4_load,
>> +	.start = k3_m4_start,
>> +	.stop = k3_m4_stop,
>> +	.reset = k3_m4_reset,
>> +	.device_to_virt = k3_m4_da_to_va,
>> +};
>> +
>> +static int ti_sci_proc_of_to_priv(struct udevice *dev, struct ti_sci_proc *tsp)
>> +{
>> +	u32 ids[2];
>> +	int ret;
>> +
>> +	tsp->sci = ti_sci_get_by_phandle(dev, "ti,sci");
>> +	if (IS_ERR(tsp->sci)) {
>> +		dev_err(dev, "ti_sci get failed: %ld\n", PTR_ERR(tsp->sci));
>> +		return PTR_ERR(tsp->sci);
>> +	}
>> +
>> +	ret = dev_read_u32_array(dev, "ti,sci-proc-ids", ids, 2);
>> +	if (ret) {
>> +		dev_err(dev, "Proc IDs not populated %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	tsp->ops = &tsp->sci->ops.proc_ops;
>> +	tsp->proc_id = ids[0];
>> +	tsp->host_id = ids[1];
>> +	tsp->dev_id = dev_read_u32_default(dev, "ti,sci-dev-id",
>> +					   TI_SCI_RESOURCE_NULL);
>> +	if (tsp->dev_id == TI_SCI_RESOURCE_NULL) {
>> +		dev_err(dev, "Device ID not populated %d\n", ret);
>> +		return -ENODEV;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct k3_m4_mem_data am6_m4_mems[] = {
>> +	{ .name = "iram", .dev_addr = 0x0 },
>> +	{ .name = "dram", .dev_addr = 0x30000 },
>> +};
>> +
>> +static int k3_m4_of_get_memories(struct udevice *dev)
>> +{
>> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
>> +	int i;
>> +
>> +	m4->num_mems = ARRAY_SIZE(am6_m4_mems);
>> +	m4->mem = calloc(m4->num_mems, sizeof(*m4->mem));
>> +	if (!m4->mem)
>> +		return -ENOMEM;
>> +
>> +	for (i = 0; i < m4->num_mems; i++) {
>> +		m4->mem[i].bus_addr = dev_read_addr_size_name(dev,
>> +							      am6_m4_mems[i].name,
>> +					  (fdt_addr_t *)&m4->mem[i].size);
>> +		if (m4->mem[i].bus_addr == FDT_ADDR_T_NONE) {
>> +			dev_err(dev, "%s bus address not found\n",
>> +				am6_m4_mems[i].name);
>> +			return -EINVAL;
>> +		}
>> +		m4->mem[i].cpu_addr = map_physmem(m4->mem[i].bus_addr,
>> +						  m4->mem[i].size,
>> +						  MAP_NOCACHE);
>> +		m4->mem[i].dev_addr = am6_m4_mems[i].dev_addr;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * k3_of_to_priv() - generate private data from device tree
>> + * @dev:	corresponding k3 m4 processor device
>> + * @m4:		pointer to driver specific private data
>> + *
>> + * Return: 0 if all goes good, else appropriate error message.
>> + */
>> +static int k3_m4_of_to_priv(struct udevice *dev, struct k3_m4_privdata *m4)
>> +{
>> +	int ret;
>> +
>> +	ret = reset_get_by_index(dev, 0, &m4->m4_rst);
>> +	if (ret) {
>> +		dev_err(dev, "reset_get() failed: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	ret = ti_sci_proc_of_to_priv(dev, &m4->tsp);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret =  k3_m4_of_get_memories(dev);
>> +	if (ret)
>> +		return ret;
>> +
>> +	m4->data = (struct k3_m4_boot_data *)dev_get_driver_data(dev);
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * k3_m4_probe() - Basic probe
>> + * @dev:	corresponding k3 remote processor device
>> + *
>> + * Return: 0 if all goes good, else appropriate error message.
>> + */
>> +static int k3_m4_probe(struct udevice *dev)
>> +{
>> +	struct k3_m4_privdata *m4;
>> +	int ret;
>> +
>> +	m4 = dev_get_priv(dev);
>> +	ret = k3_m4_of_to_priv(dev, m4);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/*
>> +	 * The M4 local resets are deasserted by default on Power-On-Reset.
>> +	 * Assert the local resets to ensure the M4s don't execute bogus code
>> +	 * in .load() callback when the module reset is released to support
>> +	 * internal memory loading. This is needed for M4 cores.
>> +	 */
>> +	reset_assert(&m4->m4_rst);
>> +
>> +	return 0;
>> +}
>> +
>> +static int k3_m4_remove(struct udevice *dev)
>> +{
>> +	struct k3_m4_privdata *m4 = dev_get_priv(dev);
>> +
>> +	free(m4->mem);
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct k3_m4_boot_data m4_data = {
>> +	.boot_align_addr = SZ_1K,
>> +	.uses_lreset = true,
>> +};
>> +
>> +static const struct udevice_id k3_m4_ids[] = {
>> +	{ .compatible = "ti,am64-m4fss", .data = (ulong)&m4_data, },
>> +	{}
>> +};
>> +
>> +U_BOOT_DRIVER(k3_m4) = {
>> +	.name = "k3_m4",
>> +	.of_match = k3_m4_ids,
>> +	.id = UCLASS_REMOTEPROC,
>> +	.ops = &k3_m4_ops,
>> +	.probe = k3_m4_probe,
>> +	.remove = k3_m4_remove,
>> +	.priv_auto = sizeof(struct k3_m4_privdata),
>> +};

[PATCH 2/4] remoteproc: k3-r5: Add support for R5F cores on AM64x SoCs

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

AM64x SoCs have two R5F clusters in the main power domain.
Extend support for R5F remote proc driver on AM64x with compatible
strings.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
---
 drivers/remoteproc/ti_k3_r5f_rproc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c b/drivers/remoteproc/ti_k3_r5f_rproc.c
index d78b3fa1bbd..57268e7f8ff 100644
--- a/drivers/remoteproc/ti_k3_r5f_rproc.c
+++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
@@ -886,6 +886,7 @@ static const struct udevice_id k3_r5f_rproc_ids[] = {
 	{ .compatible = "ti,j7200-r5f", .data = (ulong)&j7200_j721s2_data, },
 	{ .compatible = "ti,j721s2-r5f", .data = (ulong)&j7200_j721s2_data, },
 	{ .compatible = "ti,am62-r5f", .data = (ulong)&am62_data, },
+	{ .compatible = "ti,am64-r5f", .data = (ulong)&j7200_j721s2_data, },
 	{}
 };
 
@@ -930,6 +931,7 @@ static const struct udevice_id k3_r5fss_ids[] = {
 	{ .compatible = "ti,j7200-r5fss"},
 	{ .compatible = "ti,j721s2-r5fss"},
 	{ .compatible = "ti,am62-r5fss"},
+	{ .compatible = "ti,am64-r5fss"},
 	{}
 };
 
-- 
2.48.0

Re: [PATCH 2/4] remoteproc: k3-r5: Add support for R5F cores on AM64x SoCs

[Daniel Schultz]

On 23.01.25 02:07, Judith Mendez wrote:
> From: Hari Nagalla <hnagalla@ti.com>
>
> AM64x SoCs have two R5F clusters in the main power domain.
> Extend support for R5F remote proc driver on AM64x with compatible
> strings.
>
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Reviewed-by: Daniel Schultz <d.schultz@phytec.de>
> ---
>   drivers/remoteproc/ti_k3_r5f_rproc.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c b/drivers/remoteproc/ti_k3_r5f_rproc.c
> index d78b3fa1bbd..57268e7f8ff 100644
> --- a/drivers/remoteproc/ti_k3_r5f_rproc.c
> +++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
> @@ -886,6 +886,7 @@ static const struct udevice_id k3_r5f_rproc_ids[] = {
>   	{ .compatible = "ti,j7200-r5f", .data = (ulong)&j7200_j721s2_data, },
>   	{ .compatible = "ti,j721s2-r5f", .data = (ulong)&j7200_j721s2_data, },
>   	{ .compatible = "ti,am62-r5f", .data = (ulong)&am62_data, },
> +	{ .compatible = "ti,am64-r5f", .data = (ulong)&j7200_j721s2_data, },
>   	{}
>   };
>   
> @@ -930,6 +931,7 @@ static const struct udevice_id k3_r5fss_ids[] = {
>   	{ .compatible = "ti,j7200-r5fss"},
>   	{ .compatible = "ti,j721s2-r5fss"},
>   	{ .compatible = "ti,am62-r5fss"},
> +	{ .compatible = "ti,am64-r5fss"},
>   	{}
>   };
>   

[PATCH 3/4] env: ti: am64x: set rproc_fw_binaries

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

Set remote proc FW binaries for u-boot loading of remote cores.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
---
 board/ti/am64x/am64x.env | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index 8ad805a613c..43e557b8ec7 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -2,6 +2,10 @@
 #include <env/ti/mmc.env>
 #include <env/ti/k3_dfu.env>
 
+#if CONFIG_CMD_REMOTEPROC
+#include <env/ti/k3_rproc.env>
+#endif
+
 name_kern=Image
 console=ttyS2,115200n8
 args_all=setenv optargs earlycon=ns16550a,mmio32,0x02800000 ${mtdparts}
@@ -14,6 +18,8 @@ bootpart=1:2
 bootdir=/boot
 rd_spec=-
 
+rproc_fw_binaries= 0 /lib/firmware/am64-mcu-m4f0_0-fw 1 /lib/firmware/am64-main-r5f0_0-fw 2 /lib/firmware/am64-main-r5f0_1-fw 3 /lib/firmware/am64-main-r5f1_0-fw 4 /lib/firmware/am64-main-r5f1_1-fw
+
 args_usb=run finduuid;setenv bootargs console=${console}
 	${optargs}
 	root=PARTUUID=${uuid} rw
-- 
2.48.0

[PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable R5F and M4 remote proc support

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

Add support for R5F and M4 remoteproc drivers.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
---
 configs/am64x_evm_a53_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index e6e3e018da6..4630c424775 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -152,6 +152,8 @@ CONFIG_K3_SYSTEM_CONTROLLER=y
 CONFIG_REMOTEPROC_TI_K3_ARM64=y
 CONFIG_REMOTEPROC_TI_PRU=y
 CONFIG_CMD_REMOTEPROC=y
+CONFIG_REMOTEPROC_TI_K3_R5F=y
+CONFIG_REMOTEPROC_TI_K3_M4F=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_EMULATION=y
-- 
2.48.0