remoteproc: add AMD BRAM-based remote processor driver

PATCH Superseded Ben Levinsky 3 participants 12 messages Apr 27 – Apr 28

Subsystems (2)

Device tree bindings Remote processor (remoteproc)

lore

Share & tools

lore

Ben Levinsky

author

2026-04-27 16:27 UTC #0 lore raw

v2 cover remoteproc: add AMD BRAM-based remote processor driver

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

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 BRAM-based rproc
remoteproc: add AMD BRAM-based remote processor driver

 .../bindings/remoteproc/amd,bram-rproc.yaml   |  98 +++++++
 MAINTAINERS                                   |   7 +
 drivers/remoteproc/Kconfig                    |  14 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/amd_bram_rproc.c           | 243 ++++++++++++++++++
 5 files changed, 363 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
 create mode 100644 drivers/remoteproc/amd_bram_rproc.c

Signature · 1 line

2.34.1

Ben Levinsky

author

2026-04-27 16:27 UTC #1 lore raw

PATCH v2 1/2 dt-bindings: remoteproc: document AMD BRAM-based rproc

Describe an AMD BRAM-based soft-core processor subsystem instantiated in programmable logic and using dual-port BRAM for firmware storage and execution.

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.

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

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

Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +98 -0

new file mode 100644
index 000000000000..f16657dc0d9f
@@ -0,0 +1,98 @@
+# 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 BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
+
+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:
+    const: amd,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 = "amd,bram-rproc";
+      reg = <0x0 0x40000>;
+      clocks = <&pl_clk>;
+      firmware-name = "firmware.elf";
+      reset-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+    };
+...

Signature · 1 line

2.34.1

Krzysztof Kozlowski

2026-04-28 06:50 UTC #2 lore raw

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

Quoted 32 lines · Ben Levinsky

Describe an AMD BRAM-based soft-core processor subsystem instantiated in programmable logic and using dual-port BRAM for firmware storage and execution.
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.
Signed-off-by Ben Levinsky <[email protected]>
---
 .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +4 -0
new file mode 100644
index 000000000000..f16657dc0d9f
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#

Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml line 14

Quoted 10 lines

Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +10 -0

+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.

Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this completely different thing from SoC and there is a design WITHOUT SoC using this remote proc?

Best regards,
Krzysztof

Michal Simek

2026-04-28 08:33 UTC #3 lore raw

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

Quoted 39 lines · Krzysztof Kozlowski

Quoted 38 lines · Ben Levinsky
Describe an AMD BRAM-based soft-core processor subsystem instantiated in programmable logic and using dual-port BRAM for firmware storage and execution.
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.
Signed-off-by Ben Levinsky <[email protected]>
---
  .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
  1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +10 -0
new file mode 100644
index 000000000000..f16657dc0d9f
@@ -0,0 +1,98 @@
+# 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 BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>

Quoted 8 lines

Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml line 14
Quoted 4 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +4 -0
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this completely different thing from SoC and there is a design WITHOUT SoC using this remote proc?

In 99% case this is going to be used on Xilinx SOC with programmable logic next to ARM core.
soft core means - means VHDL/Verilog code synthesized to programmable logic/fpga. It means exact location in chip varies based on build and constraints.

hard core - physical HW location - like ARM cores in our chip.

(ARM is providing RTL/code that even ARM cores in fpga emulated platforms are actually used as soft cores).

Not sure if you want me to talk about that 1% use cases which are also possible but don't think anybody will design them.

Thanks,
Michal

Krzysztof Kozlowski

2026-04-28 08:47 UTC #4 lore raw

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

Quoted 56 lines · Michal Simek

Quoted 39 lines · Krzysztof Kozlowski
Quoted 38 lines · Ben Levinsky
Describe an AMD BRAM-based soft-core processor subsystem instantiated in programmable logic and using dual-port BRAM for firmware storage and execution.
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.
Signed-off-by Ben Levinsky <[email protected]>
---
  .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
  1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +10 -0
new file mode 100644
index 000000000000..f16657dc0d9f
@@ -0,0 +1,98 @@
+# 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 BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
Quoted 8 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml line 14
Quoted 4 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +4 -0
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this completely different thing from SoC and there is a design WITHOUT SoC using this remote proc?
In 99% case this is going to be used on Xilinx SOC with programmable logic next to ARM core.
soft core means - means VHDL/Verilog code synthesized to programmable logic/fpga. It means exact location in chip varies based on build and constraints.

Quoted 7 lines

hard core - physical HW location - like ARM cores in our chip.
(ARM is providing RTL/code that even ARM cores in fpga emulated platforms are actually used as soft cores).
Not sure if you want me to talk about that 1% use cases which are also possible but don't think anybody will design them.

