remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver
Subsystems (2)
v6 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.
v6:
Patch 1, dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc
- Corrected Krzysztof Kozlowski's Reviewed-by trailer to match the tag provided during the v3 review.
Patch 2, remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver
- Renamed the driver source and object from amd_bram_rproc to amd_mbv_bram_rproc.
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_mbv_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_mbv_bram_rproc.c
Signature · 1 line
2.34.1
PATCH v6 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
PATCH v6 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_mbv_bram_rproc.c | 213 ++++++++++++++++++++++++ 3 files changed, 223 insertions(+) create mode 100644 drivers/remoteproc/amd_mbv_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_mbv_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_mbv_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 3 potential issue(s) to consider: - [Medium] Format string vulnerability due to passing `dev_name(priv->dev)` directly as a format string to…
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Format string vulnerability due to passing dev_name(priv->dev) directly as a format string to rproc_mem_entry_init.
- [Medium] Clock enable count and remoteproc resource leak on the error path in amd_bram_rproc_stop().
- [Low] The driver references undefined functions (rproc_mem_entry_ioremap_wc, rproc_mem_entry_iounmap, and rproc_elf_load_rsc_table_optional), leading to immediate compilation failures. --
--- Patch [2]: [PATCH v6 2/2] remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver --- commit 86b0a2cc7621606c7e9542f2f1f85e8f3f1d960a
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_mbv_bram_rproc.c new file +0
-0
[ ... ]
Quoted 3 lines
drivers/remoteproc/amd_mbv_bram_rproc.c new file +3
-0+static int amd_bram_rproc_prepare (struct rproc *rproc) +{ +struct amd_bram_rproc *priv = rproc->priv;
[ ... ]
drivers/remoteproc/amd_mbv_bram_rproc.c line 74
Quoted 4 lines
drivers/remoteproc/amd_mbv_bram_rproc.c new file +4
-0+ 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,
[Severity: Low]
Are rproc_mem_entry_ioremap_wc and rproc_mem_entry_iounmap declared?
It looks like referencing these undefined functions causes a compilation failure when building with CONFIG_AMD_MBV_BRAM_REMOTEPROC.
drivers/remoteproc/amd_mbv_bram_rproc.c line 75
Quoted 1 line
drivers/remoteproc/amd_mbv_bram_rproc.c new file +1
-0+ dev_name(priv->dev));
[Severity: Medium]
Could this lead to a format string vulnerability?
rproc_mem_entry_init() is a variadic function that uses its name argument as a format string in a call to vsnprintf(). By passing dev_name(priv->dev) directly as the format string, an uninitialized stack read regression could occur if a maliciously crafted device tree overlay contains a '%' character in the node name.
Would it be safer to pass "%s", dev_name(priv->dev) instead?
Quoted 8 lines
drivers/remoteproc/amd_mbv_bram_rproc.c new file +8
-0+if (!mem) +return -ENOMEM ; + +rproc_add_carveout (rproc, mem); +rproc_coredump_add_segment (rproc, da,resource_size (&res)); + +return 0 ; +}
[ ... ]
drivers/remoteproc/amd_mbv_bram_rproc.c line 117
Quoted 10 lines
drivers/remoteproc/amd_mbv_bram_rproc.c new file +10
-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;
[Severity: Medium]
Does this error path leak the clock enable count by returning early before calling clk_disable_unprepare(priv->clk)?
Also, if this early return occurs, the remoteproc core's rproc_shutdown() aborts before calling rproc_resource_cleanup(). Does this cause the rproc_mem_entry objects on the carveouts list to leak when the device is later removed via rproc_del()?
drivers/remoteproc/amd_mbv_bram_rproc.c line 130
Quoted 13 lines
drivers/remoteproc/amd_mbv_bram_rproc.c new file +13
-0+ } + +/* 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" );
[Severity: Low]
Is rproc_elf_load_rsc_table_optional() declared?
Similar to the callbacks in amd_bram_rproc_prepare(), this appears to be an undefined function that triggers a build failure.
Quoted 2 lines
drivers/remoteproc/amd_mbv_bram_rproc.c new file +2
-0+return 0 ; +}
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Quoted 19 lines · 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.
v6:
Patch 1, dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc
Quoted 8 lines
- Corrected Krzysztof Kozlowski's Reviewed-by trailer to match the tag provided during the v3 review.
Patch 2, remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver
- Renamed the driver source and object from
amd_bram_rproctoamd_mbv_bram_rproc.
Applied.
Thanks,
Mathieu
Quoted 94 lines
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
Kconfigsymbol toAMD_MBV_BRAM_REMOTEPROC.
- Updated theKconfigprompt to use MicroBlaze/V.
- Removed the reset GPIO and clock sentence from theKconfighelp 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
MAINTAINERSentry.
- Trimmed theKconfighelp text.
- Reused the common WC ioremap/iounmap carveout callbacks.
- Reused the common optional ELF resource-table helper.
- Usedresource_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 throughrproc_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 originaldt_binding_checkcomplaints 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 matchingCOMMON_CLKdependency inKconfig.
- Cleaned up the reset comments and removed the successdev_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_mbv_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_mbv_bram_rproc.cSignature · 1 line
2.34.1