Add a MicroBlaze remoteproc driver and binding

Describe an AMD MicroBlaze remote processor controlled through the remoteproc framework.

The binding models the MicroBlaze remoteproc device as a child node whose reg property describes the executable firmware memory window in the MicroBlaze-local address space. The parent bus node provides standard devicetree address translation through ranges so Linux can access the same memory through the system physical address space.

An active-low reset GPIO holds the MicroBlaze in reset until firmware loading completes.

Signed-off-by Ben Levinsky <[email protected]>

---
 .../bindings/remoteproc/amd,microblaze.yaml   | 67 +++++++++++++++++++
 1 file changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +24 -0

+
+  reg:
+    maxItems: 1
+    description:
+      MicroBlaze-local address and size of the executable firmware memory
+      window.
+
+  firmware-name:
+    maxItems: 1
+
+  reset-gpios:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - reset-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+

On 14/04/2026 18:15, Ben Levinsky wrote:

A nit, subject: drop second/last, redundant "binding". The "dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 14

Quoted 12 lines

+---
+$id: http://devicetree.org/schemas/remoteproc/amd,microblaze.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +9 -0

+
+title: AMD MicroBlaze remote processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
+
+description:
+  MicroBlaze remote processor controlled by Linux through the remoteproc
+  framework.

Describe hardware, not Linux frameworks. IOW, Linux framework is here irrelevant.

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 26

Quoted 12 lines

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +12 -0

+
+  The executable firmware memory window is described in the
+  MicroBlaze-local address space by the node's reg property and translated
+  to the system physical address space with standard devicetree address
+  translation provided by the parent bus node's ranges property.
+
+properties:
+  $nodename:
+    pattern: "^remoteproc@[0-9a-f]+$"
+
+  compatible:
+    const: amd,microblaze

microblaze is architecture, so this feels way too generic. You need SoC specific compatibles and I suggest do not reference architecture, but name or the function of the processor, if there are such.

Quoted 23 lines · Krzysztof Kozlowski

On 14/04/2026 18:15, Ben Levinsky wrote:

A nit, subject: drop second/last, redundant "binding". The "dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 14

Quoted 12 lines

+---
+$id: http://devicetree.org/schemas/remoteproc/amd,microblaze.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +9 -0

+
+title: AMD MicroBlaze remote processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
+
+description:
+  MicroBlaze remote processor controlled by Linux through the remoteproc
+  framework.

Describe hardware, not Linux frameworks. IOW, Linux framework is here irrelevant.

Quoted 16 lines

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 26

Quoted 12 lines

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +12 -0

+
+  The executable firmware memory window is described in the
+  MicroBlaze-local address space by the node's reg property and translated
+  to the system physical address space with standard devicetree address
+  translation provided by the parent bus node's ranges property.
+
+properties:
+  $nodename:
+    pattern: "^remoteproc@[0-9a-f]+$"
+
+  compatible:
+    const: amd,microblaze

microblaze is architecture, so this feels way too generic. You need SoC specific compatibles and I suggest do not reference architecture, but name or the function of the processor, if there are such.

I have been arguing internally that I think when you look at driver itself it can be pretty much generic loader for any firmware and doesn't really matter if

target subsystem is Microblaze/Risc-V/whatever based. And I was suggesting them to use more generic name.

Because at the end of day reg property is pointing to location where firmware should be loaded and gpio is a way how to start that subsystem and there is nothing Microblaze specific.

I can also imagine that the same driver could be extended with optional power domain, power regulator and clock properties if there is a need to drive them before subsystem gets out of reset.

Does it make sense?

Quoted 43 lines · Michal Simek

Quoted 39 lines · Krzysztof Kozlowski

On 14/04/2026 18:15, Ben Levinsky wrote:

A nit, subject: drop second/last, redundant "binding". The "dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 14

Quoted 12 lines

+---
+$id: http://devicetree.org/schemas/remoteproc/amd,microblaze.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +9 -0

+
+title: AMD MicroBlaze remote processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
+
+description:
+  MicroBlaze remote processor controlled by Linux through the remoteproc
+  framework.

