uConsole CM5 (NVMe boot) — hard power-off on every reboot, only fixed by fully unplugging power

uConsole
, ,
1

Hi all,

sorry for the wall of text, claude helped me a litte bit with the text and the summary of everything we did :slight_smile:

I’m running into a reproducible issue on my uConsole CM5 and have already ruled out most of the usual suspects, so I wanted to check if anyone here has seen this before or has ideas.

Setup:

  • uConsole CM5 (NVMe boot only, no SD card, no eMMC)
  • Custom multi-boot setup across 3 partitions on the NVMe (Debian Trixie / RetroPie / Kali), switched via a systemd-based OS selector
  • Firmware: 2026/05/26, 086b83e3332dfc8927c56762771d082f3077a1ae (release)

Symptom:
On every sudo reboot (regardless of which of the 3 OSes triggers it), the board goes completely dead — no LED, no fan, no response to the power button. Only unplugging power for a few seconds and reconnecting fixes it. A clean sudo shutdown -h now followed by pressing the power button to turn it back on always works reliably. It’s only the warm reboot path that fails.

What I’ve already ruled out:

  • EEPROM config — confirmed correct and complete:
  [all]
  BOOT_UART=1
  POWER_OFF_ON_HALT=1
  BOOT_ORDER=0xf461
  PCIE_PROBE=1
  SD_BOOT_MAX_RETRIES=2
  SD_QUIRKS=1
  • Inserting an SD card while still booting from NVMe — no effect
  • PCIe link speed — forced dtparam=pciex1_gen=1 (confirmed active via vclog -m and dmesg, link running at 2.5 GT/s) — no effect, same hard failure
  • Battery voltage — tested completely without batteries installed, USB-C power only — same hard failure (screen stayed black on that cold boot for an unrelated, known reason, but the board itself powered on with LED/fan active; the reboot-death behavior was identical)
  • AXP223 as system-power-controller — checked device tree, the system-power-controller property is not set on the pmic@34 node, so the PMIC isn’t registered as the central shutdown handler
  • Persistent journal — set up /var/log/journal for persistence, but even that doesn’t survive the crash — the cutoff is too abrupt for journald to flush, suggesting a genuine hard power interruption rather than a software/kernel hang

One thing I did notice in dmesg:

[    1.768630] bcm2835-wdt bcm2835-wdt: Poweroff handler already present!

Not sure if this is relevant or just a common/harmless message on CM5 boards in general.

What I haven’t been able to do:
Get a debug UART capture of the actual moment of failure — from what I understand the real debug console (ttyAMA10) requires soldering to test points directly on the CM5 module itself, which I’d rather avoid unless necessary.

Has anyone else seen this specific pattern on the uConsole CM5 (reboot = hard death, shutdown+button = fine)? Any pointers on where else to look (mainboard MCU/EC firmware, specific kernel patch, known NVMe adapter incompatibility) would be much appreciated.

Thanks!

2
3

First of all, thanks for the reply.

Unfortunately, Im not really great with electronics and stuff. But I have some soldering skills.

Based on Claude, this mod only fixes the “long-press-to-turn-off” bug but it doesn’t help with the reboot issue, right?

4

I’m guessing it’s caused by the same issue, raspi changed the behavior of some pins, which broke forced shutdown, but it can also have broken reboots, but that’s less obvious because people don’t reboot their uconsoles regularly?

1 Like
5

Has anyone who did the GPIO_VREF mod tested whether it also fixes sudo reboot (not just forced shutdown)?

6

I can try it. What’s image do you use?

7

I’m using Rex’s latest Trixie image (6.12.87)