• Armbian current images
  • Audio does not work at all.
  • When I plug in a 3.5 mm headset, nothing happens — no detection, no sound.
  • Bluetooth works, Wi‑Fi does not.
  • I have to manually compile the Realtek rtw89 wireless driver. After compiling, both Wi‑Fi and Bluetooth work, but still no audio output.
• Vendor (Radxa) images
  • Audio works perfectly.
  • When I plug in a headset, the system immediately detects it and asks whether it has a microphone.
  • Sound output through the headset works as expected.
  • However, with the vendor image I cannot use Bluetooth and Wi‑Fi at the same time. According to what I found online, the RTL8852BU chip shares internal resources. I must disable Wi‑Fi to use a Bluetooth mouse and keyboard reliably.
  • Connecting a Bluetooth headset causes an immediate disconnect.
• Feedback from Radxa
  • Radxa confirmed that the Bluetooth/Wi‑Fi coexistence issue is caused by the driver.

Summary

At the moment, I cannot use either the current Armbian images or the vendor images without running into major problems:

Armbian: Wi‑Fi/Bluetooth OK (after manual driver build), but no audio.

Vendor image: Audio OK, but Bluetooth and Wi‑Fi cannot work simultaneously.

Is this a known issue, and am I the only one experiencing these problems?

Thanks a lot for your support and help.

I am on the latest vendor release of gnome installed via armbian installer. Kernel is linux-image-6.1.115-*-rk2410.

When I look for audio drivers I do not see

card 3: rockchiphdmiin [rockchip,hdmiin], device 0: fddf8000.i2s-dummy_codec hdmiin-dc-0 [fddf8000.i2s-dummy_codec hdmiin-dc-0]

 Subdevices: 1/1

 Subdevice #0: subdevice #0

I got the board very recently and the forum is a little mesay about the hdmi rx functionality. It would be a great help if anyone can help me out on this, let me know if i am missing anything.

I just got my hands on a brand new 5T with 24GB of RAM and installed Armbian 26.04 minimal on it (on an SD card - no eMMC on this board). I immediately put it to use running CI jobs, however started seeing segfaults and things almost straight away.

Current power source is the Radxa 60W power supply. Currently passively cooled (with the Radxa heat sink). Hasn't gone over 70º in the last 24 hours, even when maxxed out compiling rust packages. 

Here's information about the board:
 

james@kassandra:~$ cat /proc/device-tree/model
Radxa ROCK 5Tjames@kassandra:~$
james@kassandra:~$ dpkg -l | grep '^ii  linux-'
ii  linux-base                                       4.15ubuntu5                                      all          Linux image base package
ii  linux-dtb-current-rockchip64                     26.2.5                                           arm64        Armbian Linux current DTBs in /boot/dtb-6.18.24-current-rockchip64
ii  linux-image-current-rockchip64                   26.2.5                                           arm64        Armbian Linux current kernel image 6.18.24-current-rockchip64
ii  linux-libc-dev:arm64                             7.0.0-15.15                                      arm64        Linux Kernel Headers for development
ii  linux-u-boot-rock-5t-current                     26.2.5                                           arm64        Das U-Boot for rock-5t
james@kassandra:~$ sudo dd if=/dev/mmcblk1 bs=512 count=8192 2> /dev/null | strings | grep '^DDR'
DDR 9fa84341ce typ 24/09/06-09:51:11,fwver: v1.18

I can reliably recreate the segfault by running `claude`:
 

Bun v1.3.14 (0a466a11) Linux arm64
Linux Kernel v6.18.24 | glibc v2.43
CPU: neon fp aes crc32 atomics
Args: "claude"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(5) fetch(35) jsc spawn(8) standalone_executable yaml_parse claude_code
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:constants" "node:crypto" "node:dns" "node:events" "node:fs" "node:fs/promises" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:path/posix" "node:path/win32" "node:perf_hooks" "node:process" "node:readline" "node:stream" "node:stream/consumers" "node:string_decoder" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:vm" "node:zlib" "ws" "node:http2"
Elapsed: 9886ms | User: 3200ms | Sys: 775ms
RSS: 72.61MB | Peak: 0.32GB | Commit: 72.61MB | Faults: 993 | Machine: 24.72GB

