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.
