Revolution Pi Connect SE + Debian Bookworm 64 bit

Board Integrations
,
1

The official Mender documentation explains how Mender works. This is a board-specific complement to the official documentation.

Topic title should be in the format: <board type> + <OS>

Suggested title: Revolution Pi Connect SE + Debian Bookworm 64 bit

Device description

Revolution Pi (Kunbus) is an industrial DIN-rail platform based on the Raspberry Pi Compute Module. The RevPi Connect SE uses a Raspberry Pi Compute Module 4S (brcm,bcm2711, revision type 0x15).

Verified on a working Bullseye Mender image on the same hardware:

Property Value
/proc/device-tree/model Raspberry Pi Compute Module 4S Rev 1.0
/proc/device-tree/compatible kunbus,revpi-connect-se, brcm,bcm2711
OS (working control) Debian 11 (bullseye), kernel 6.1.174-rt51-v8

There is no dedicated CM4S / Connect SE config in mender-convert. Closest advertised path is the Raspberry Pi 4 Bookworm 64-bit U-Boot config (same SoC family).

Support level

Board / OS Status
RevPi Connect SE + Debian Bullseye 64-bit + Mender U-Boot Works (same U-Boot generation as below)
RevPi Connect SE + Debian Bookworm 64-bit + stock mender-convert Does not boot — early hang after color splash (confirmed)
Other RevPi variants (Core, Compact, Connect 4/5, …) Not tested here

Tested mender-convert versions (Bookworm hang):

  • 5.2.1 — hang confirmed on hardware
  • master @ e7bff87 (5.2.1-40-ge7bff87) — same hang confirmed on hardware

Both pin the same U-Boot asset: raspberrypi_arm64-2024.04.tar.gz (Mender branch mender-rpi-2024.04``Preformatted text).

Getting started

Follow the official guide: Convert a Mender Debian image.

Input image: official KUNBUS RevPi Bookworm 64-bit lite, e.g. 2026-03-17-revpi-bookworm-arm64-lite.img.

Important before convert:

  1. Boot the vendor image once and complete Kunbus first-boot setup (serial / MAC / model) before converting, same as for Bullseye integrations.
  2. Grow the root partition if needed — the stock lite rootfs is often 100% full, so apt fails while installing Mender packages. Growing root by ~1 GiB is a convert-time prerequisite, not the boot bug below.

Config used for the Bookworm attempt:

./docker-build

MENDER_ARTIFACT_NAME=revpi-bookworm-1 \
  ./docker-mender-convert \
    --disk-image input/2026-03-17-revpi-bookworm-arm64-lite-grown.img \
    --config configs/raspberrypi/uboot/debian/raspberrypi4_bookworm_64bit_config \
    --overlay input/rootfs_overlay_demo

That config installs Mender RPi U-Boot as kernel8.img (MENDER_DEVICE_TYPE=raspberrypi4_64, boot mount /boot/firmware).

Related Bullseye Hub topic (working path on older OS): Revolution Pi + Debian Bullseye 64 bit.

References

  • Docs: Convert a Mender Debian image
  • Config: configs/raspberrypi/uboot/debian/raspberrypi4_bookworm_64bit_config in mender-convert
  • U-Boot build script / branch: build-uboot-rpi64.sh → mender-rpi-2024.04
  • Golden images: Kunbus / Revolution Pi download portal (Bookworm arm64 lite)
  • Detailed repro notes (local): BUG.md in this tree

Known issues

Bookworm + Mender U-Boot 2024.04 early hang (primary)

Symptom: after flashing a stock mender-convert Bookworm image, power-cycle shows the Raspberry Pi color splash, then nothing (no multi-user / SSH). UART on Connect SE is not usable for forensics (PiBridge).

Reproduced with: stock Docker mender-convert on both 5.2.1 and current master — no custom convert hooks, no third-party U-Boot. Convert itself completes successfully; the failure is at early boot.

Strong evidence (controlled bisect on same hardware):

U-Boot 2024.04 + Bullseye CM4S/RevPi FDT   → boots
U-Boot 2024.04 + Bookworm CM4S/RevPi FDT  → early hang
Bookworm Linux + Bookworm CM4S FDT        → boots (vendor image, no Mender U-Boot)

Replacing only Bookworm bcm2711-*.dtb on an otherwise working Bullseye boot VFAT is enough to recreate the hang. So the interesting object is the firmware-provided BCM2711/RevPi FDT handed into U-Boot, not the rootfs alone.

Not the primary cause: missing CM4S model type 0x15 in U-Boot’s rpi_models_new_scheme[] (falls back to “Unknown model” / bcm283x-rpi-other.dtb). On a working Bullseye Mender image, Linux still sees the real RevPi/CM4S tree (kunbus,revpi-connect-se / brcm,bcm2711). That means the unknown-model fdtfile fallback is not what Linux boots from on this Mender path — treat 0x15 support as a separate correctness fix.

Ask to maintainers:

  1. Is Connect SE / CM4S + Bookworm considered supported under raspberrypi4_bookworm_64bit_config, or is a dedicated config needed?
  2. Can Mender RPi U-Boot 2024.04 be fixed (or a newer raspberrypi_arm64-*.tar.gz shipped) to tolerate the Bookworm CM4S/RevPi FDT at fdt_addr?
  3. Separately: add CM4S revision type 0x15 to the RPi model table.
2

Update Sept 03/2026

RevPi Bookworm U-Boot boot issue — current findings

We have now isolated the RevPi boot failure to the Raspberry Pi CM4S device tree.