Then I would treat it exactly like every other block of a SoC - you need a SoC specific compatible. If there is a fallback, SoC specific compatible should be used in the fallback as well - that's all already documented in writing-bindings.

If this is ever used standalone, outside of SoC, then maybe it will need its own wiring thus it will get its own compatible.

Best regards,
Krzysztof

Michal Simek

2026-04-28 09:11 UTC #5 lore raw

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

Quoted 62 lines · Krzysztof Kozlowski

Quoted 61 lines · Michal Simek
Quoted 39 lines · Krzysztof Kozlowski
Quoted 38 lines · Ben Levinsky
Describe an AMD BRAM-based soft-core processor subsystem instantiated in programmable logic and using dual-port BRAM for firmware storage and execution.
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.
Signed-off-by Ben Levinsky <[email protected]>
---
   .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
   1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +10 -0
new file mode 100644
index 000000000000..f16657dc0d9f
@@ -0,0 +1,98 @@
+# 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 BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
Quoted 8 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml line 14
Quoted 4 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +4 -0
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this completely different thing from SoC and there is a design WITHOUT SoC using this remote proc?
In 99% case this is going to be used on Xilinx SOC with programmable logic next to ARM core.
soft core means - means VHDL/Verilog code synthesized to programmable logic/fpga. It means exact location in chip varies based on build and constraints.
hard core - physical HW location - like ARM cores in our chip.
(ARM is providing RTL/code that even ARM cores in fpga emulated platforms are actually used as soft cores).

Quoted 7 lines

Quoted 2 lines
Not sure if you want me to talk about that 1% use cases which are also possible but don't think anybody will design them.
Then I would treat it exactly like every other block of a SoC - you need a SoC specific compatible. If there is a fallback, SoC specific compatible should be used in the fallback as well - that's all already documented in writing-bindings.

But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of these will use this configuration. Do you want to list all of them?

Thanks,
Michal

Krzysztof Kozlowski

2026-04-28 09:14 UTC #6 lore raw

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

Quoted 68 lines · Michal Simek

Quoted 65 lines · Krzysztof Kozlowski
Quoted 63 lines · Michal Simek
Quoted 39 lines · Krzysztof Kozlowski
Quoted 38 lines · Ben Levinsky
Describe an AMD BRAM-based soft-core processor subsystem instantiated in programmable logic and using dual-port BRAM for firmware storage and execution.
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.
Signed-off-by Ben Levinsky <[email protected]>
---
   .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
   1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +10 -0
new file mode 100644
index 000000000000..f16657dc0d9f
@@ -0,0 +1,98 @@
+# 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 BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
Quoted 8 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml line 14
Quoted 4 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +4 -0
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this completely different thing from SoC and there is a design WITHOUT SoC using this remote proc?
In 99% case this is going to be used on Xilinx SOC with programmable logic next to ARM core.
soft core means - means VHDL/Verilog code synthesized to programmable logic/fpga. It means exact location in chip varies based on build and constraints.
hard core - physical HW location - like ARM cores in our chip.
(ARM is providing RTL/code that even ARM cores in fpga emulated platforms are actually used as soft cores).
Not sure if you want me to talk about that 1% use cases which are also possible but don't think anybody will design them.

Quoted 8 lines

Quoted 4 lines
Then I would treat it exactly like every other block of a SoC - you need a SoC specific compatible. If there is a fallback, SoC specific compatible should be used in the fallback as well - that's all already documented in writing-bindings.
But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of these will use this configuration.
Do you want to list all of them?

"Then I would treat it exactly like every other block of a SoC"

Best regards,
Krzysztof

Michal Simek

2026-04-28 13:10 UTC #7 lore raw

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

Quoted 74 lines · Krzysztof Kozlowski

Quoted 73 lines · Michal Simek
Quoted 69 lines · Krzysztof Kozlowski
Quoted 56 lines · Michal Simek
Quoted 39 lines · Krzysztof Kozlowski
Quoted 38 lines · Ben Levinsky
Describe an AMD BRAM-based soft-core processor subsystem instantiated in programmable logic and using dual-port BRAM for firmware storage and execution.
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.
Signed-off-by Ben Levinsky <[email protected]>
---
    .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
    1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +10 -0
new file mode 100644
index 000000000000..f16657dc0d9f
@@ -0,0 +1,98 @@
+# 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 BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
Quoted 8 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml line 14
Quoted 4 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +4 -0
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this completely different thing from SoC and there is a design WITHOUT SoC using this remote proc?
In 99% case this is going to be used on Xilinx SOC with programmable logic next to ARM core.
soft core means - means VHDL/Verilog code synthesized to programmable logic/fpga. It means exact location in chip varies based on build and constraints.
Quoted 7 lines
hard core - physical HW location - like ARM cores in our chip.
(ARM is providing RTL/code that even ARM cores in fpga emulated platforms are actually used as soft cores).
Not sure if you want me to talk about that 1% use cases which are also possible but don't think anybody will design them.
Then I would treat it exactly like every other block of a SoC - you need a SoC specific compatible. If there is a fallback, SoC specific compatible should be used in the fallback as well - that's all already documented in writing-bindings.

