Rock 5T: clean shutdown but reboot hangs with periodic IRQ dump (Armbian 25.11.2, 6.1.115-vendor-rk35xx)

[AWa.]

Hi,

 

Board: Radxa ROCK 5T
SoC: RK3588
Armbian image: Armbian 25.11.2 for Rock 5T
Kernel: 6.1.115-vendor-rk35xx
Userspace: Debian stable (trixie)
U-Boot package: linux-u-boot-rock-5t-vendor 25.11.2 (arm64)

u-boot-tools: 2025.01-3

Boot device: NVMe (/dev/nvme0n1), Armbian 25.11.2 for Rock 5T

 

https://paste.armbian.com/opokufetux

 

Summary

On ROCK 5T, a normal reboot performs a clean shutdown (all services stopped, filesystems unmounted) but the board does not restart.
After reaching Reached target reboot.target - System Reboot., the system hangs for some time and then repeatedly prints an interrupt/IRQ table (GICv3/ITS) on the console. A hardware power cycle is required to recover.

Reboot is therefore unreliable / effectively broken.

 

Poweroff hangs in the same way as reboot (clean shutdown, then IRQ table on screen, board does not actually power down).

 

Configuration details

Relevant /boot/armbianEnv.txt (current state):

verbosity=1
bootlogo=false
console=both
extraargs=cma=256M reboot=warm sysrq_always_enabled=1
overlay_prefix=rockchip-rk3588
fdtfile=rockchip/rk3588-rock-5t.dtb
rootdev=UUID=fbf76c4c-167a-49b2-81a4-e1b0220e8cac
rootfstype=ext4
overlays=
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

/proc/cmdline confirms the kernel parameters are applied:

 

 

root=UUID=fbf76c4c-167a-49b2-81a4-e1b0220e8cac rootwait rootfstype=ext4 splash=verbose console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart= usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cma=256M reboot=warm sysrq_always_enabled=1 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory androidboot.fwver=ddr-v1.18-9fa84341ce,bl31-v1.48,uboot-rmbian-201-09/01/2025

Observed behavior

Run sudo reboot.

Systemd performs an orderly shutdown:

services are stopped,

all filesystems (including NVMe root) are unmounted or remounted ro,

shutdown target is reached:

 

Reached target reboot.target - System Reboot

 

Instead of resetting and returning to U‑Boot, the board hangs.

After some time, the HDMI console repeatedly prints a tall table of interrupts (GICv3/ITS entries, many zeros, some counters for PCIe/NVMe, USB, etc.), and never actually reboots.

Only cutting power recovers the board.

The system otherwise runs stably under load; NVMe, PCIe, network, and filesystem are all healthy.

Workaround

As a workaround, the reboot target was overridden to trigger a SysRq hard reset after a brief delay, so that services can shut down cleanly first:

/etc/systemd/system/systemd-reboot.service.d/override.conf:

 

[Service]
ExecStart=
ExecStart=/bin/sh -c 'sleep 5; echo 1 > /proc/sys/kernel/sysrq; echo b > /proc/sysrq-trigger'
TimeoutStartSec=0

 

With this override in place:

sudo reboot now:

does a normal orderly shutdown,

waits ~5 seconds at the end,

then does SysRq + b to force a full reset,

the board reliably returns to U‑Boot and boots again.

This confirms that:

clean shutdown works,

a forced hardware reset works,

but the normal reboot path used by the vendor RK3588 stack on ROCK 5T leaves the SoC in a bad state (seen as GIC/interrupt dump on screen) instead of performing a full reset.

What I think is wrong

It looks like the firmware/bootloader + vendor kernel combination on ROCK 5T does not properly implement the reboot sequence (PSCIs / PMIC / reset controller), so after Linux hands control over, the hardware stays in some half‑reset state and keeps generating spurious interrupts instead of resetting GIC/PCIe/etc. completely.

The fact that SysRq + b from a fully running system does give a clean hardware reset suggests there is a working reset path, but the normal reboot path used by systemd / kernel is not using it correctly.

 

Could you:

Confirm whether this is a known issue for:

Rock 5T specifically, or

the 6.1.115-vendor-rk35xx kernel / current U‑Boot/BL31 bundle for rk3588 on Armbian?

Advise whether there is:

a newer U‑Boot / ATF / device‑tree combination that fixes reboot on Rock 5T,

or a recommended kernel parameter / DT change (e.g. different PSCI reset mode, watchdog reset, etc.) to get a reliable soft reboot without the hard SysRq fallback?

If needed, provide debug instructions (extra bootargs, specific logs around PSCI/reset) so the issue can be characterized better.

I can provide:

full dmesg from a normal boot,

photos or serial logs of the IRQ table that appears after reboot hangs (GICv3/ITS dump on HDMI),

U‑Boot version / environment if required.

Thanks in advance for looking into this.

Edited 11 hours ago by AWa.