nrfutil running on RPI 4

[drollinger]

Hello Nordic Team and Community,

I'm working on a fully automated Zephyr RTOS development environment on Raspberry Pi (Debian Bookworm) targeted at the nRF52840 Dongle. The goal is a repeatable, shippable setup for remote/telecommuting firmware engineers worldwide – one script installs everything (west, Zephyr SDK, OpenOCD for GPIO SWD flashing, Go + mcumgr, etc.), builds samples like "blinky", and flashes via Raspberry Pi GPIO pins.

We've successfully got SWD flashing working with OpenOCD, and the setup includes mcumgr for potential MCUboot-based DFU. However, for USB/serial DFU options (especially with the dongle's factory Nordic bootloader or legacy workflows), I'd like to explore integrating nRF Util on the Raspberry Pi host.

From my research on DevZone and elsewhere:

• Official nRF Util (v7+) does not have native ARM support (armhf/aarch64) and is distributed as x86 binaries.
• Older versions (v6.x legacy pc-nrfutil) had community workarounds involving building pc-ble-driver from source or using pre-built wheels, but these are deprecated and often fail on modern Raspberry Pi OS.
• Some threads mention feature requests for ARM/SBC support, but no official binaries yet.

Questions:

1. Is there any official or planned support for running nRF Util on ARM Linux (Raspberry Pi) in 2026 or later?
2. If not, are there recommended workarounds (e.g., Docker, QEMU, or specific build instructions for the latest version)?
3. For Zephyr + MCUboot projects on nRF52840, is mcumgr the preferred/recommended DFU tool on ARM hosts like Raspberry Pi? (It seems lightweight and already works well in our setup.)
4. Any tips for USB DFU specifically with the nRF52840 Dongle from an ARM host?

I've attached our setup manual (manual-1.0.0.pdf) with full details, wiring diagrams, and screenshots for context. The script automates a complete environment and proves "blinky" in minutes – we'd love to extend it with reliable DFU options.

Any guidance, confirmation, or pointers to recent solutions would be greatly appreciated!

Thanks in advance,

Cy Drollinger

Electronic Realization llc Indiana

[email protected]

406(539)8117

[Einar Thorsrud]

Hi Cy,

• Is there any official or planned support for running nRF Util on ARM Linux (Raspberry Pi) in 2026 or later?
• If not, are there recommended workarounds (e.g., Docker, QEMU, or specific build instructions for the latest version)?

As you write nrfutil is not supported on ARM64 on Linux, and there is no official workaround. I cannot comment on potential future plans, but you can contact nordic sales regarding that. 

For Zephyr + MCUboot projects on nRF52840, is mcumgr the preferred/recommended DFU tool on ARM hosts like Raspberry Pi? (It seems lightweight and already works well in our setup.)

Yes, that is the approach I would recommend.

Any tips for USB DFU specifically with the nRF52840 Dongle from an ARM host?

There are no officially supported solutions here either. There has been some work by other parties, such as rpi-nrfutil, but I have not experience with it.

[drollinger]

Thank you, just to be redundant: the work I have started is complete. The Zephyr development runs on a RPi(Bookworm), compiles MCUboot, programs the nRF52840 USB dongle over SWD, compiles blinky for MCUboot, and MCUboot programs the blinky. Terse document describing some of process here

[drollinger]

This begs the question: Is there anything the nrfutil can do that cant be done with the MCUboot?

[Einar Thorsrud]

Hi,

These are different things. nrfutil is a PC side tool that has different purposes, one of which is to perform DFU (over different transports, and using both the old nRF DFU protocol and SMP similar to MCUmgr), while MCUboot is a bootloader.

But you did perhaps mean MCUmgr and not MCUboot? If so, these are also very different tools, but overlap in the capability to perform DFU over SMP (MCUmgr can also do other data transfer over SMP). You can see practical examples of using MCUmgr in the documentation for the SMP Server Sample.

[drollinger]

Your inference is spot on, thank you! Okay.