[PATCH v5 0/2] remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver

[PATCH v5 0/2] remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver

[Ben Levinsky]

Add a MicroBlaze/V BRAM-based remoteproc driver and corresponding binding
for AMD soft processors located in programmable logic.

The series models a soft-core processor subsystem that executes firmware
from dual-port BRAM. The BRAM window is described in the processor-local
address space and translated to the Linux-visible system physical address
through the parent bus ranges property.

This series depends on the remoteproc cleanup series available here:

  https://lore.kernel.org/linux-remoteproc/ah2aVdlsLqy9aeHP@p14s/

That series adds the common WC ioremap carveout callbacks and optional
ELF resource-table helper used by patch 2.

v5:
  Patch 1, dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based
  rproc

  - Updated the binding title and patch wording to use MicroBlaze/V.
  - Added Reviewed-by from Krzysztof Kozlowski.

  Patch 2, remoteproc: add AMD MicroBlaze/V BRAM-based remote processor
  driver

  - Renamed the Kconfig symbol to AMD_MBV_BRAM_REMOTEPROC.
  - Updated the Kconfig prompt to use MicroBlaze/V.
  - Removed the reset GPIO and clock sentence from the Kconfig help text.
  - Updated the driver and module descriptions to use MicroBlaze/V.

v4:
  Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc

  - Sorted the SoC-specific compatible enum by name.

  Patch 2, remoteproc: add AMD BRAM-based remote processor driver

  - Dropped the driver-specific MAINTAINERS entry.
  - Trimmed the Kconfig help text.
  - Reused the common WC ioremap/iounmap carveout callbacks.
  - Reused the common optional ELF resource-table helper.
  - Used resource_size(&res) for the translated memory window size.
  - Kept the coredump segment address as the processor-local device
    address. The coredump path resolves segment addresses through
    rproc_da_to_va() against the registered carveout device address, while
    res.start is the Linux-visible system physical address after DT
    translation and may differ from the processor-local BRAM address.

v3:
  This version updates the binding to use SoC-specific compatibles with
  the fallback form discussed on the thread.

  Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc

  - Reworked the compatible schema to use SoC-specific compatibles.
  - Added amd,versal2-bram-rproc to the supported compatible list.
  - Used xlnx,zynqmp-bram-rproc as the fallback compatible.
  - Updated the example to match the new compatible scheme.

  Patch 2, remoteproc: add AMD BRAM-based remote processor driver

  - Updated the driver OF match table to bind via the
    xlnx,zynqmp-bram-rproc fallback compatible.

v2:
  This version pivots the series away from a MicroBlaze-specific binding
  and driver shape and instead models a BRAM-based soft-core processor
  subsystem more generally.

  This follows the upstream feedback that amd,microblaze was too tied to
  the processor architecture while also being too generic as a DT
  compatible for the hardware interface being described.

  Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc

  - Renamed the binding away from amd,microblaze and reframed it around a
    BRAM-based soft-core processor subsystem.
  - Dropped the redundant trailing "binding" wording from the patch
    subject.
  - Rewrote the binding text to describe the hardware rather than the Linux
    remoteproc framework.
  - Reworked the example to address the original dt_binding_check
    complaints about the root node and simple-pm-bus example shape.
  - Added a clocks property for the soft-core subsystem.

  Patch 2, remoteproc: add AMD BRAM-based remote processor driver

  - Renamed the driver away from the MicroBlaze-specific name to match the
    BRAM-based binding.
  - Added clock handling for the soft-core subsystem and the matching
    COMMON_CLK dependency in Kconfig.
  - Cleaned up the reset comments and removed the success dev_dbg() message
    called out in review.

Ben Levinsky (2):
  dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc
  remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver

 .../bindings/remoteproc/amd,bram-rproc.yaml   | 105 +++++++++
 drivers/remoteproc/Kconfig                    |   9 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/amd_bram_rproc.c           | 213 ++++++++++++++++++
 4 files changed, 328 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
 create mode 100644 drivers/remoteproc/amd_bram_rproc.c

-- 
2.34.1

[PATCH v5 1/2] dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc

[Ben Levinsky]

Describe an AMD MicroBlaze/V BRAM-based remote processor controlled
through the remoteproc framework.

The binding models a soft-core processor subsystem instantiated in AMD
programmable logic and using dual-port BRAM for firmware storage and
execution. The remoteproc device is represented as a child node whose
reg property describes the firmware memory window in the processor-local
address space. The parent bus node provides standard devicetree address
translation through ranges so Linux can access the same BRAM through the
system physical address space.

