remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver
Subsystems (2)
v5 cover remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver
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
Signature · 1 line
2.34.1
PATCH v5 1/2 dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc
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.
--- .../bindings/remoteproc/amd,bram-rproc.yaml | 105 ++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +105 -0
@@ -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 <[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: + 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>; + }; +...
Signature · 1 line
2.34.1
Re: [PATCH v5 1/2] dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc
Quoted 11 lines · 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.
Quoted 5 lines
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 <[email protected]>
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
Hi Krzysztof
Quoted 16 lines · Krzysztof Kozlowski
Quoted 15 lines · 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.
Quoted 9 lines
Quoted 1 line
Reviewed-by Krzysztof Kozlowski <[email protected]>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 <[email protected]>"
Sorry it was not exact tag from v3.
Re: [PATCH v5 1/2] dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc
In reply to Ben LevinskyHi 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
Quoted 133 lines · 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 <[email protected]>Signed-off-by Ben Levinsky <[email protected]>--- .../bindings/remoteproc/amd,bram-rproc.yaml | 105 ++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yamlDocumentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +105
-0@@ -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 <[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: + 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>; + }; +...
Mathieu Poirier
maintainerRe: [PATCH v5 1/2] dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc
Quoted 5 lines · 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.
Let me have a look before sending another revision.
Quoted 139 lines
Thank you
BenQuoted 133 lines · 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 <[email protected]>Signed-off-by Ben Levinsky <[email protected]>--- .../bindings/remoteproc/amd,bram-rproc.yaml | 105 ++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yamlDocumentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml new file +105
-0@@ -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 <[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: + 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
In reply to Ben LevinskyAdd 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.
--- 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
drivers/remoteproc/Kconfig +9 -0
@@ -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
drivers/remoteproc/Makefile +1 -0
@@ -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
drivers/remoteproc/amd_bram_rproc.c new file +213 -0
213 lines not on this page · raw message
Signature · 1 line
2.34.1
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] The driver references multiple non-existent functions (`rproc_mem_entry_ioremap_wc`…
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The driver references multiple non-existent functions (rproc_mem_entry_ioremap_wc, rproc_mem_entry_iounmap, and rproc_elf_load_rsc_table_optional) and illegally passes a variadic macro as an argument, causing a build failure. --
--- Patch [2]: [PATCH v5 2/2] remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver --- commit fa5c15f78fe1b684bd57e7c11e3674d5ed2661ce
Author: Ben Levinsky <[email protected]>
remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver
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.
Quoted 5 lines
drivers/remoteproc/amd_bram_rproc.c new file +0
-0
[ ... ]
Quoted 2 lines
drivers/remoteproc/amd_bram_rproc.c new file +2
-0+static int amd_bram_rproc_prepare (struct rproc *rproc) +{
[ ... ]
drivers/remoteproc/amd_bram_rproc.c line 75
Quoted 11 lines
drivers/remoteproc/amd_bram_rproc.c new file +11
-0+ 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));
[Severity: Low]
Do the callback functions rproc_mem_entry_ioremap_wc() and rproc_mem_entry_iounmap() exist in the tree? Passing undefined symbols here will cause build failures.
[ ... ]
drivers/remoteproc/amd_bram_rproc.c line 132
Quoted 7 lines
drivers/remoteproc/amd_bram_rproc.c new file +7
-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 ; +}
[Severity: Low]
Is rproc_elf_load_rsc_table_optional() defined in the kernel tree?
Additionally, because dev_dbg is a variadic macro, passing it as a function pointer argument will result in preprocessor errors. Should this use a different logging function or wrapper?
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Mathieu Poirier
maintainerQuoted 54 lines · 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 <[email protected]>--- 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.cdrivers/remoteproc/Kconfig +9
-0@@ -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_MXCdrivers/remoteproc/Makefile +0
-0
drivers/remoteproc/Makefile remoteproc-y += remoteproc_sysfs.o · line 14
Quoted 4 lines
drivers/remoteproc/Makefile +1
-0@@ -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
s/amd_bram_rproc.o/amd_mbv_bram_rproc.o
Thanks,
Mathieu
Quoted 225 lines
drivers/remoteproc/Makefile +0
-0obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o obj-$(CONFIG_IMX_DSP_REMOTEPROC) += imx_dsp_rproc.o obj-$(CONFIG_INGENIC_VPU_RPROC) += ingenic_rproc.odrivers/remoteproc/amd_bram_rproc.c new file +213
-0@@ -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 <[email protected]>" ); +MODULE_LICENSE ("GPL" );Signature · 1 line
2.34.1