Quoted 5 lines

Quoted 3 lines
But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of these will use this configuration.
Do you want to list all of them?
"Then I would treat it exactly like every other block of a SoC"

No issue. Here is snippet.

properties:
compatible:
items:
- enum:
- xlnx,zynqmp-bram-rproc
- xlnx,versal-bram-rproc
- xlnx,versal-net-bram-rproc
- amd,versal2-bram-rproc
- const: amd,bram-rproc

The example should also be updated:

  examples:
    - |
      #include <dt-bindings/gpio/gpio.h>
      remoteproc@0 {
        compatible = "xlnx,zynqmp-bram-rproc", "amd,bram-rproc";
        reg = <0x0 0x40000>;
        clocks = <&pl_clk>;
        firmware-name = "firmware.elf";
        reset-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
      };

Thanks,
Michal

Krzysztof Kozlowski

2026-04-28 13:12 UTC #8 lore raw

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

Quoted 95 lines · Michal Simek

Quoted 74 lines · Krzysztof Kozlowski
Quoted 73 lines · Michal Simek
Quoted 69 lines · Krzysztof Kozlowski
Quoted 56 lines · Michal Simek
Quoted 39 lines · Krzysztof Kozlowski
Quoted 38 lines · Ben Levinsky
Describe an AMD BRAM-based soft-core processor subsystem instantiated in programmable logic and using dual-port BRAM for firmware storage and execution.
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.
Signed-off-by Ben Levinsky <[email protected]>
---
    .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
    1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +10 -0
new file mode 100644
index 000000000000..f16657dc0d9f
@@ -0,0 +1,98 @@
+# 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 BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
Quoted 8 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml line 14
Quoted 4 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +4 -0
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this completely different thing from SoC and there is a design WITHOUT SoC using this remote proc?
In 99% case this is going to be used on Xilinx SOC with programmable logic next to ARM core.
soft core means - means VHDL/Verilog code synthesized to programmable logic/fpga. It means exact location in chip varies based on build and constraints.
Quoted 7 lines
hard core - physical HW location - like ARM cores in our chip.
(ARM is providing RTL/code that even ARM cores in fpga emulated platforms are actually used as soft cores).
Not sure if you want me to talk about that 1% use cases which are also possible but don't think anybody will design them.
Then I would treat it exactly like every other block of a SoC - you need a SoC specific compatible. If there is a fallback, SoC specific compatible should be used in the fallback as well - that's all already documented in writing-bindings.
Quoted 5 lines
Quoted 3 lines
But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of these will use this configuration.
Do you want to list all of them?
"Then I would treat it exactly like every other block of a SoC"
No issue. Here is snippet.
properties:
compatible:
items:
- enum:
- xlnx,zynqmp-bram-rproc
- xlnx,versal-bram-rproc
- xlnx,versal-net-bram-rproc
- amd,versal2-bram-rproc
- const: amd,bram-rproc

Quoted 1 line

The example should also be updated:

Yes, except what I wrote earlier and is mentioned in the writing bindings doc - the specific compatible should be also the fallback.

Best regards,
Krzysztof

Michal Simek

2026-04-28 13:18 UTC #9 lore raw

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

Quoted 96 lines · Krzysztof Kozlowski

Quoted 95 lines · Michal Simek
Quoted 74 lines · Krzysztof Kozlowski
Quoted 73 lines · Michal Simek
Quoted 69 lines · Krzysztof Kozlowski
Quoted 56 lines · Michal Simek
Quoted 39 lines · Krzysztof Kozlowski
Quoted 38 lines · Ben Levinsky
Describe an AMD BRAM-based soft-core processor subsystem instantiated in programmable logic and using dual-port BRAM for firmware storage and execution.
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.
Signed-off-by Ben Levinsky <[email protected]>
---
     .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
     1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +10 -0