A clock input feeds the soft-core processor subsystem, and an active-low
reset GPIO holds the processor in reset until firmware loading completes.
The firmware-name property is optional.

Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
 .../bindings/remoteproc/amd,bram-rproc.yaml   | 105 ++++++++++++++++++
 1 file changed, 105 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
new file mode 100644
index 000000000000..c0359f447ea8
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD MicroBlaze/V BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <ben.levinsky@amd.com>
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
+
+  Hardware Architecture:
+
+    Host (PS)                        Programmable Logic (PL)
+    =========                        ======================
+
+    AXI Interface -----------------> AXI BRAM Controller (Host Port)
+                                             |
+                                             | Port A
+                                             v
+                                     +-----------------+
+                                     |  Dual-Port BRAM |
+                                     | (shared memory) |
+                                     +-----------------+
+                                             ^
+                                             | Port B
+                                             |
+                                     AXI BRAM Controller (Soft-core Port)
+                                             ^
+                                             | LMB
+                                             |
+                                     Soft-core CPU (MicroBlaze/V)
+
+    GPIO --------------------------> Proc Sys Reset ----> CPU Reset Signal
+
+    Clock -------------------------> Clock Distribution -> CPU Clock
+
+  Memory Architecture:
+
+    The dual-port BRAM allows simultaneous access from both processors:
+      - Port A: Connected to the host AXI BRAM controller for firmware loading
+      - Port B: Connected to the soft-core local memory bus for execution
+
+  The reg property describes the executable BRAM window in the processor-local
+  address space. The parent bus node translates that window to the system
+  physical address space by using standard devicetree address translation
+  through ranges. A clock input and a reset GPIO control the subsystem.
+
+properties:
+  compatible:
+    oneOf:
+      - const: xlnx,zynqmp-bram-rproc
+      - items:
+          - enum:
+              - amd,versal2-bram-rproc
+              - xlnx,versal-bram-rproc
+              - xlnx,versal-net-bram-rproc
+          - const: xlnx,zynqmp-bram-rproc
+
+  reg:
+    maxItems: 1
+    description:
+      Processor-local address and size of the BRAM firmware memory window,
+      as seen by the soft-core processor (typically 0x0 for reset vector).
+      The parent bus ranges property must translate this window to the
+      corresponding system physical address.
+
+  clocks:
+    maxItems: 1
+    description:
+      Clock input for the soft-core processor subsystem.
+
+  firmware-name:
+    maxItems: 1
+    description:
+      Name of the firmware ELF file to load.
+
+  reset-gpios:
+    maxItems: 1
+    description:
+      GPIO specifier controlling the soft-core reset input.
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - reset-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    remoteproc@0 {
+      compatible = "xlnx,zynqmp-bram-rproc";
+      reg = <0x0 0x40000>;
+      clocks = <&pl_clk>;
+      firmware-name = "firmware.elf";
+      reset-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+    };
+...
-- 
2.34.1

Re: [PATCH v5 1/2] dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc

[Krzysztof Kozlowski]

On Thu, Jul 09, 2026 at 07:57:11AM -0700, Ben Levinsky wrote:
> Describe an AMD MicroBlaze/V BRAM-based remote processor controlled
> through the remoteproc framework.
> 
> The binding models a soft-core processor subsystem instantiated in AMD
> programmable logic and using dual-port BRAM for firmware storage and
> execution. The remoteproc device is represented as a child node whose
> reg property describes the firmware memory window in the processor-local
> address space. The parent bus node provides standard devicetree address
> translation through ranges so Linux can access the same BRAM through the
> system physical address space.
> 
> A clock input feeds the soft-core processor subsystem, and an active-low
> reset GPIO holds the processor in reset until firmware loading completes.
> The firmware-name property is optional.
> 
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>

NAK.

You are not allowed to invent tags. You did not receive such tag.

Best regards,
Krzysztof

Re: [PATCH v5 1/2] dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc

[Ben Levinsky]

Hi Krzysztof