Describe hardware, not Linux frameworks. IOW, Linux framework is here irrelevant.

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 26

Quoted 12 lines

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +12 -0

+
+  The executable firmware memory window is described in the
+  MicroBlaze-local address space by the node's reg property and translated
+  to the system physical address space with standard devicetree address
+  translation provided by the parent bus node's ranges property.
+
+properties:
+  $nodename:
+    pattern: "^remoteproc@[0-9a-f]+$"
+
+  compatible:
+    const: amd,microblaze

microblaze is architecture, so this feels way too generic. You need SoC specific compatibles and I suggest do not reference architecture, but name or the function of the processor, if there are such.

Quoted 2 lines

I have been arguing internally that I think when you look at driver itself it can be pretty much generic loader for any firmware and doesn't really matter if

Luckily I don't speak about driver :)

Quoted 3 lines

target subsystem is Microblaze/Risc-V/whatever based. And I was suggesting them to use more generic name.

So the binding is for drivers - generic loader? Then simply no. Not suitable for DT.

Quoted 5 lines

Because at the end of day reg property is pointing to location where firmware should be loaded and gpio is a way how to start that subsystem and there is nothing Microblaze specific.

Quoted 5 lines

I can also imagine that the same driver could be extended with optional power domain, power regulator and clock properties if there is a need to drive them before subsystem gets out of reset.

Does it make sense?

Yes, drop from DT. No need for generic stuff. Or describe the hardware.

Quoted 4 lines

Quoted 2 lines

Does it make sense?

Yes, drop from DT. No need for generic stuff. Or describe the hardware.

You need to describe that connection to HW. GPIOs, memory location, etc. It means there must be any description.

Quoted 7 lines · Michal Simek

Quoted 4 lines

Quoted 2 lines

Does it make sense?

Yes, drop from DT. No need for generic stuff. Or describe the hardware.

You need to describe that connection to HW. GPIOs, memory location, etc. It means there must be any description.

No, you can write user-space driver or pass everything through SW nodes. No need for DT description.

But if you want a DT description, then it must be for the specific hardware, since the hardware is not generic.

Quoted 11 lines · Krzysztof Kozlowski

Quoted 7 lines · Michal Simek

Quoted 4 lines

Quoted 2 lines

Does it make sense?

Yes, drop from DT. No need for generic stuff. Or describe the hardware.

You need to describe that connection to HW. GPIOs, memory location, etc. It means there must be any description.

No, you can write user-space driver or pass everything through SW nodes. No need for DT description.

The firmware memory typically sits behind AXI-to-AXI bridges and

interconnect switches. The bus topology varies between FPGA designs.

DT ranges-based address translation is the standard way to describe

this, and pushing it into userspace would just mean hardcoding what

ranges already provides.

I don't think SW nodes should be used here.

Quoted 3 lines

But if you want a DT description, then it must be for the specific hardware, since the hardware is not generic.

But there is specific HW loaded. It is loaded at power up and don't change over life cycle. What I am just saying that access to this fixed HW (in fpga) is generic. At this stage memory and gpio only.

What I was trying to say is that the hardware topology (memory window +

reset GPIO) is the same regardless of the soft-core cpu (MicroBlaze, RISC-V, etc.)/fpga, so naming it after the ISA architecture felt wrong to me

too.

When I look at other bindings. For example this one. Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml

the compatible describes the communication mechanism (FIFO-based G-Link), not the specific processor behind it.

Our case is similar the compatible describes the control mechanism firmware loaded through a memory window, processor started via GPIO reset. What sits behind that interface varies and is opaque to the binding.

Would something like "amd,mem-gpio-rproc" be acceptable, following the same pattern where the compatible identifies the interface mechanism?

Quoted 37 lines · Michal Simek

Quoted 11 lines · Krzysztof Kozlowski

Quoted 7 lines · Michal Simek

Quoted 4 lines

Quoted 2 lines

Does it make sense?

Yes, drop from DT. No need for generic stuff. Or describe the hardware.

You need to describe that connection to HW. GPIOs, memory location, etc. It means there must be any description.

