# Raspberry Pi 4 stuck on boot **URL:** \ **Category:** General Discussions\ **Tags:** u-boot, boot, kernel\ **Created:** [January 21, 2026, 11:22am UTC](https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175 "2026-01-21T11:22:25Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![yakirm-cr](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/yakirm-cr/32/2047_2.png) [@yakirm-cr](https://hub.mender.io/u/yakirm-cr)\ **Post date:** [January 21, 2026, 11:22am UTC](https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175/1 "2026-01-21T11:22:25Z")
Hi. We are building Raspberry Pi images using [RPi-Distro/pi-gen](https://github.com/RPi-Distro/pi-gen). The images are based on Debian 12 arm64 and then they are converted using `mender-convert` version 4.3.0. Recently, a newer Kernel version was released by Debian (version 6.12.62) and since then images converted by mender-convert are stuck on boot with the following output: ```auto MESS:00:00:17.285959:0: brfs: File read: 1059 bytes MESS:00:00:17.291733:0: brfs: File read: /mfs/sd/cmdline.txt MESS:00:00:17.294300:0: Read command line from file 'cmdline.txt': MESS:00:00:17.300177:0: 'console=serial0,115200 console=tty1 root=${mender_kernel_root} rootfstype=ext4 fsck.repair=yes rootwait splash' MESS:00:00:17.437867:0: brfs: File read: 111 bytes MESS:00:00:17.496318:0: brfs: File read: /mfs/sd/kernel8.img MESS:00:00:17.498870:0: Loaded 'kernel8.img' to 0x200000 size 0x9b0c8 MESS:00:00:17.505768:0: Kernel relocated to 0x80000 MESS:00:00:17.509627:0: Device tree loaded to 0x2e659e00 (size 0xe1f5) MESS:00:00:17.518940:0: uart: Set PL011 baud rate to 103448.300000 Hz MESS:00:00:17.525182:0: uart: Baud rate change done... MESS:00:00:17.527199:0: uart: Baud rate change done... MESS:00:00:17.532584:0: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined MESS:00:00:17.540201:0: Watchdog stopped MESS:00:00:17.543698:0: arm_loader: Starting ARM with 948MB ``` Note, that we do not define specific versions to use when building the image with `pi-gen` and no changes were made in the process which builds the Raspberry Pi images. To confirm that the images built by `pi-gen` are valid, we burned them using `rpi-imager` and tried to boot - the Raspberry Pi boot successfully with those images (with the newer Kernel version). Any idea what can be the root cause for stuck boot encountered on images converted using `mender-convert`? Thanks. ---
**Author:** ![lueschem](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lueschem/32/214_2.png) [@lueschem](https://hub.mender.io/u/lueschem)\ **Post date:** [January 22, 2026, 8:23am UTC](https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175/2 "2026-01-22T08:23:04Z")
To me this sounds similar to the [issue I encountered in 2021](https://github.com/lueschem/edi-pi/issues/23). With u-boot in the boot chain it gets difficult to have a synchronous update of the device tree binary (dtb) and the kernel. At some point I got stuck on an old device tree binary and the new kernel did not boot anymore. ---
**Author:** ![yakirm-cr](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/yakirm-cr/32/2047_2.png) [@yakirm-cr](https://hub.mender.io/u/yakirm-cr)\ **Post date:** [January 22, 2026, 10:24am UTC](https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175/3 "2026-01-22T10:24:48Z")
@lueschem, thanks. We are facing this issue even after burning the `*.img.gz` file generated by `mender-convert` on the SD card (i.e. not via the `mender-update` flow), which means that this is a fresh installation that has everything sync. ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [January 22, 2026, 2:40pm UTC](https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175/4 "2026-01-22T14:40:20Z")
Hi @yakirm-cr, My gut feeling is that it’s not necessarily the kernel, but some other part of the plumbing which Raspberry Pi OS changed. They are sometimes quite trigger happy there unfortunately. As I’m not familiar with the `pi-gen` workflow, is my guess correct so far: - the script is obtained via their Github repo - you have a known state which works - you have a known state which is broken If that is accurate, then the most straightforward approach would be a `git bisect`. That will get you to the offending change quite quickly, assuming that there’s not thousands of commits to `pi-gen` in the mean time. Once that is known we can hopefully propose a solution. Greetz, Josef ---
**Author:** ![yakirm-cr](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/yakirm-cr/32/2047_2.png) [@yakirm-cr](https://hub.mender.io/u/yakirm-cr)\ **Post date:** [January 25, 2026, 4:12pm UTC](https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175/5 "2026-01-25T16:12:37Z")
@TheYoctoJester, You were right - some other part of the plumbing which Raspberry Pi OS changed with the new Kernel version. I rebuilt the U-Boot (using [mendersoftware/mender-convert-integration-scripts](https://github.com/mendersoftware/mender-convert-integration-scripts)) with additional debug logging and based on the additional debug messages I found that the new 6.12.62 device tree sets `compatible = "arm,pl011-axi"` for the UART. U-Boot 2024.04 only matches `"arm,pl011"`, so the PL011 driver never binds, which causes the Raspberry Pi to hang on boot. In order to resolve I applied the following patch on the `drivers/serial/serial_pl01x.c` on the branch `mender-rpi-2024.04` of [mendersoftware/uboot-mender](https://github.com/mendersoftware/uboot-mender): ```auto #if CONFIG_IS_ENABLED(OF_REAL) static const struct udevice_id pl01x_serial_id[] ={ {.compatible = "arm,pl011", .data = TYPE_PL011}, + {.compatible = "arm,pl011-axi", .data = TYPE_PL011}, {.compatible = "arm,pl010", .data = TYPE_PL010}, {} }; ``` With this change the issue is resolved. 🙂 ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [January 26, 2026, 6:38am UTC](https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175/6 "2026-01-26T06:38:25Z")
Great @yakirm-cr, Thanks for sharing! ---
**Author:** ![bartvanbos](https://avatars.discourse-cdn.com/v4/letter/b/ac91a4/32.png) [@bartvanbos](https://hub.mender.io/u/bartvanbos)\ **Post date:** [September 4, 2026, 3:34pm UTC](https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175/7 "2026-09-04T15:34:55Z")
We ran into the same underlying `arm,pl011-axi` compatibility issue on a Revolution Pi Connect SE / Raspberry Pi CM4S and completed a deeper root-cause investigation here: > [@Revolution Pi Connect SE + Debian Bookworm 64 bit](https://hub.mender.io/t/revolution-pi-connect-se-debian-bookworm-64-bit/8354): > > The official [Mender documentation](https://docs.mender.io/) explains how Mender works. This is a board-specific complement to the official documentation. Topic title should be in the format: \ + \ 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… We confirmed that U-Boot 2024.04 does not match `arm,pl011-axi` when it is the only PL011 compatible string. Patching only UART0 in the failing DTB to add the legacy fallbacks makes the image boot again. I have opened a PR against Mender’s `mender-rpi-2024.04` branch to address this directly in the Mender-maintained U-Boot fork: > > > This PR adds two Raspberry Pi Compute Module 4S compatibility fixes to the \`mend…er-rpi-2024.04\` branch. > > \### 1. Add Compute Module 4S board detection > > Raspberry Pi revision type \`0x15\` currently falls through to \`Unknown model\` and uses \`bcm283x-rpi-other.dtb\`. > > This patch maps revision type \`0x15\` to: > > \`bcm2711-rpi-cm4s.dtb\` > > and uses the same onboard Ethernet handling as Compute Module 4. > > \### 2. Add \`arm,pl011-axi\` PL011 compatibility > > Newer Raspberry Pi device trees may describe the PL011 UART as: > > \`compatible = "arm,pl011-axi";\` > > U-Boot 2024.04 currently only matches the legacy \`arm,pl011\` compatible string. As a result, the UART does not bind when the device tree does not provide the legacy fallback. > > This behavior has also been observed in another Raspberry Pi 4 / Mender integration case: > > https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175/5 > > We reproduced and investigated the issue in detail on a Revolution Pi Connect SE / Raspberry Pi Compute Module 4S using the Bookworm \`bcm2711-rpi-cm4s.dtb\`: > > https://hub.mender.io/t/revolution-pi-connect-se-debian-bookworm-64-bit/8354 > > The investigation and support discussion are also tracked in Northern.tech support case: > > https://support.northern.tech/hc/en-us/requests/12515 > > The regression was isolated by bisecting Raspberry Pi firmware DTB changes, and confirmed by modifying only UART0 in the failing DTB from: > > \`compatible = "arm,pl011-axi";\` > > to: > > \`compatible = "arm,pl011-axi", "arm,pl011", "arm,primecell";\` > > With that change, the same image boots successfully through the Mender/U-Boot A/B boot flow. > > Adding \`arm,pl011-axi\` to the generic PL011 driver match table allows U-Boot to work directly with these device trees without depending on the legacy fallback string. > > Raspberry Pi later restored the legacy PL011 fallback compatibles in newer device trees, so current Trixie-based Revolution Pi images are no longer affected. This U-Boot change nevertheless makes the Mender Raspberry Pi bootloader more robust against device trees using \`arm,pl011-axi\` directly. > > These changes are submitted here specifically for the Mender-maintained \`mender-rpi-2024.04\` integration branch. Any corresponding upstream U-Boot changes can be submitted separately through the U-Boot mailing-list process. The long-term fix can also be considered upstream in U-Boot, but merging the small compatibility fix into Mender’s current 2024.04-based branch would immediately harden the existing Raspberry Pi integration for Mender users. If others here are affected by the same issue, it would be helpful to reference the PR and add your test results/use case there as well. ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [September 14, 2026, 9:30am UTC](https://hub.mender.io/t/raspberry-pi-4-stuck-on-boot/8175/8 "2026-09-14T09:30:24Z")
Hi @bartvanbos, Thanks for sharing and submitting! Greetz, Josef