[PATCH 0/2] remoteproc: xlnx: add auto-boot support

[PATCH 0/2] remoteproc: xlnx: add auto-boot support

[Tanmay Shah]

The Cortex-R remote processors on AMD-Xilinx platforms can run
before linux boot. Add auto-boot property to notify linux that remote
processor is ready to be used, so linux can load fw and start it or
attach to the running processor.


Tanmay Shah (2):
  dt-bindings: remoteproc: xlnx: add auto boot feature
  remoteproc: xlnx: enable auto boot feature

 .../remoteproc/xlnx,zynqmp-r5fss.yaml         |  8 +++
 drivers/remoteproc/xlnx_r5_remoteproc.c       | 49 +++++++++++++------
 2 files changed, 42 insertions(+), 15 deletions(-)


base-commit: 6f860d238b44da8ac57be25289b9f4410691c4e2
-- 
2.34.1

[PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature

[Tanmay Shah]

Add auto-boot property to notify that remote processor is setup and
ready to boot. Linux can attempt to boot or attach to already running
remote processor. "firmware-name" property is used to mention default
firmware to boot when linux starts the remote processor.

Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
 .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index ee63c03949c9..0d27260e3baa 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -135,6 +135,14 @@ patternProperties:
           - description: vring1
         additionalItems: true
 
+      auto-boot:
+        type: boolean
+        description: remote core is either already running or ready to boot
+
+      firmware-name:
+        maxItems: 1
+        description: default firmware to load
+
     required:
       - compatible
       - reg
-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature

[Krzysztof Kozlowski]

On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
> Add auto-boot property to notify that remote processor is setup and
> ready to boot. Linux can attempt to boot or attach to already running
> remote processor. "firmware-name" property is used to mention default
> firmware to boot when linux starts the remote processor.
> 
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
>  .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> index ee63c03949c9..0d27260e3baa 100644
> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> @@ -135,6 +135,14 @@ patternProperties:
>            - description: vring1
>          additionalItems: true
>  
> +      auto-boot:

Last months, I have been asking AMD to follow writing-bindings doc or
other DT guidelines way too many times.

Or you just sent us downstream... Do you see anywhere such property?
What properties do you see? How are they named?

> +        type: boolean
> +        description: remote core is either already running or ready to boot

And why is this property of a board?

> +
> +      firmware-name:
> +        maxItems: 1
> +        description: default firmware to load

Can you load non-default firmware later? IOW, why adding description
here, what is special?

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature

[Shah, Tanmay]

Hello,

Thanks for reviews. Please see my comments below.

On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote:
> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
>> Add auto-boot property to notify that remote processor is setup and
>> ready to boot. Linux can attempt to boot or attach to already running
>> remote processor. "firmware-name" property is used to mention default
>> firmware to boot when linux starts the remote processor.
>>
>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>> ---
>>  .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>> index ee63c03949c9..0d27260e3baa 100644
>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>> @@ -135,6 +135,14 @@ patternProperties:
>>            - description: vring1
>>          additionalItems: true
>>  
>> +      auto-boot:
> 
> Last months, I have been asking AMD to follow writing-bindings doc or
> other DT guidelines way too many times.
> 
> Or you just sent us downstream... Do you see anywhere such property?
> What properties do you see? How are they named?
> 

I should have put note about this. Current auto-boot properties are
named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific
there. Can we have a common auto-boot property? Similar to
firmware-name? If we agree to it then what's the correct location? New
file remoteproc.yaml is okay?

>> +        type: boolean
>> +        description: remote core is either already running or ready to boot
> 
> And why is this property of a board?
> 

Not sure what indicates it is? The property is under remoteproc child
device that is SOC level property. Remote core is on same SOC wher linux
core is running.

>> +
>> +      firmware-name:
>> +        maxItems: 1
>> +        description: default firmware to load
> 
> Can you load non-default firmware later? IOW, why adding description
> here, what is special?
> 

The rootfs contains other firmware demos, and it is possible to stop the
default firmware, load other fw elf and re-run the remote core.
I don't have strong preference on the description part, I will remove it
if redundant.

> Best regards,
> Krzysztof
> 

Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature

[Krzysztof Kozlowski]

On 23/04/2026 17:14, Shah, Tanmay wrote:
> Hello,
> 
> Thanks for reviews. Please see my comments below.
> 
> On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote:
>> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
>>> Add auto-boot property to notify that remote processor is setup and
>>> ready to boot. Linux can attempt to boot or attach to already running
>>> remote processor. "firmware-name" property is used to mention default
>>> firmware to boot when linux starts the remote processor.
>>>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>> ---
>>>  .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> index ee63c03949c9..0d27260e3baa 100644
>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> @@ -135,6 +135,14 @@ patternProperties:
>>>            - description: vring1
>>>          additionalItems: true
>>>  
>>> +      auto-boot:
>>
>> Last months, I have been asking AMD to follow writing-bindings doc or
>> other DT guidelines way too many times.
>>
>> Or you just sent us downstream... Do you see anywhere such property?
>> What properties do you see? How are they named?
>>
> 
> I should have put note about this. Current auto-boot properties are
> named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific
> there. Can we have a common auto-boot property? Similar to
> firmware-name? If we agree to it then what's the correct location? New
> file remoteproc.yaml is okay?

Common properties go to dtschema, so it would need to go there, but the
point is that it's way too generic - every component with FW could be
called "auto-boot". This should stay vendor property, IMO.

> 
>>> +        type: boolean
>>> +        description: remote core is either already running or ready to boot
>>
>> And why is this property of a board?
>>
> 
> Not sure what indicates it is? The property is under remoteproc child
> device that is SOC level property. Remote core is on same SOC wher linux
> core is running.

So it is implied by SoC compatible? Please provide some arguments why it
cannot be implied by the SoC compatible. I gave you one way out, but if
you disagree then no problem.

> 
>>> +
>>> +      firmware-name:
>>> +        maxItems: 1
>>> +        description: default firmware to load
>>
>> Can you load non-default firmware later? IOW, why adding description
>> here, what is special?
>>
> 
> The rootfs contains other firmware demos, and it is possible to stop the
> default firmware, load other fw elf and re-run the remote core.
> I don't have strong preference on the description part, I will remove it
> if redundant.

No, it's fine, I wanted to be sure that such use case makes sense.

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature

[Shah, Tanmay]

On 4/23/2026 12:26 PM, Krzysztof Kozlowski wrote:
> On 23/04/2026 17:14, Shah, Tanmay wrote:
>> Hello,
>>
>> Thanks for reviews. Please see my comments below.
>>
>> On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote:
>>> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
>>>> Add auto-boot property to notify that remote processor is setup and
>>>> ready to boot. Linux can attempt to boot or attach to already running
>>>> remote processor. "firmware-name" property is used to mention default
>>>> firmware to boot when linux starts the remote processor.
>>>>
>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>> ---
>>>>  .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>>>>  1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> index ee63c03949c9..0d27260e3baa 100644
>>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> @@ -135,6 +135,14 @@ patternProperties:
>>>>            - description: vring1
>>>>          additionalItems: true
>>>>  
>>>> +      auto-boot:
>>>
>>> Last months, I have been asking AMD to follow writing-bindings doc or
>>> other DT guidelines way too many times.
>>>
>>> Or you just sent us downstream... Do you see anywhere such property?
>>> What properties do you see? How are they named?
>>>
>>
>> I should have put note about this. Current auto-boot properties are
>> named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific
>> there. Can we have a common auto-boot property? Similar to
>> firmware-name? If we agree to it then what's the correct location? New
>> file remoteproc.yaml is okay?
> 
> Common properties go to dtschema, so it would need to go there, but the
> point is that it's way too generic - every component with FW could be
> called "auto-boot". This should stay vendor property, IMO.
> 

Ack, I will rename it to xlnx,auto-boot.

>>
>>>> +        type: boolean
>>>> +        description: remote core is either already running or ready to boot
>>>
>>> And why is this property of a board?
>>>
>>
>> Not sure what indicates it is? The property is under remoteproc child
>> device that is SOC level property. Remote core is on same SOC wher linux
>> core is running.
> 
> So it is implied by SoC compatible? Please provide some arguments why it
> cannot be implied by the SoC compatible. I gave you one way out, but if
> you disagree then no problem.
> 

So on some SoC, the bootloader supports loading and starting of the
remote processor. But it is totally user's choice. User can choose to
load & start one core of a cluster via bootloader and leave another core
powered-off.
That is why it is not possible to decide based on SoC compatible.

If we don't want to make it a device-tree property then I can implement
in a different way. New way will detect if the remote is running or not
via EMMI/SCMI call to the firmware, and take a decision based on that.
If this new way works, then I don't think we need auto-boot property at all.

Let me know your thoughts.

>>
>>>> +
>>>> +      firmware-name:
>>>> +        maxItems: 1
>>>> +        description: default firmware to load
>>>
>>> Can you load non-default firmware later? IOW, why adding description
>>> here, what is special?
>>>
>>
>> The rootfs contains other firmware demos, and it is possible to stop the
>> default firmware, load other fw elf and re-run the remote core.
>> I don't have strong preference on the description part, I will remove it
>> if redundant.
> 
> No, it's fine, I wanted to be sure that such use case makes sense.
> 
> Best regards,
> Krzysztof

[PATCH 2/2] remoteproc: xlnx: enable auto boot feature

[Tanmay Shah]

remoteproc framework has capability to start (or attach to) the remote
processor automatically if auto boot flag is set by the driver during
probe. If remote core is not started before the Linux boot, and linux is
expected to start the remote core then it uses "firmware-name" property
to load default firmware during auto boot.

Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 49 +++++++++++++++++--------
 1 file changed, 34 insertions(+), 15 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 50a9974f3202..c6ec8186b160 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
 };
 
 /**
- * zynqmp_r5_add_rproc_core() - Add core data to framework.
- * Allocate and add struct rproc object for each r5f core
+ * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
+ * Allocate struct rproc object for each r5f core
  * This is called for each individual r5f core
  *
  * @cdev: Device node of each r5 core
  *
  * Return: zynqmp_r5_core object for success else error code pointer
  */