No, you can write user-space driver or pass everything through SW nodes. No need for DT description.

The firmware memory typically sits behind AXI-to-AXI bridges and

interconnect switches. The bus topology varies between FPGA designs.

DT ranges-based address translation is the standard way to describe

this, and pushing it into userspace would just mean hardcoding what

ranges already provides.

I don't think SW nodes should be used here.

Quoted 3 lines

But if you want a DT description, then it must be for the specific hardware, since the hardware is not generic.

But there is specific HW loaded. It is loaded at power up and don't change over life cycle. What I am just saying that access to this fixed HW (in fpga) is generic. At this stage memory and gpio only.

What I was trying to say is that the hardware topology (memory window +

Quoted 7 lines

reset GPIO) is the same regardless of the soft-core cpu (MicroBlaze, RISC-V, etc.)/fpga, so naming it after the ISA architecture felt wrong to me

too.

When I look at other bindings. For example this one. Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml

That's a subnode of other device. Not an independent device.

Plus I dislike most of Qualcomm remoteproc bindings and find them way to downstreamish, written to match downstream approaches without respecting DT rules.

Quoted 11 lines

the compatible describes the communication mechanism (FIFO-based G-Link), not the specific processor behind it.

Our case is similar the compatible describes the control mechanism firmware loaded through a memory window, processor started via GPIO reset. What sits behind that interface varies and is opaque to the binding.

Quoted 2 lines

Would something like "amd,mem-gpio-rproc" be acceptable, following the same pattern where the compatible identifies the interface mechanism?

Not for me. You have a very specific physical remote processor. That's what you write bindings for.

Quoted 23 lines · Krzysztof Kozlowski

On 14/04/2026 18:15, Ben Levinsky wrote:

A nit, subject: drop second/last, redundant "binding". The "dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 14

Quoted 12 lines

+---
+$id: http://devicetree.org/schemas/remoteproc/amd,microblaze.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +9 -0

+
+title: AMD MicroBlaze remote processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
+
+description:
+  MicroBlaze remote processor controlled by Linux through the remoteproc
+  framework.

Describe hardware, not Linux frameworks. IOW, Linux framework is here irrelevant.

Quoted 16 lines

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 26

Quoted 12 lines

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +12 -0

+
+  The executable firmware memory window is described in the
+  MicroBlaze-local address space by the node's reg property and translated
+  to the system physical address space with standard devicetree address
+  translation provided by the parent bus node's ranges property.
+
+properties:
+  $nodename:
+    pattern: "^remoteproc@[0-9a-f]+$"
+
+  compatible:
+    const: amd,microblaze

microblaze is architecture, so this feels way too generic. You need SoC specific compatibles and I suggest do not reference architecture, but name or the function of the processor, if there are such.

I have been arguing internally that I think when you look at driver itself it can be pretty much generic loader for any firmware and doesn't really matter if target subsystem is Microblaze/Risc-V/whatever based. And I was suggesting them to use more generic name.

Because at the end of day reg property is pointing to location where firmware should be loaded and gpio is a way how to start that subsystem and there is nothing Microblaze specific.

I can also imagine that the same driver could be extended with optional power domain, power regulator and clock properties if there is a need to drive them before subsystem gets out of reset.

Quoted 44 lines · Michal Simek

Quoted 23 lines · Krzysztof Kozlowski

On 14/04/2026 18:15, Ben Levinsky wrote:

A nit, subject: drop second/last, redundant "binding". The "dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 14

Quoted 12 lines

+---
+$id: http://devicetree.org/schemas/remoteproc/amd,microblaze.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +9 -0

+
+title: AMD MicroBlaze remote processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
+
+description:
+  MicroBlaze remote processor controlled by Linux through the remoteproc
+  framework.

Describe hardware, not Linux frameworks. IOW, Linux framework is here irrelevant.

Quoted 16 lines

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml line 26

Quoted 12 lines

Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml new file +12 -0