On 7/10/26 12:09 AM, Krzysztof Kozlowski wrote:
> On Thu, Jul 09, 2026 at 07:57:11AM -0700, Ben Levinsky wrote:
>> Describe an AMD MicroBlaze/V BRAM-based remote processor controlled
>> through the remoteproc framework.
>>
>> The binding models a soft-core processor subsystem instantiated in AMD
>> programmable logic and using dual-port BRAM for firmware storage and
>> execution. The remoteproc device is represented as a child node whose
>> reg property describes the firmware memory window in the processor-local
>> address space. The parent bus node provides standard devicetree address
>> translation through ranges so Linux can access the same BRAM through the
>> system physical address space.
>>
>> A clock input feeds the soft-core processor subsystem, and an active-low
>> reset GPIO holds the processor in reset until firmware loading completes.
>> The firmware-name property is optional.
>>
>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> 
> NAK.
> 
> You are not allowed to invent tags. You did not receive such tag.
> 
> Best regards,
> Krzysztof
> 
Sorry for the churn here - I can fix this instead to bring back the RB tag in the next as you put in review at end of the v3. "Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>"

Sorry it was not exact tag from v3. 

Re: [PATCH v5 1/2] dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc

[Ben Levinsky]

Hi Mathieu 

Though 2/2 got NAK, will you still review this ? 

If not I will bump rev and update patch 2/2.

Thank you
Ben

On 7/9/26 7:57 AM, Ben Levinsky wrote:
> Describe an AMD MicroBlaze/V BRAM-based remote processor controlled
> through the remoteproc framework.
> 
> The binding models a soft-core processor subsystem instantiated in AMD
> programmable logic and using dual-port BRAM for firmware storage and
> execution. The remoteproc device is represented as a child node whose
> reg property describes the firmware memory window in the processor-local
> address space. The parent bus node provides standard devicetree address
> translation through ranges so Linux can access the same BRAM through the
> system physical address space.
> 
> A clock input feeds the soft-core processor subsystem, and an active-low
> reset GPIO holds the processor in reset until firmware loading completes.
> The firmware-name property is optional.
> 
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
> ---
>  .../bindings/remoteproc/amd,bram-rproc.yaml   | 105 ++++++++++++++++++
>  1 file changed, 105 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
> new file mode 100644
> index 000000000000..c0359f447ea8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AMD MicroBlaze/V BRAM-based Remote Processor
> +
> +maintainers:
> +  - Ben Levinsky <ben.levinsky@amd.com>
> +
> +description: |
> +  Soft-core processor subsystem instantiated in AMD programmable logic and
> +  using dual-port BRAM for firmware storage and execution.
> +
> +  Hardware Architecture:
> +
> +    Host (PS)                        Programmable Logic (PL)
> +    =========                        ======================
> +
> +    AXI Interface -----------------> AXI BRAM Controller (Host Port)
> +                                             |
> +                                             | Port A
> +                                             v
> +                                     +-----------------+
> +                                     |  Dual-Port BRAM |
> +                                     | (shared memory) |
> +                                     +-----------------+
> +                                             ^
> +                                             | Port B
> +                                             |
> +                                     AXI BRAM Controller (Soft-core Port)
> +                                             ^
> +                                             | LMB
> +                                             |
> +                                     Soft-core CPU (MicroBlaze/V)
> +
> +    GPIO --------------------------> Proc Sys Reset ----> CPU Reset Signal
> +
> +    Clock -------------------------> Clock Distribution -> CPU Clock
> +
> +  Memory Architecture:
> +
> +    The dual-port BRAM allows simultaneous access from both processors:
> +      - Port A: Connected to the host AXI BRAM controller for firmware loading
> +      - Port B: Connected to the soft-core local memory bus for execution
> +
> +  The reg property describes the executable BRAM window in the processor-local
> +  address space. The parent bus node translates that window to the system
> +  physical address space by using standard devicetree address translation
> +  through ranges. A clock input and a reset GPIO control the subsystem.
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - const: xlnx,zynqmp-bram-rproc
> +      - items:
> +          - enum:
> +              - amd,versal2-bram-rproc
> +              - xlnx,versal-bram-rproc
> +              - xlnx,versal-net-bram-rproc
> +          - const: xlnx,zynqmp-bram-rproc
> +
> +  reg:
> +    maxItems: 1
> +    description:
> +      Processor-local address and size of the BRAM firmware memory window,
> +      as seen by the soft-core processor (typically 0x0 for reset vector).
> +      The parent bus ranges property must translate this window to the
> +      corresponding system physical address.
> +
> +  clocks:
> +    maxItems: 1
> +    description:
> +      Clock input for the soft-core processor subsystem.
> +
> +  firmware-name:
> +    maxItems: 1
> +    description:
> +      Name of the firmware ELF file to load.
> +
> +  reset-gpios:
> +    maxItems: 1
> +    description:
> +      GPIO specifier controlling the soft-core reset input.
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +    remoteproc@0 {
> +      compatible = "xlnx,zynqmp-bram-rproc";
> +      reg = <0x0 0x40000>;
> +      clocks = <&pl_clk>;
> +      firmware-name = "firmware.elf";
> +      reset-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
> +    };
> +...