-static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
+static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
 {
 	struct zynqmp_r5_core *r5_core;
+	const char *fw_name = NULL;
 	struct rproc *r5_rproc;
 	int ret;
 
@@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
 	if (ret)
 		return ERR_PTR(ret);
 
+	ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
+	if (ret < 0 && ret != -EINVAL)
+		return ERR_PTR(dev_err_probe(cdev, ret,
+					     "failed to parse firmware-name\n"));
+
 	/* Allocate remoteproc instance */
 	r5_rproc = rproc_alloc(cdev, dev_name(cdev),
 			       &zynqmp_r5_rproc_ops,
-			       NULL, sizeof(struct zynqmp_r5_core));
+			       fw_name, sizeof(struct zynqmp_r5_core));
 	if (!r5_rproc) {
 		dev_err(cdev, "failed to allocate memory for rproc instance\n");
 		return ERR_PTR(-ENOMEM);
@@ -931,7 +937,7 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
 
 	r5_rproc->recovery_disabled = true;
 	r5_rproc->has_iommu = false;
-	r5_rproc->auto_boot = false;
+	r5_rproc->auto_boot = of_property_read_bool(dev_of_node(cdev), "auto-boot");
 	r5_core = r5_rproc->priv;
 	r5_core->dev = cdev;
 	r5_core->np = dev_of_node(cdev);
@@ -941,13 +947,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
 		goto free_rproc;
 	}
 