new file mode 100644
index 000000000000..f16657dc0d9f
@@ -0,0 +1,98 @@
+# 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 BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <[email protected]>
Quoted 8 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml line 14
Quoted 4 lines
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +4 -0
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this completely different thing from SoC and there is a design WITHOUT SoC using this remote proc?
In 99% case this is going to be used on Xilinx SOC with programmable logic next to ARM core.
soft core means - means VHDL/Verilog code synthesized to programmable logic/fpga. It means exact location in chip varies based on build and constraints.
Quoted 7 lines
hard core - physical HW location - like ARM cores in our chip.
(ARM is providing RTL/code that even ARM cores in fpga emulated platforms are actually used as soft cores).
Not sure if you want me to talk about that 1% use cases which are also possible but don't think anybody will design them.
Then I would treat it exactly like every other block of a SoC - you need a SoC specific compatible. If there is a fallback, SoC specific compatible should be used in the fallback as well - that's all already documented in writing-bindings.
Quoted 5 lines
Quoted 3 lines
But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of these will use this configuration.
Do you want to list all of them?
"Then I would treat it exactly like every other block of a SoC"
No issue. Here is snippet.
properties:
compatible:
items:
- enum:
- xlnx,zynqmp-bram-rproc
- xlnx,versal-bram-rproc
- xlnx,versal-net-bram-rproc
- amd,versal2-bram-rproc
- const: amd,bram-rproc

Quoted 4 lines

Quoted 1 line
The example should also be updated:
Yes, except what I wrote earlier and is mentioned in the writing bindings doc - the specific compatible should be also the fallback.

properties:
compatible:
oneOf:
- const: xlnx,zynqmp-bram-rproc
- items:
- enum:
- xlnx,versal-bram-rproc
- xlnx,versal-net-bram-rproc
- amd,versal2-bram-rproc
- const: xlnx,zynqmp-bram-rproc

Good now?

Krzysztof Kozlowski

2026-04-28 13:28 UTC #10 lore raw

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

Quoted 27 lines · Michal Simek

Quoted 11 lines
Quoted 11 lines
properties:
compatible:
items:
- enum:
- xlnx,zynqmp-bram-rproc
- xlnx,versal-bram-rproc
- xlnx,versal-net-bram-rproc
- amd,versal2-bram-rproc
- const: amd,bram-rproc
Quoted 4 lines
Quoted 1 line
The example should also be updated:
Yes, except what I wrote earlier and is mentioned in the writing bindings doc - the specific compatible should be also the fallback.
properties:
compatible:
oneOf:
- const: xlnx,zynqmp-bram-rproc
- items:
- enum:
- xlnx,versal-bram-rproc
- xlnx,versal-net-bram-rproc
- amd,versal2-bram-rproc
- const: xlnx,zynqmp-bram-rproc

Quoted 1 line

Good now?

Yes, looks good to me!

Best regards,
Krzysztof

Ben Levinsky

author

2026-04-27 16:27 UTC #11 lore raw

PATCH v2 2/2 remoteproc: add AMD BRAM-based remote processor driver

In reply to Ben Levinsky

Add a remoteproc driver for AMD 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 the firmware image to be assigned later. Firmware images without a resource table are also accepted.

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

---
 MAINTAINERS                         |   7 +
 drivers/remoteproc/Kconfig          |  14 ++
 drivers/remoteproc/Makefile         |   1 +
 drivers/remoteproc/amd_bram_rproc.c | 243 ++++++++++++++++++++++++++++
 4 files changed, 265 insertions(+)
 create mode 100644 drivers/remoteproc/amd_bram_rproc.c

MAINTAINERS +7 -0

index c871acf2179c..172539971950 100644
@@ -1037,6 +1037,13 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/w1/amd,axi-1wire-host.yaml
 F:	drivers/w1/masters/amd_axi_w1.c
 
+AMD BRAM REMOTEPROC DRIVER
+M:	Ben Levinsky <[email protected]>
+L:	[email protected]
+S:	Maintained
+F:	Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
+F:	drivers/remoteproc/amd_bram_rproc.c
+
 AMD CDX BUS DRIVER
 M:	Nipun Gupta <[email protected]>
 M:	Nikhil Agarwal <[email protected]>

drivers/remoteproc/Kconfig +14 -0

index ee54436fea5a..9a2a887ede8a 100644
@@ -23,6 +23,20 @@ config REMOTEPROC_CDEV
 
 	  It's safe to say N if you don't want to use this interface.
 
+config AMD_BRAM_REMOTEPROC
+	tristate "AMD BRAM-based remoteproc support"
+	depends on OF && COMMON_CLK && (GPIOLIB || COMPILE_TEST)
+	help
+	  Say y or m here to support a BRAM-based remote processor managed
+	  through the remoteproc framework.
+
+	  This driver matches designs where executable firmware memory is
+	  described in the BRAM-local address space and translated to
+	  the system physical address space with standard devicetree address
+	  translation.
+
+	  If unsure, say N.
+
 config IMX_REMOTEPROC
 	tristate "i.MX remoteproc support"
 	depends on ARCH_MXC

drivers/remoteproc/Makefile +1 -0

index 1c7598b8475d..5c39664b50c3 100644
@@ -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_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

drivers/remoteproc/amd_bram_rproc.c new file +243 -0

243 lines not on this page · raw message

Signature · 1 line

2.34.1