[PATCH v5 2/2] remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver

[Ben Levinsky]

Add a remoteproc driver for AMD MicroBlaze/V soft-core processor
subsystems instantiated in programmable logic and using dual-port BRAM
for firmware storage and execution.

The driver parses the firmware memory window from the remoteproc device
node's reg property, interprets that address and size in the
processor-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 processor is controlled through an active-low reset GPIO and a
subsystem clock. The clock is enabled before reset is released, and the
processor is kept in reset until firmware loading completes.

The firmware-name property is optional, allowing firmware to be assigned
later through the remoteproc framework. Firmware images without a
resource table are also accepted.

Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
 drivers/remoteproc/Kconfig          |   9 ++
 drivers/remoteproc/Makefile         |   1 +
 drivers/remoteproc/amd_bram_rproc.c | 213 ++++++++++++++++++++++++++++
 3 files changed, 223 insertions(+)
 create mode 100644 drivers/remoteproc/amd_bram_rproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c521c744e7db..b25252acbfb9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -23,6 +23,15 @@ config REMOTEPROC_CDEV
 
 	  It's safe to say N if you don't want to use this interface.
 
+config AMD_MBV_BRAM_REMOTEPROC
+	tristate "AMD MicroBlaze/V BRAM-based remoteproc support"
+	depends on OF && COMMON_CLK && (GPIOLIB || COMPILE_TEST)
+	help
+	  Say y or m here to support a MicroBlaze/V BRAM-based remote
+	  processor managed through the remoteproc framework.
+
+	  If unsure, say N.
+
 config IMX_REMOTEPROC
 	tristate "i.MX remoteproc support"
 	depends on ARCH_MXC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 1c7598b8475d..9af895fff06e 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,6 +11,7 @@ remoteproc-y				+= remoteproc_sysfs.o
 remoteproc-y				+= remoteproc_virtio.o
 remoteproc-y				+= remoteproc_elf_loader.o
 obj-$(CONFIG_REMOTEPROC_CDEV)		+= remoteproc_cdev.o
+obj-$(CONFIG_AMD_MBV_BRAM_REMOTEPROC)	+= amd_bram_rproc.o
 obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
 obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
