Skip to content

Add Cortex-M7 remoteproc support for iot-gate-imx8plus#614

Draft
shaunmulligan wants to merge 3 commits intomasterfrom
add-m7-remoteproc-support
Draft

Add Cortex-M7 remoteproc support for iot-gate-imx8plus#614
shaunmulligan wants to merge 3 commits intomasterfrom
add-m7-remoteproc-support

Conversation

@shaunmulligan
Copy link
Copy Markdown

@shaunmulligan shaunmulligan commented Mar 24, 2026 •
edited
Loading

⚠️ ⚠️ ⚠️ DON'T MERGE ⚠️ ⚠️ ⚠️

Enable the Cortex-M7 co-processor on the iot-gate-imx8plus (NXP i.MX8M Plus) via the Linux remoteproc framework and RPMsg messaging.

  • M7 device tree — new iot-gate-imx8plus-m7.dts variant with reserved memory, MU mailboxes, and RPMsg vring buffers (based on CompuLab reference compulab-imx8m-plus-rpmsg.dtsi)
  • U-boot — add clk_ignore_unused to mmcargs so Linux doesn't gate M7 clocks while the co-processor is running
  • imx_rpmsg_tty auto-load — new recipe to auto-load the imx_rpmsg_tty module at boot via modules-load.d (NXP Kconfig forces module-only build)
  • layer.conf — add M7 DTB to KERNEL_DEVICETREE and include the autoload recipe in IMAGE_INSTALL

Context

This is part of a PoC proving that balena can natively manage co-processor firmware as OCI container images using ARM remoteproc-runtime. The full pipeline: balena push → cloud build → supervisor deploys FreeRTOS firmware with remoteproc runtime → M7 boots → RPMsg channel created → bidirectional communication via /dev/ttyRPMSG30.

Testing

Tested on iot-gate-imx8plus with balenaOS 6.11.11+rev1:

  • M7 device tree loads correctly, imx-rproc appears as remoteproc0
  • FreeRTOS RPMsg echo firmware loads and runs via remoteproc-runtime
  • /dev/ttyRPMSG30 created, bidirectional RPMsg communication confirmed
  • imx_rpmsg_tty module auto-loads at boot
  • clk_ignore_unused prevents M7 clock gating
  • Survives reboot — firmware reloads, RPMsg re-establishes

@shaunmulligan
Add Cortex-M7 remoteproc support for iot-gate-imx8plus
51b77fe 
Enable the Cortex-M7 co-processor via remoteproc/RPMsg on the
iot-gate-imx8plus (NXP i.MX8M Plus).

Changes:
- Add M7 device tree variant (iot-gate-imx8plus-m7.dts) with reserved
  memory regions, MU mailboxes, and RPMsg vring buffers. Based on
  CompuLab reference compulab-imx8m-plus-rpmsg.dtsi.
- Add DTS patch to both linux-compulab and linux-balena-bootloader
  kernel builds.
- Add clk_ignore_unused to u-boot mmcargs to prevent Linux from
  gating M7 clocks while the co-processor is running.
- Add imx-rpmsg-tty-autoload recipe to auto-load the imx_rpmsg_tty
  kernel module at boot via modules-load.d (module cannot be built-in
  due to NXP Kconfig constraint).
- Add M7 DTB to KERNEL_DEVICETREE in layer.conf.

Tested on iot-gate-imx8plus with FreeRTOS RPMsg echo firmware loaded
via ARM remoteproc-runtime OCI runtime. M7 boots, RPMsg channel
established, bidirectional communication confirmed via /dev/ttyRPMSG30.

Signed-off-by: Shaun Mulligan <shaun@balena.io>
@shaunmulligan shaunmulligan force-pushed the add-m7-remoteproc-support branch from 0e00798 to 51b77fe Compare March 25, 2026 09:54
@shaunmulligan
dts: iot-gate-imx8plus-m7: override pinctrl_ie_di4o4 via label reference
ea0c487 
Release GPIO4 DIO pads (IN2/IO31, IN3/IO29, OUT0/IO30, OUT3/IO12) for M7
use by overriding pinctrl_ie_di4o4 with only the GPIO5/GPIO1 pads that
Linux should retain.

Uses &pinctrl_ie_di4o4 { } label reference instead of re-declaring the
label inside &iomuxc { } to avoid a duplicate-label DTC compile error.

NOT YET PUSHED - pending Yocto build and on-device verification.
@shaunmulligan shaunmulligan marked this pull request as draft March 25, 2026 10:55
@shaunmulligan
dts: iot-gate-imx8plus-m7: add gpio-reserved-ranges for M7 DIO pins
29999f2 
Add gpio-reserved-ranges = <12 1>, <29 3> to the GPIO4 controller node
in the M7 device tree. This marks GPIO4 pins 12 (DO3), 29 (DI3),
30 (DO0), and 31 (DI2) as invalid in Linux gpiolib valid_mask,
preventing any Linux driver or userspace from requesting them.

This is a second layer of protection beyond the pinctrl override:
- pinctrl override: prevents Linux from muxing M7 pads
- gpio-reserved-ranges: prevents gpiolib register-level access

Linux-owned GPIO4 pins (IO20/USB2, IO24/PHY reset, IO28/LED) are
unaffected.

Tested on device: /sys/kernel/debug/gpio shows only gpio-116, 120, 124
for gpiochip3 (GPIO4). M7 GPIO DIO and RPMsg demo fully functional.

Signed-off-by: Shaun Mulligan <shaun@balena.io>
@shaunmulligan shaunmulligan requested a deployment to sign.balena-cloud.com March 27, 2026 12:29 — with GitHub Actions Waiting
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@shaunmulligan