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).
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:
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),
Rock 5T: clean shutdown but reboot hangs with periodic IRQ dump (Armbian 25.11.2, 6.1.115-vendor-rk35xx)
in Radxa Rock 5T
Posted · Edited by 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/2025Observed 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 RebootInstead 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=0With 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.