diff --git a/drivers/remoteproc/amd_bram_rproc.c b/drivers/remoteproc/amd_bram_rproc.c
new file mode 100644
index 000000000000..e4a103cf8455
--- /dev/null
+++ b/drivers/remoteproc/amd_bram_rproc.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD MicroBlaze/V BRAM-based Remote Processor driver
+ *
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ *
+ * This driver supports soft-core processors (MicroBlaze, MicroBlaze-V, or
+ * similar) instantiated in AMD programmable logic, using dual-port BRAM
+ * for firmware storage and execution.
+ *
+ * The firmware memory (BRAM) is described in the processor-local address
+ * space and translated to the Linux-visible system physical address with
+ * standard devicetree address translation.
+ *
+ * Reset is controlled via GPIO connected to Processor System Reset IP.
+ */
+
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+
+#include "remoteproc_internal.h"
+
+/**
+ * struct amd_bram_rproc - AMD MicroBlaze/V BRAM-based remoteproc private data
+ * @dev: device pointer
+ * @reset: GPIO descriptor for reset control (active-low)
+ * @clk: processor clock
+ */
+struct amd_bram_rproc {
+	struct device *dev;
+	struct gpio_desc *reset;
+	struct clk *clk;
+};
+
+static int amd_bram_rproc_prepare(struct rproc *rproc)
+{
+	struct amd_bram_rproc *priv = rproc->priv;
+	struct rproc_mem_entry *mem;
+	struct resource res;
+	u64 da, size;
+	int ret;
+
+	ret = of_property_read_reg(priv->dev->of_node, 0, &da, &size);
+	if (ret) {
+		dev_err(priv->dev, "failed to parse executable memory reg\n");
+		return ret;
+	}
+
+	if (!size || size > U32_MAX) {
+		dev_err(priv->dev, "invalid executable memory size\n");
+		return -EINVAL;
+	}
+
+	if (da > U32_MAX) {
+		dev_err(priv->dev, "invalid executable memory address\n");
+		return -EINVAL;
+	}
+
+	ret = of_address_to_resource(priv->dev->of_node, 0, &res);
+	if (ret) {
+		dev_err(priv->dev, "failed to translate executable memory reg\n");
+		return ret;
+	}
+
+	mem = rproc_mem_entry_init(priv->dev, NULL, (dma_addr_t)res.start,
+				   resource_size(&res), da,
+				   rproc_mem_entry_ioremap_wc,
+				   rproc_mem_entry_iounmap,
+				   dev_name(priv->dev));
+	if (!mem)
+		return -ENOMEM;
+
+	rproc_add_carveout(rproc, mem);
+	rproc_coredump_add_segment(rproc, da, resource_size(&res));
+
+	return 0;
+}
+
+static int amd_bram_rproc_start(struct rproc *rproc)
+{
+	struct amd_bram_rproc *priv = rproc->priv;
+	int ret;
+
+	/* Enable clock before releasing reset */
+	ret = clk_prepare_enable(priv->clk);
+	if (ret) {
+		dev_err(priv->dev, "failed to enable clock: %d\n", ret);
+		return ret;
+	}
+
+	/* Deassert reset and let the processor run. */
+	ret = gpiod_set_value_cansleep(priv->reset, 0);
+	if (ret) {
+		dev_err(priv->dev, "failed to deassert reset: %d\n", ret);
+		clk_disable_unprepare(priv->clk);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int amd_bram_rproc_stop(struct rproc *rproc)
+{
+	struct amd_bram_rproc *priv = rproc->priv;
+	int ret;
+
+	/* Assert reset before disabling the processor clock. */
+	ret = gpiod_set_value_cansleep(priv->reset, 1);
+	if (ret) {
+		dev_err(priv->dev, "failed to assert reset: %d\n", ret);
+		return ret;
+	}
+
+	/* Disable clock after asserting reset */
+	clk_disable_unprepare(priv->clk);
+
+	return 0;
+}
+
+static int amd_bram_rproc_parse_fw(struct rproc *rproc,
+				   const struct firmware *fw)
+{
+	rproc_elf_load_rsc_table_optional(rproc, fw, dev_dbg,
+					  "no resource table found\n");
+	return 0;
+}
+
+static const struct rproc_ops amd_bram_rproc_ops = {
+	.prepare	= amd_bram_rproc_prepare,
+	.start		= amd_bram_rproc_start,
+	.stop		= amd_bram_rproc_stop,
+	.load		= rproc_elf_load_segments,
+	.sanity_check	= rproc_elf_sanity_check,
+	.get_boot_addr	= rproc_elf_get_boot_addr,
+	.parse_fw	= amd_bram_rproc_parse_fw,
+};
+
+static int amd_bram_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct amd_bram_rproc *priv;
+	const char *fw_name = NULL;
+	struct rproc *rproc;
+	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), &amd_bram_rproc_ops,
+				 fw_name, sizeof(*priv));
+	if (!rproc)
+		return -ENOMEM;
+
+	priv = rproc->priv;
+	priv->dev = dev;
+
+	/* Get the processor clock */
+	priv->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(priv->clk))
+		return dev_err_probe(dev, PTR_ERR(priv->clk),
+				     "failed to get clock\n");
+
+	/*
+	 * Keep the processor in reset until remoteproc has finished loading
+	 * firmware into the executable memory window described by reg and
+	 * translated through the parent bus ranges property.
+	 */
+	priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(priv->reset))
+		return dev_err_probe(dev, PTR_ERR(priv->reset),
+				     "failed to get reset gpio\n");
+
+	rproc->auto_boot = false;
+
+	ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to set DMA mask\n");
+
+	platform_set_drvdata(pdev, rproc);
+
+	ret = devm_rproc_add(dev, rproc);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to register rproc\n");
+
+	return 0;
+}
+
+static const struct of_device_id amd_bram_rproc_of_match[] = {
+	{ .compatible = "xlnx,zynqmp-bram-rproc" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, amd_bram_rproc_of_match);
+
+static struct platform_driver amd_bram_rproc_driver = {
+	.probe = amd_bram_rproc_probe,
+	.driver = {
+		.name = "amd-bram-rproc",
+		.of_match_table = amd_bram_rproc_of_match,
+	},
+};
+module_platform_driver(amd_bram_rproc_driver);
+
+MODULE_DESCRIPTION("AMD MicroBlaze/V BRAM-based Remote Processor driver");
+MODULE_AUTHOR("Ben Levinsky <ben.levinsky@amd.com>");
+MODULE_LICENSE("GPL");
-- 
2.34.1