panic(main thread): Segmentation fault at address 0x7300A749AD00

dmesg output:

[54442.949901] 2.1.128: claude: potentially unexpected fatal signal 5.
[54442.949933] CPU: 5 UID: 1000 PID: 540517 Comm: claude Not tainted 6.18.24-current-rockchip64 #2 PREEMPT
[54442.949952] Hardware name: Radxa ROCK 5T (DT)
[54442.949959] pstate: 00001000 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)
[54442.949973] pc : 00000000031cb264
[54442.949980] lr : 00000000031cb264
[54442.949986] sp : 0000ffffece87fd0
[54442.949992] x29: 0000ffffece88070 x28: 000000000059aabe x27: 0000ffffb267f740
[54442.950016] x26: 0000000000000004 x25: 0000ffffece884c8 x24: 0000ffffece887b8
[54442.950035] x23: 0000ffffece88850 x22: 000000000691c000 x21: 0000ffffece88540
[54442.950055] x20: 000000000691c000 x19: 0000ffffece886d0 x18: 0000000000000000
[54442.950073] x17: 0000ffffb28386a0 x16: 0000000006a12ff0 x15: 0000000000000034
[54442.950092] x14: 0000000000000032 x13: 0000000000000003 x12: aaaaaaaaaaaaaaaa
[54442.950111] x11: 0101010101010101 x10: 0000000000000000 x9 : 0000000000000000
[54442.950130] x8 : 0000000000000086 x7 : 0000000000000000 x6 : 0000000000000000
[54442.950148] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[54442.950165] x2 : 0000000000000000 x1 : 0000ffffb2a3bc90 x0 : 0000000000000000

I tried running stress-ng and saw thousands of failures leading to a hard lockup:
 

stress-ng: info:  [542138] setting to a 10 mins run per stressor
stress-ng: info:  [542138] dispatching hogs: 8 vm
stress-ng: info:  [542139] vm: using 1.35GB per stressor instance (total 10.79GB of 13.48GB available memory)
stress-ng: fail:  [542153] checkerboard: detected 4 memory errors
stress-ng: fail:  [542149] galpat-one: detected 2437 memory errors
stress-ng: fail:  [542148] flip: detected 32 memory errors
stress-ng: fail:  [542147] flip: detected 96 memory errors
stress-ng: fail:  [542152] galpat-one: detected 5632 memory errors
stress-ng: fail:  [542148] galpat-one: detected 818 memory errors
stress-ng: fail:  [542147] fwdrev: detected 48 memory errors
stress-ng: fail:  [542149] gray code (flip): detected 96 memory errors
stress-ng: fail:  [542150] flip: detected 96 memory errors
stress-ng: fail:  [542147] galpat-one: detected 1980 memory errors
stress-ng: fail:  [542148] gray code: detected 160 memory errors
stress-ng: fail:  [542150] fwdrev: detected 112 memory errors
stress-ng: fail:  [542149] incdec code: detected 160 memory errors
stress-ng: fail:  [542150] galpat-one: detected 1740 memory errors
stress-ng: fail:  [542149] inc-nybble: detected 32 memory errors
stress-ng: fail:  [542148] incdec code: detected 16 memory errors
stress-ng: fail:  [542152] incdec code: detected 16 memory errors
stress-ng: fail:  [542151] flip: detected 288 memory errors
stress-ng: fail:  [542154] flip: detected 288 memory errors
stress-ng: fail:  [542153] flip: detected 144 memory errors
stress-ng: fail:  [542151] galpat-one: detected 256 memory errors
stress-ng: fail:  [542153] galpat-one: detected 871 memory errors
stress-ng: fail:  [542149] modulo X: detected 2 memory errors
stress-ng: fail:  [542149] info: 5 failures reached, aborting stress process
stress-ng: fail:  [542144] vm: detected 2727 bit errors while stressing memory
stress-ng: error: [542138] vm: [542144] terminated with an error, exit status=2 (stressor failed)
stress-ng: fail:  [542148] modulo X: detected 4 memory errors
stress-ng: fail:  [542148] info: 5 failures reached, aborting stress process
stress-ng: fail:  [542142] vm: detected 1030 bit errors while stressing memory
stress-ng: error: [542138] vm: [542142] terminated with an error, exit status=2 (stressor failed)
stress-ng: fail:  [542152] modulo X: detected 3 memory errors
stress-ng: fail:  [542150] modulo X: detected 8 memory errors
stress-ng: fail:  [542147] modulo X: detected 1 memory error
stress-ng: fail:  [542150] moving inversion: detected 12 memory errors
stress-ng: fail:  [542150] info: 5 failures reached, aborting stress process
stress-ng: fail:  [542139] vm: detected 1968 bit errors while stressing memory
stress-ng: error: [542138] vm: [542139] terminated with an error, exit status=2 (stressor failed)
stress-ng: fail:  [542151] modulo X: detected 5 memory errors
stress-ng: fail:  [542152] one-zero: detected 7881 memory errors
stress-ng: fail:  [542151] moving inversion: detected 168 memory errors
stress-ng: fail:  [542153] modulo X: detected 37 memory errors
stress-ng: fail:  [542146] vm: detected 13532 bit errors while stressing memory
stress-ng: error: [542138] vm: [542146] terminated with an error, exit status=2 (stressor failed)
stress-ng: fail:  [542147] mscan: detected 640 memory errors
stress-ng: fail:  [542147] info: 5 failures reached, aborting stress process
stress-ng: fail:  [542143] vm: detected 2765 bit errors while stressing memory
stress-ng: error: [542138] vm: [542143] terminated with an error, exit status=2 (stressor failed)
stress-ng: fail:  [542153] moving inversion: detected 32 memory errors
stress-ng: fail:  [542153] info: 5 failures reached, aborting stress process
stress-ng: fail:  [542141] vm: detected 1088 bit errors while stressing memory
stress-ng: error: [542138] vm: [542141] terminated with an error, exit status=2 (stressor failed)