+
+  The executable firmware memory window is described in the
+  MicroBlaze-local address space by the node's reg property and translated
+  to the system physical address space with standard devicetree address
+  translation provided by the parent bus node's ranges property.
+
+properties:
+  $nodename:
+    pattern: "^remoteproc@[0-9a-f]+$"
+
+  compatible:
+    const: amd,microblaze

microblaze is architecture, so this feels way too generic. You need SoC specific compatibles and I suggest do not reference architecture, but name or the function of the processor, if there are such.

Quoted 4 lines

I have been arguing internally that I think when you look at driver itself it can be pretty much generic loader for any firmware and doesn't really matter if target subsystem is Microblaze/Risc-V/whatever based. And I was suggesting them to use more generic name.

Generic to AMD though, not everyone, right?

I agree it probably doesn't matter what the processor arch is. The compatible just needs to be specific enough when there's some quirk/feature in the interface to the operating system, that we can distinguish the specific implementation *without* a DT update.

Quoted 5 lines

Because at the end of day reg property is pointing to location where firmware should be loaded and gpio is a way how to start that subsystem and there is nothing Microblaze specific.

Quoted 3 lines

I can also imagine that the same driver could be extended with optional power domain, power regulator and clock properties if there is a need to drive them before subsystem gets out of reset.

That never works because then there's timing/ordering constraints for enabling/disabling all those resources. Then we end up with a never ending stream of properties added which results in a poorly designed binding.

Add an AMD MicroBlaze remoteproc driver.

The driver parses the executable firmware memory window from the remoteproc device node's reg property, interprets that address and size in the MicroBlaze-local address space, and then uses standard devicetree address translation through the parent bus ranges property to obtain the corresponding Linux-visible system physical address.

The resulting translated region is registered as the executable remoteproc carveout and coredump segment.

The MicroBlaze is controlled through an active-low reset GPIO and kept in reset until firmware loading completes.

The firmware-name property is optional, allowing firmware to be assigned later through the remoteproc framework.

drivers/remoteproc/amd_microblaze_rproc.c new file +72 -0

+	gpiod_set_value_cansleep(mb->reset, 0);
+
+	return 0;
+}
+
+static int mb_rproc_stop(struct rproc *rproc)
+{
+	struct mb_rproc *mb = rproc->priv;
+
+	/* reset-gpios is declared active-low, so logical 1 asserts reset */
+	gpiod_set_value_cansleep(mb->reset, 1);
+
+	return 0;
+}
+
+static int mb_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+	int ret;
+
+	ret = rproc_elf_load_rsc_table(rproc, fw);
+	if (ret == -EINVAL) {
+		dev_dbg(&rproc->dev, "no resource table found\n");
+		return 0;
+	}
+
+	return ret;
+}
+
+static const struct rproc_ops mb_rproc_ops = {
+	.prepare	= mb_rproc_prepare,
+	.start		= mb_rproc_start,
+	.stop		= mb_rproc_stop,
+	.load		= rproc_elf_load_segments,
+	.sanity_check	= rproc_elf_sanity_check,
+	.get_boot_addr	= rproc_elf_get_boot_addr,
+	.parse_fw	= mb_rproc_parse_fw,
+};
+
+static int mb_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mb_rproc *mb;
+	struct rproc *rproc;
+	const char *fw_name = NULL;
+	int ret;
+
+	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
+	if (ret < 0 && ret != -EINVAL)
+		return dev_err_probe(dev, ret,
+				     "failed to parse firmware-name property\n");
+
+	rproc = devm_rproc_alloc(dev, dev_name(dev), &mb_rproc_ops, fw_name,
+				 sizeof(*mb));
+	if (!rproc)
+		return -ENOMEM;
+
+	mb = rproc->priv;
+	mb->dev = dev;
+
+	/*
+	 * Keep the MicroBlaze in reset until remoteproc has finished loading
+	 * firmware into the executable memory window described by reg and
+	 * translated through the parent bus ranges property.
+	 */
+	mb->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(mb->reset))
+		return dev_err_probe(dev, PTR_ERR(mb->reset),
+				     "failed to get reset gpio\n");
+
+	rproc->auto_boot = false;
+
+	ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));