Hi Beleswar,
On Thu, Jul 24, 2025 at 07:01:44PM +0530, Beleswar Padhi wrote:
> When attaching to a remote processor, it is implied that the rproc was
> booted by an external entity. Thus, it's carveout and devmem resources
> would already have been processed by the external entity during boot.
>
> Re-allocating the carveouts in Linux (without proper flags) would zero
> out the memory regions used by the firmware and can lead to undefined
> behaviour. And there is no need to re-map the memory regions for devmem
> resources as well.
>
> Therefore, do not process the carveout and devmem resources in attach
> mode by not appending them to the rproc->carveouts and rproc->mappings
> lists respectively.
>
I think what you are proposing is logical. Arnaud, Daniel, Iuliana and Tanmay -
please test this on your platforms. I will also need another TB from someone at
TI.
Regards,
Mathieu
> Signed-off-by: Beleswar Padhi <b-pa...@ti.com>
> ---
> Testing:
> 1. Tested IPC with remoteprocs in attach mode in TI platforms.
> [However, TI K3 platforms do not use resource table for carveouts,
> all the memory regions are reserved statically in Device Tree.]
>
> drivers/remoteproc/remoteproc_core.c | 30 ++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 825672100528..ef709a5fa73c 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -640,6 +640,20 @@ static int rproc_handle_devmem(struct rproc *rproc, void
> *ptr,
> return -EINVAL;
> }
>
> + /*
> + * When attaching to a remote processor, it is implied that the rproc
> + * was booted by an external entity. Thus, it's devmem resources would
> + * already have been mapped by the external entity during boot. There is
> + * no need to re-map the memory regions here.
> + *
> + * Skip adding the devmem rsc to the mapping list and return without
> + * complaining.
> + */
> + if (rproc->state == RPROC_DETACHED) {
> + dev_info(dev, "skipping devmem rsc in attach mode\n");
> + return 0;
> + }
> +
> mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
> if (!mapping)
> return -ENOMEM;
> @@ -839,6 +853,22 @@ static int rproc_handle_carveout(struct rproc *rproc,
> return -EINVAL;
> }
>
> + /*
> + * When attaching to a remote processor, it is implied that the rproc
> + * was booted by an external entity. Thus, it's carveout resources would
> + * already have been allocated by the external entity during boot.
> + * Re-allocating the carveouts here (without proper flags) would zero
> + * out the memory regions used by the firmware and can lead to undefined
> + * behaviour.
> + *
> + * Skip adding the carveouts to the alloc list and return without
> + * complaining.
> + */
> + if (rproc->state == RPROC_DETACHED) {
> + dev_info(dev, "skipping carveout allocation in attach mode\n");
> + return 0;
> + }
> +
> dev_dbg(dev, "carveout rsc: name: %s, da 0x%x, pa 0x%x, len 0x%x, flags
> 0x%x\n",
> rsc->name, rsc->da, rsc->pa, rsc->len, rsc->flags);
>
> --
> 2.34.1
>