Anyone have any advice on how to fix this? Is it faulty DDR or a firmware issue?

I'm trying to apply this patch, but I think i'm doing something wrong it doesn't seem to be working. I'm getting the same behavior.
 

[    1.369895] rockchip-dw-pcie a41000000.pcie: iATU: unroll T, 8 ob, 8 ib, align 64K, limit 8G
[    2.224201] r8169 0003:31:00.0 eth0: jumbo features [frames: 16362 bytes, tx checksumming: ko]

[    1.504906] rockchip-dw-pcie a40800000.pcie: iATU: unroll T, 8 ob, 8 ib, align 64K, limit 8G

I tried putting the patch in:
build/userpatches/kernel/rockchip64-current/ 

Then I tried it in:

build/userpatches/kernel/archive/rockchip64-6.18/

because of this output:
[🌱] User patches directory for kernel [ /home/marv/rock5t/build/userpatches/kernel/archive/rockchip64-6.18 ]

Doesn't seem to get applied, when I transfer the 'new' rk3588-rock-5t.dtb file to my device, the 2ed interface doesn't turn on.

What am i doing wrong?

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.

https://forum.radxa.com/t/rock-5b-wwan-support-hardware-bug/25780

Hopefully someone can help as to what could be going on.

Edit: Armbian Monitor Here: https://paste.armbian.com/avusulewax

I boot with the official image https://docs.radxa.com/en/rock5/rock5t/low-level-dev/maskrom/linux and insert the sd card(with armbian img), and run such command, then I can boot armbian from SD card

sudo dd if=/dev/mmcblk0 of=working_idbloader.img bs=512 skip=64 count=8000
sudo dd if=/dev/mmcblk0 of=working_u-boot.itb bs=512 skip=16384 count=8000
sudo dd if=working_idbloader.img of=/dev/mmcblk1 bs=512 seek=64 conv=notrunc
sudo dd if=working_u-boot.itb of=/dev/mmcblk1 bs=512 seek=16384 conv=notrunc

BTW, it seems there's no rock-5t tag, so I selected the 5b one