Search the Community

Hi there. 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?

Hello. For the past month, I have been working on fixing, updating, and rewriting the hardware crypto patch for RK3588. I've done so much work on it that I'm considering submitting it for review to be added to mainline kernel. I needed hardware cryptographic acceleration for a small project running on my Kubernetes ARM cluster. I noticed that Armbian is still using rk35xx-montjoie-crypto-v2-rk35xx.patch, so I decided to give it a try, but unfortunately the results were quite buggy. I took a closer look at rk35xx-montjoie-crypto-v2-rk35xx.patch and discovered a fairly large number of bugs and potential improvements. I then spent the past month rewriting and updating the original Montjoie code. I probably would have finished earlier, but I was determined to make Multi-Channel Scatter-Gather (Multi-SG) Linked List Items (LLI) in Direct Memory Access (DMA) work — and it now looks like that simply cannot be done. Bit of explanation: A cryptographic hash like SHA-256 takes a file of any size and boils it down to a fixed-length digest. Because files can be big, the math is done in chunks. The very last chunk of the file must be formatted in a specific way. It requires a special "padding" to be attached to the end, which includes a "1" bit, a bunch of "0" bits, and the exact total length of the original file. When a file is loaded into RAM, the kernel memory manager and DMA mapping layer may place its data across multiple non-contiguous memory regions instead of one large continuous block. When the CPU asks the Rockchip crypto hardware to hash this data, it provides a Scatter-Gather (SG) list — essentially a map that says: Read 4KB here, then read 8KB over there, then 2KB over here. The hardware reads the list and jumps around memory automatically. The Rockchip V2 hardware has a built-in feature to automatically add that cryptographic "padding" to the end of a message. However I suspect that the hardware has a design flaw in how it tracks its progress when jumping between scattered memory chunks. When the hardware reaches the boundary between one chunk and the next in a Multi-SG list, its internal byte/block counter loses track of the exact byte count across the gaps in memory. The result is a completely wrong digest. Because I couldn't figure out hardware internal math (and believe me I was trying hard for around 3 weeks trying everything I could under the sun), the only logical mainline fix was to check the Scatter-Gather list and if it's only one chunk send it to Rockchip hardware engine and if the map has more than one chunk (Multi-SG) it's intercepted bypassing the Rockchip hardware and sent to the CPU's standard software (fallback) crypto driver, which knows how to deal with it correctly. The (most likely) hardware bug is causing descriptor-chain state continuation failure and that could involve, for instance: byte counter resets, partial block FIFO resets, hash state reloads incorrectly, descriptor parser wrongly treats entries as independent jobs therfore HW_PAD cannot correctly track block boundaries across chained LLI descriptors. Moreover Rockchip documentation is a bit suspicious in that RK3588 TRM advertises “LLI DMA” and “HW padding”, but never explicitly mentions that hash operations may span multiple linked descriptors. Below is the list of fixes, updates and changes: 1. Documentation/devicetree/bindings/crypto/rockchip,rk3588-crypto.yaml Clock names corrected. Original had "a" and "h" as clock-names items. v3 corrects them to "core", "aclk", "hclk" matching the actual clock signal names in the hardware and passing make dt_binding_check. YAML example reg size fixed. Original example said 0x4000 (16KB). v3 corrects to 0x2000 (8KB) to match both DTS nodes and the actual hardware register map. 2. drivers/crypto/Makefile Root Makefile hook added. v3 adds obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP2) += rockchip/ to the root crypto Makefile. Without this, if CONFIG_CRYPTO_DEV_ROCKCHIP (the V1 driver) is disabled, the build system never descends into drivers/crypto/rockchip/ and the V2 driver silently doesn't build regardless of Kconfig selection. 3. rk2_crypto.h dbgfs_info field added to struct rockchip_ip. Original was missing it, causing register_debugfs to overwrite dbgfs_stats with the info file pointer. v3 adds struct dentry *dbgfs_info as the third debugfs member. #include <linux/reset.h> added. Moved from rk2_crypto.c so that rk2_crypto_ahash.c and rk2_crypto_skcipher.c can call reset_control_assert/deassert directly in their DMA error recovery paths. fallback_req ordering documented. Added // keep at the end comment on struct skcipher_request fallback_req in rk2_cipher_rctx. Same ordering maintained in rk2_ahash_rctx with struct ahash_request fallback_req as last member — required for the flexible array __ctx placement to work correctly. 4. rk2_crypto.c pm_init return value fixed. Original returned err at the end, which after pm_runtime_enable would always be 0 but was misleading. v3 explicitly return 0. IRQ handler fires complete() only on LISTDONE or hard error. Original called complete() on any non-zero DMA_INT_ST. Intermediate SRC_INT per-LLI-entry interrupts would prematurely wake the hash path before all data was processed, producing wrong digests. v3 only signals completion for RK2_CRYPTO_DMA_INT_LISTDONE (BIT(0)) or error bits (0xF8). Consistent spin_lock_bh throughout. get_rk2_crypto(), probe, and remove all use spin_lock_bh/spin_unlock_bh. Original used plain spin_lock in get_rk2_crypto() and probe, risking deadlock if a crypto engine callback ran on the same CPU. Debugfs overwrite bug fixed. Original register_debugfs wrote to rocklist.dbgfs_stats twice — the second write (info file) overwrote the stats file pointer. v3 correctly uses rocklist.dbgfs_info for the second file. pm_runtime_resume_and_get return value checked in probe. Original ignored this return value. v3 checks it and jumps to err_pm on failure. PM reference count balanced on probe success. Original left usage count at 1 after successful registration, pinning the device ON forever. v3 calls pm_runtime_mark_last_busy + pm_runtime_put_autosuspend after successful registration. Separate err_register_alg label with list_del + pm_runtime_put_sync. Original jumped to err_pm on registration failure, which skipped both the list cleanup and the PM put. v3 has a dedicated label that removes the device from the list and decrements the PM count before falling through to rk2_crypto_pm_exit. crypto_engine_exit called before rk2_crypto_pm_exit in remove. Original order was reversed — clocks disabled before engine drained. v3 exits the engine first to flush all in-flight requests, then disables PM. algt->dev handoff on multi-device remove. When the registering device is removed while a second device survives, v3 iterates all algorithm templates and updates algt->dev to the surviving device, preventing use-after-free in tfm_init/tfm_exit logging. dma_free_coherent added to rk2_crypto_remove. The LLI table is a non-managed allocation. Original never freed it on normal remove, leaking it on every rmmod. v3 frees it at the end of remove. pm_resume does full assert/udelay/deassert cycle. Ensures hardware is cleanly initialised with clocks running on every PM wakeup, not just deassert. 5. rk2_crypto_ahash.c Multi-SG hardware fallback. Added if (sg_nents(areq->src) > 1) check at the top of rk2_ahash_need_fallback. The RK3568/3588 hardware padding engine (HW_PAD) loses block-count state across LLI descriptor boundaries, producing wrong digests for any multi-SG request. Single-SG requests continue to use hardware; multi-SG routes to software fallback and increments stat_fb_sgdiff. Explicit payload length for hardware padding. Added writel(areq->nbytes, rkc->reg + RK2_CRYPTO_CH0_PC_LEN_0) before starting DMA. The HW_PAD bit requires the total message length to be programmed in advance so the hardware knows where to apply the Merkle–Damgård padding. Without this, single-SG hardware hashes would also produce wrong results. INT_EN write-enable mask fixed. Original wrote RK2_CRYPTO_DMA_INT_LISTDONE | 0x7F with no upper bits, which is silently discarded by the HIWORD_UPDATE register pattern. v3 first clears stale pending interrupts (writel(0x7F, DMA_INT_ST)), then writes 0x007F007F so enable bits and their write-enable mask are both set. LIST_INT added to last LLI descriptor. LISTDONE (BIT(0)) is only set in DMA_INT_ST when the last LLI entry has RK2_LLI_DMA_CTRL_LIST_INT (BIT(8)) set in dma_ctrl. Without it, DMA completes silently, no interrupt fires, 2-second timeout every request. v3 adds RK2_LLI_DMA_CTRL_LIST_INT | RK2_LLI_DMA_CTRL_SRC_INT to the last descriptor. Uninterruptible completion wait. Changed from wait_for_completion_interruptible_timeout to wait_for_completion_timeout. The interruptible variant can return early on SIGTERM/SIGKILL while DMA is still writing to memory, causing data corruption or use-after-free. timeout return value captured and checked. Original discarded the return value, making timeout undetectable. v3 stores the return in unsigned long timeout and checks !timeout for ETIMEDOUT, then separately checks !rkc->status for EIO. rctx->nrsgs = 0 initialised before dma_map_sg. Ensures rk2_hash_unprepare never calls dma_unmap_sg on an uninitialised count. Safe dma_unmap_sg in unprepare. Added if (rctx->nrsgs) guard before dma_unmap_sg, preventing a kernel panic if dma_map_sg failed in the prepare step. MAX_LLI overflow check. Added if (ddi >= MAX_LLI) at the top of the LLI build loop with dev_err and -EINVAL. Prevents overflowing the DMA-coherent LLI table with a scatter-list longer than 20 entries. readl_poll_timeout_atomic return value checked. Original discarded the return, allowing wrong digest output if HASH_VALID never set. v3 assigns to err and jumps to theend on timeout. be32_to_cpu in digest readback. Hardware outputs all digest words (SHA1, SHA256, SHA384, SHA512, SM3, MD5) in big-endian register format. readl() on LE ARM64 gives a byte-swapped value; be32_to_cpu corrects it before put_unaligned_le32. pm_runtime_mark_last_busy before put_autosuspend. Refreshes the autosuspend timer on each request completion so the device doesn't suspend between back-to-back requests. DMA error hardware reset. On !rkc->status (DMA error interrupt), v3 performs reset_control_assert/udelay(10)/reset_control_deassert to recover the DMA engine from a stuck state before returning -EIO. crypto_ahash_set_statesize promotion in rk2_hash_init_tfm. After allocating the fallback, v3 queries its statesize and promotes the template's statesize if the fallback needs more space. Fixes -EOVERFLOW on export()/import() when ARM Crypto Extensions drivers (sha1-ce, sha256-ce) advertise a larger statesize than the raw hash state. 6. rk2_crypto_skcipher.c rk2_print gated with #ifdef CONFIG_CRYPTO_DEV_ROCKCHIP2_DEBUG. Register dumps on every DMA error flood production logs. v3 wraps the entire function and its callsite with the debug config guard. OTP KEY VALID bit corrected. Original checked BIT(2) for both HASH BUSY and OTP KEY VALID (copy-paste error). v3 uses BIT(3) for OTP KEY VALID. Multi-bit switch statements corrected. All field switches now use (v >> N) & mask before comparing case values, fixing cases that could never match after masking. dd->dma_ctrl = assignment not |=. The LLI table persists across requests. Using |= accumulates stale flag bits from previous requests. v3 uses = for the initial value. RK2_CRYPTO_DMA_CTL_START << 16 not literal 1 << 16. Ensures the write-enable mask is always correct regardless of the constant value. get_rk2_crypto() with null check for cipher. Original used algt->dev (always first device) for all cipher requests, bypassing load balancing. v3 uses get_rk2_crypto() matching the hash path, with if (!rkc) return -ENODEV. DMA unmap moved before timeout/error checks. Original goto theend on timeout bypassed dma_unmap_sg, permanently leaking the mapping. v3 unmaps unconditionally before checking results. wait_for_completion_timeout (uninterruptible). Same fix as hash — prevents signal interruption while DMA is active. Separate timeout/error errnos. ETIMEDOUT for timeout, EIO for DMA error with rk2_print debug dump. INT_EN write-enable mask + stale clear. Same fix as hash path: writel(0x7F, DMA_INT_ST) then writel(0x007F007F, DMA_INT_EN). LIST_INT added to cipher descriptor. RK2_LLI_DMA_CTRL_LIST_INT added to dd->dma_ctrl so LISTDONE fires in DMA_INT_ST. pm_runtime_mark_last_busy before put_autosuspend. DMA error hardware reset. Same reset_control_assert/deassert recovery as hash. Fallback log changed to dev_dbg. Original dev_info in rk2_cipher_tfm_init flooded logs during PM stress testing (hundreds of TFM allocations per second). v3 uses dev_dbg. Stricter XTS fallback check. Changed sg_nents(areq->src) > 1 to != 1 for the XTS-specific SG check. XTS requires exactly one contiguous buffer — more than one SG is wrong but so is zero. 7. include/dt-bindings/reset/rockchip,rk3588-cru.h Patch correctly uses mainline SCMI for RK3588. mainline Linux kernel Commit 849d9db form Feb 22, 2025 "dt-bindings: reset: Add SCMI reset IDs for RK3588" so there is no reason to modify this file as entries exist already. Please note the patch still removes the entire RK3588_SECURECRU_RESET_OFFSET macro and all its entries as keeping them in rst-rk3588.c alongside SCMI would be redundant and potentially dangerous. rk35xx-crypto-v3.patch

https://github.com/siderolabs/sbc-rockchip/issues/103 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?

hi. Please tell me, I installed the image and bootloader on the emmc (armbian) on the radxa 5t and now I can't install another one because the board doesn't want to start from the CD card. what should I do? Im try this but doesnt work https://docs.radxa.com/en/rock5/rock5t/low-level-dev/maskrom/erase

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.

Trying the Armbian Radxa Rock5T 25.5.1 / 6.1.115 Ubuntu server image for the Rock5T and I can't get the Quectel M2 EM12-G WWAN card to be recognized at all. I was previously running the Joshua Reik image and the card showed in lsusb on that image and worked, but I can't figure out why it's not working on this image. I'm kind of new to all this. I did find this similar thread but never found a resolution. 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 got a radxa rock 5t and trying to install armbian(https://www.armbian.com/radxa-rock-5t), arimbian NOT boot and I can see the indicator light on the board is showing a steady green light. 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