What we already knew

  • Bullseye boots correctly through the Mender U-Boot A/B boot flow.

  • Bookworm fails very early: rainbow screen, then no further boot or serial output.

  • Vanilla Bookworm without U-Boot boots correctly.

  • Replacing bcm2711-rpi-cm4s.dtb with the Bullseye version makes the newer image boot again.

This identified bcm2711-rpi-cm4s.dtb as the root cause area.

Git bisect

We matched the exact Bullseye working DTB and Bookworm failing DTB to Raspberry Pi firmware Git history.

Between them:

  • 222 total firmware commits

  • 23 commits actually changed bcm2711-rpi-cm4s.dtb

We used git bisect and physically boot-tested the intermediate DTBs.

Result:

  • All tested intermediate DTBs booted correctly.

  • The final DTB-changing commit introduced the failure.

First bad Raspberry Pi firmware commit:

70c596a513fb6a37f26405a40e60733a833a1672

Root cause

That commit includes a Raspberry Pi device-tree change for the PL011 UART.

The working DTs use legacy-compatible PL011 identification, while the failing DT contains:

compatible = "arm,pl011-axi";

U-Boot 2024.04 does not contain a driver match for arm,pl011-axi.

Proof

We took the exact known-bad Bookworm DTB and modified only UART0:

From:

compatible = "arm,pl011-axi";

to:

compatible = "arm,pl011-axi", "arm,pl011", "arm,primecell";

Nothing else was changed.

Result: the RevPi boots successfully again through Mender/U-Boot.

We also confirmed that patching UART0 alone is sufficient; the other disabled PL011 UART nodes do not need to be changed.

Conclusion

The Bookworm failure is caused by a device-tree compatibility change for UART0. The newer Raspberry Pi DT identifies it only as arm,pl011-axi, which U-Boot 2024.04 does not recognize. Restoring the legacy PL011 fallback compatible string makes the exact failing DTB boot successfully.

3

We were able to complete the root-cause investigation and confirm that this issue is caused by a temporary Raspberry Pi Device Tree compatibility regression affecting the PL011 UART definition.

Our findings:

  • Bullseye boots correctly through the Mender/U-Boot A/B flow.

  • Bookworm fails very early on the Revolution Pi Connect SE.

  • We isolated the failure to bcm2711-rpi-cm4s.dtb.

  • We matched the working Bullseye DTB and failing Bookworm DTB against the Raspberry Pi firmware Git history and bisected the DTB changes.

  • The first failing Raspberry Pi firmware commit was:

70c596a513fb6a37f26405a40e60733a833a1672

This introduced the PL011 UART Device Tree change where UART0 was represented as:

compatible = "arm,pl011-axi";

The Mender mender-rpi-2024.04 U-Boot branch does not contain a driver match for arm,pl011-axi.

We then performed a controlled test using the exact known-bad Bookworm DTB. We modified only UART0 from:

compatible = "arm,pl011-axi";

to:

compatible = "arm,pl011-axi", "arm,pl011", "arm,primecell";

With only that change, the same Bookworm DTB boots successfully through Mender/U-Boot.

Raspberry Pi later restored the legacy fallback compatible strings in this patch:

We have now confirmed that KUNBUS included this backport/fix in their Debian Trixie release:

The KUNBUS Trixie bcm2711-rpi-cm4s.dtb contains:

arm,pl011-axi arm,pl011 arm,primecell

and the Revolution Pi Connect SE boots correctly with Trixie through our Mender/U-Boot A/B boot flow.

Therefore, this issue is no longer a release blocker for us, as we can proceed with Trixie.

That said, it may still be worthwhile for Mender to consider making the mender-rpi-2024.04 U-Boot branch compatible with arm,pl011-axi directly. At present, the U-Boot PL011 drivers match the legacy arm,pl011 compatible string, but not arm,pl011-axi. Supporting the newer compatible string would make the Mender Raspberry Pi boot flow more robust against similar Device Tree changes in the future.

4

We have now completed the root-cause investigation and opened a PR against Mender’s mender-rpi-2024.04 U-Boot branch:

The issue was narrowed down to the PL011 UART compatibility string in the affected Bookworm bcm2711-rpi-cm4s.dtb.

The failing DTB exposes UART0 only as:

compatible = "arm,pl011-axi";

while the current Mender U-Boot 2024.04 branch does not match arm,pl011-axi.

We confirmed the root cause experimentally by taking the exact known-bad DTB and changing only UART0 to:

compatible = "arm,pl011-axi", "arm,pl011", "arm,primecell";

With that single change, the same image boots correctly through the Mender/U-Boot A/B flow.

KUNBUS Trixie already contains the later Raspberry Pi backward-compatibility fix, so Trixie is no longer blocked. However, I still think it would be valuable for Mender to merge the U-Boot-side compatibility fix.

There are two possible long-term directions:

  1. Submit the arm,pl011-axi support upstream to U-Boot and wait for it to be accepted and released.

  2. Harden the existing Mender mender-rpi-2024.04 branch now by adding the compatible string to the PL011 driver match table.

Upstreaming is absolutely worth considering, and I am happy to look at that as a separate follow-up. But Mender currently maintains a U-Boot branch based around 2024.04, so even if upstream U-Boot accepts the fix, Mender customers would not benefit automatically without either backporting it or moving the Mender integration to a newer U-Boot release.

For that reason, I think merging the small compatibility fix into the existing Mender branch is the pragmatic short-term solution. It makes the Mender Raspberry Pi boot flow more resilient to valid Raspberry Pi Device Tree changes and directly benefits users of the current Mender integration, while upstream U-Boot work can continue independently.

The same PR also adds explicit Raspberry Pi Compute Module 4S detection, which avoids revision type 0x15 falling through to Unknown model.

PR:

Hopefully the Mender team can review and consider merging this into mender-rpi-2024.04.