-	/* Add R5 remoteproc core */
-	ret = rproc_add(r5_rproc);
-	if (ret) {
-		dev_err(cdev, "failed to add r5 remoteproc\n");
-		goto free_rproc;
-	}
-
 	/*
 	 * If firmware is already available in the memory then move rproc state
 	 * to DETACHED. Firmware can be preloaded via debugger or by any other
@@ -958,6 +957,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
 	if (!zynqmp_r5_get_rsc_table_va(r5_core))
 		r5_rproc->state = RPROC_DETACHED;
 
+	dev_dbg(cdev, "auto boot %s, rproc state %s, fw-name = %s\n",
+		r5_rproc->auto_boot ? "enabled" : "disabled",
+		(r5_rproc->state == RPROC_DETACHED) ? "detached" : "offline",
+		!fw_name ? "NULL" : fw_name);
+
 	r5_core->rproc = r5_rproc;
 	return r5_core;
 
@@ -1278,7 +1282,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
 	enum rpu_oper_mode fw_reg_val;
 	struct device **child_devs;
 	enum rpu_tcm_comb tcm_mode;
-	int core_count, ret, i;
+	int core_count, ret, i, j;
 	struct mbox_info *ipi;
 
 	ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
@@ -1364,7 +1368,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
 		child_devs[i] = &child_pdev->dev;
 
 		/* create and add remoteproc instance of type struct rproc */
-		r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
+		r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
 		if (IS_ERR(r5_cores[i])) {
 			ret = PTR_ERR(r5_cores[i]);
 			r5_cores[i] = NULL;
@@ -1409,6 +1413,22 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
 		goto release_r5_cores;
 	}
 
+	for (j = 0; j < cluster->core_count; j++) {
+		/* Add R5 remoteproc core */
+		ret = rproc_add(r5_cores[j]->rproc);
+		if (ret) {
+			dev_err_probe(r5_cores[j]->dev, ret,
+				      "failed to add emoteproc\n");
+			i = core_count - 1;
+
+			/* delete previous added rproc */
+			while (--j >= 0)
+				rproc_del(r5_cores[j]->rproc);
+
+			goto release_r5_cores;
+		}
+	}
+
 	kfree(child_devs);
 	return 0;
 
@@ -1418,7 +1438,6 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
 		if (r5_cores[i]) {
 			zynqmp_r5_free_mbox(r5_cores[i]->ipi);
 			of_reserved_mem_device_release(r5_cores[i]->dev);
-			rproc_del(r5_cores[i]->rproc);
 			rproc_free(r5_cores[i]->rproc);
 		}
 		i--;
-- 
2.34.1