Search the Community

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

I am trying to get the ARM performance assessment setup working (I'm trying to get Mali profiling for OpenCL code) on the Rock 5B+, and I've hit a blocker. The main component to this is some kernel configuration (CONFIG_ARM_SPE_PMU) and a loadable module. Oddly, those work fine in a custom kernel build. What I am hitting appears to be some missing interrupt setup that renders all those components inert. (It has to be a custom build to get CONFIG_ARM_SPE_PMU set. The issue is that even with the kernel configured and the module loaded, the SPE component remains inactive. ARM has its own system report tool which analyzes a setup, and that tool is reporting an issue: And indeed, nothing seems to show in cat /proc/interrupts. The man page for the module suggests this is the issue: It says: KPTI is definitely disabled and the SPE PMU loads (it's in lsmod) but it still doesn’t show in /sys/bus/event_source/devices/. Nothing relevant seemed to show in dmesg either. Frankly, I have no idea where to look for the SPE interrupt, or how to set it up. If anybody has any pointers or suggestions, I'd be extremely grateful.

mar 22 2026 build. system seems to boot up, lights on, fans on at boot but no hdmi output

Hi everyone, I'm facing an issue with Armbian installation on Rock 5B Plus. Hardware Board: Radxa ROCK 5B+ (RK3588) Storage: NVMe #1 (system): 256 GB, in M.2 slot 1 NVMe #2 (backup): 128 GB, in M.2 slot 2 Boot: MTD flash + NVMe Power supply: both POE+ HAT 25W and official power supply 30W Software Armbian: 25.11.2 Desktop ubuntu Kernel: 6.1.115-vendor-rk35xx Boot configured via armbian-install → “Boot from MTD Flash, system on NVMe” Initial install steps Wrote Armbian image to microSD and booted from SD. Used armbian-install to install: Boot from MTD Flash, system on NVMe #1 Powered off, removed SD, left only NVMe #1 installed. Board boots fine from SPI+NVMe #1: blue LED, OS comes up, Green LED, everything OK. Power off the board and plug NVME #2 (preformatted ext4 with gparted and empty, the disk works because I tried the procedure the other way around, using the second disk as the main one) Power on. Solid blue light, no OS, no HDMI output (I don't have UART) lsblk -f with microSD plugged: mtdblock0 mmcblk1 └─mmcblk1p1 ext4 1.0 armbi_root 2e67f233-22a9-46c9-90a7-8f0e0f2d3154 21.7G 22% /var/log.hdd / zram0 [SWAP] zram1 36M 16% /var/log zram2 nvme1n1 ├─nvme1n1p1 ext4 1.0 cacf66ca-ea9b-4dc4-b7b3-185f18e7c64f 100G 6% /mnt/main └─nvme1n1p2 ext4 1.0 data a7d6675c-3ca6-4a87-85cf-7d91856fd79c nvme0n1 └─nvme0n1p1 ext4 1.0 armbi_backup 5aadc790-715a-4f48-bbbc-ce4bfd2717bd 110.8G 0% /mnt/backup /boot/armbianEnv.txt looks correct verbosity=1 bootlogo=true console=both extraargs=cma=256M overlay_prefix=rockchip-rk3588 overlays=panthor-gpu fdtfile=rockchip/rk3588-rock-5b-plus.dtb rootdev=UUID=cacf66ca-ea9b-4dc4-b7b3-185f18e7c64f rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u /etc/fstab looks correct # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=cacf66ca-ea9b-4dc4-b7b3-185f18e7c64f / ext4 defaults,noatime,commit=120,errors=remount-ro,x-gvfs-hide 0 1 UUID=5aadc790-715a-4f48-bbbc-ce4bfd2717bd /mnt/backup ext4 defaults,nofail 0 2 <--- also tried without this line I've also tried by "forcing" the mount of NMVE #2 by adding it to /etc/fstab of NVME #1 but nothing changes. Could you please help me understand if this is an issue related to my configuration or could be a bug? Thanks

Looks like only one HDMI port and one NVMe drive bays work on the edge kernels. Not sure whats wrong with HDMI port but two SSDs installed cause issues PCIE addressing. Probably overlay issue with the newer kernel images?

Downloaded Debian 13 (Trixie)Minimal / IOT kernel 6.18 onto SD and had it working 24/7 for about 2-3 days with no problems. I selected the option to copy the content of the SD card to an NVME, updated the MTD flash and set it as first boot option and now the device wont boot from nvme, SD or USB. How can I recover the unit?

I have a nice armbian image on an SSD on a rock5b board. I want to copy it to an sd card for cloning on other boards. Does anyone know how this can be done? It doesn't come out via dd

My recent RK3588 kernel adventure: - dual-core H.265 (HEVC) encoding working live at full 4K@60 on armbian-build edge kernel (6.19-rc8) for Rock 5B[+] and Orange Pi 5 Ultra. - fix for setting HDMIRX EDID (this didn't work in mainline on any of my tested hardware) This is out-of-tree (practical focus over upstream goals), but it's stable and producing clean bitstreams. Repo: https://github.com/rcawston/rockchip-rk3588-mainline-patches Feedback welcome.

Hi, i think the rpm setting-step's of the onboard fan is to low. - how can this be adjusted? SBC: Rock5b

Hi rock5b user 🙂 My sbc hangs after 8-14 hours on the network. no ping from inside or outside works # ip link - show eth0 up after the commands ip link set eth0 down ip link set eth0 up - the network worgs again, https://paste.armbian.com/tiqabekoje - any hints for this issue?

Description: Hello everyone, I am encountering an issue where kernel configuration changes do not take effect when building an image for the Rock 5B using the Armbian Build system. Environment: Board: Rock 5B Kernel: Vendor Release: Noble Build Mode: Mini Build Tag/Branch: v25.11 Specific Issue: To ensure compatibility with Redroid containers, I need to change the kernel's CONFIG_ARM64_VA_BITS from the default 48-bit to 39-bit. What I have tried: I have attempted the following three methods, but none have worked: Ran the kernel configuration tool to change CONFIG_ARM64_VA_BITS, then copied the generated .config to userpatches/linux-rk35xx-vendor.config. Took the default config/kernel/linux-rk35xx-vendor.config, manually modified/added CONFIG_ARM64_VA_BITS=39 and CONFIG_ARM64_VA_BITS_39=y, and copied it to userpatches/linux-rk35xx-vendor.config. Created a kernel source patch in userpatches targeting arch/arm64/configs/rockchip_linux_defconfig and arch/arm64/configs/defconfig to force CONFIG_ARM64_VA_BITS=39 and CONFIG_ARM64_VA_BITS_39=y. Result: Regardless of the method used, the final Armbian-generated kernel remains at VA_BITS=48. It seems my configuration changes are being overwritten or ignored during the build process. Request: Is there specific logic in the Vendor/RK3588 build configuration that forcibly locks VA_BITS? What is the correct way to modify this parameter for this specific board/kernel combination? Thanks for your help!

after configuring the image from the sd card and installing the system on ssd m2 via armbiab-install, the board stopped shutting down. I tried to change bootloader, img, and EF through rkdeveloptool, but nothing helps. PS EF doesn't work, does anyone know what to do?

I have an Radxa 5B+ that are powered through POE HAT. The problem is that POE HAT fan does not work at all. I have to identical machines, same issue on both of them. I have installed Armbian minimal Bookworm on both, on nvme ssd.

I have Radxa 5B+ with 1TB nvme ssd. I installed Armbian minimal Bookworm on my nvme disk. IT starts without the SD card. Problem started few days ago when i run apt upgrade. After that, the machine don't start without SD card. I have tried to reinstall the machine several times, same happends. I also tried Armbian minimal Trixie, but there the machine don't start at all without SD card. So something have changed the last days. At the moment i have installed Bookworm again, and used the command "sudo apt-mark hold linux-u-boot-rock-5b-plus-vendor". Now the machine starts without SDcard, and i can use apt upgrade, but it is not a long term solution. Anyone have the same issue and a solution?

Hiya, I am currently trying to setup some ROCK 5B boards as runners and as I install the latest Ubuntu 24.04 (Noble) from here https://www.armbian.com/rock-5b/ it seems to get to where I configure my user etc, then on the next boot it gets stuck at kernal. So I guess before I go through trial and error , is there a recognised most stable build that can be relaibly flashed people would recommend, I found the Rock provided Debian and KDE Plasma to be very buggy and just kept locking up on me so something with Gnome would be cool for now , but will probably move to headless much further down the line. Amazing community reading the messages so far so thank you for everyone who contributes!

Hy all, For some time now I have a Rock 5b + with 16Gig memory. The problem I have is playback video' s in youtube. Video's are not even watcheble in the lowest resolution. Other 4k video' s play fine. I tried several bechmark video' s from online sources. I looked around to see if others experiance the same problem but cannot find anny clu in this matter. I use Armbian ver. 25.5.1 Do others have the same issue? Is there a soltion for this problem? Also I find this board not the fastest. It's a bit faster than mi RPI5 with 4Gig mem. The PI5 plays HD on youtube. I also have a OrangePi 5 ultra with 16 gig memory on stock Orangepi ubuntu witch is a dream to work with. This board is fast, has a small formfactor and became my daily PC for everything. This board also play's youtube video' s in HD. A direct comparacing with the Rock 5b+ is not possible because no Armbian version will boot on this OrangePi board sadly. I tested on wired and WiFi network with no vissible difference. Anny advise is welcome! Ernst-Jan

I am using :- [ Ubuntu 24.04 (Noble)](https://dl.armbian.com/rock-5b-plus/Noble_vendor_server) from :- [Radxa Rock 5B Plus - Armbian](https://www.armbian.com/rock-5b-plus/) Trying to turn fan on on Radxa Rock 5B+ selecting the device using armbian-config actually makes it disappear I am getting `line 3: echo: write error:Device or resource busy`

Title, i just download the right version used balenaEtcher for flashing it on microssd and its stuck on blue light(booting), how i can solve it

Hello, I've recently bought a rock 5B plus. I have a brand new crucial P310 nvme 1TB with the goal to boot from it. As the title says, sometimes the nvme drive is properly detected, sometimes not. (Everytime the controller is visible in lspci, but only sometimes shows in lsblk). When the drive is properly detected, I can write to it and it works fine, without issues. I've noticed that it is more likely to be detected on a cold boot (ie. if I turn off the power and come back the next day, the first time it will probably show up). I have the official radxa 65w PD power adapter (although I've also tried a lot more during the process with the same results). I tried with the official radxa debian image, and with armbian, and the results are exactly the same on both. Btw, I would like to mention that armbian noble gnome doesn't boot even from the sd card (blue led but no display output, I let it for over 10 minutes), only the minimal/iot works. I don't know what else to try at this point, I can post any info / logs you may want. Thanks!

hey all, I have been running three Rock 5B+ for some time now with Proxmox arm port, and last night I did a kernel update to the latest, and now all three SBC are running extremely slow, PVE does not load, and there are a bunch of system errors (see below). I tried going back to an older kernel, but the same errors remain. any thoughts? Aug 18 07:13:00 PMOX2 kernel: rk806 spi2.0: no dvs-setting pinctrl state Aug 18 07:13:00 PMOX2 kernel: cpu cpu0: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: cpu cpu0: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: cpu cpu0: Failed to get leakage Aug 18 07:13:00 PMOX2 kernel: cpu cpu4: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: cpu cpu4: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: cpu cpu4: Failed to get leakage Aug 18 07:13:00 PMOX2 kernel: cpu cpu6: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: cpu cpu6: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: cpu cpu6: Failed to get leakage Aug 18 07:13:00 PMOX2 kernel: arm-scmi firmware:scmi: Failed. SCMI protocol 17 not active. Aug 18 07:13:00 PMOX2 kernel: debugfs: File 'Capture' in directory 'dapm' already present! Aug 18 07:13:00 PMOX2 kernel: debugfs: File 'Capture' in directory 'dapm' already present! Aug 18 07:13:00 PMOX2 kernel: rk-multicodecs es8316-sound: ASoC: Property 'rockchip,audio-routing' does not exist or its length> Aug 18 07:13:00 PMOX2 kernel: dw-pcie fe190000.pcie: invalid resource Aug 18 07:13:00 PMOX2 kernel: dw-pcie fe190000.pcie: Failed to initialize host Aug 18 07:13:00 PMOX2 kernel: mpp_rkvdec2 fdc38100.rkvdec-core: shared_niu_a is not found! Aug 18 07:13:00 PMOX2 kernel: rkvdec2_init:1198: No niu aclk reset resource define Aug 18 07:13:00 PMOX2 kernel: mpp_rkvdec2 fdc38100.rkvdec-core: shared_niu_h is not found! Aug 18 07:13:00 PMOX2 kernel: rkvdec2_init:1201: No niu hclk reset resource define Aug 18 07:13:00 PMOX2 kernel: mpp_rkvdec2 fdc48100.rkvdec-core: shared_niu_a is not found! Aug 18 07:13:00 PMOX2 kernel: rkvdec2_init:1198: No niu aclk reset resource define Aug 18 07:13:00 PMOX2 kernel: mpp_rkvdec2 fdc48100.rkvdec-core: shared_niu_h is not found! Aug 18 07:13:00 PMOX2 kernel: rkvdec2_init:1201: No niu hclk reset resource define Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: rockchip_init_read_margin: no regulator (venc) found: -19 Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: Failed to get leakage Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: error -ENODEV: _opp_set_regulators: no regulator (venc) found Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: failed to set opp config Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: failed to init opp info Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: failed to init_opp_table Aug 18 07:13:00 PMOX2 kernel: rkvenc_init:2147: failed to add venc devfreq Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbe0000.rkvenc-core: rockchip_init_read_margin: no regulator (venc) found: -19 Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbe0000.rkvenc-core: Failed to get leakage Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbe0000.rkvenc-core: error -ENODEV: _opp_set_regulators: no regulator (venc) found Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbe0000.rkvenc-core: failed to set opp config Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbe0000.rkvenc-core: failed to init opp info Aug 18 07:13:00 PMOX2 kernel: mpp_rkvenc2 fdbe0000.rkvenc-core: failed to init_opp_table Aug 18 07:13:00 PMOX2 kernel: rkvenc_init:2147: failed to add venc devfreq Aug 18 07:13:00 PMOX2 kernel: rockchip-dmc dmc: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: rockchip-dmc dmc: Failed to get leakage Aug 18 07:13:00 PMOX2 kernel: rockchip-dmc dmc: failed to get vop bandwidth to dmc rate Aug 18 07:13:00 PMOX2 kernel: rockchip-dmc dmc: failed to get vop pn to msch rl Aug 18 07:13:00 PMOX2 kernel: mali fb000000.gpu: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: mali fb000000.gpu: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: mali fb000000.gpu: Failed to get leakage Aug 18 07:13:00 PMOX2 kernel: debugfs: Directory 'fb000000.gpu-mali' with parent 'vdd_gpu_s0' already present! Aug 18 07:13:00 PMOX2 kernel: debugfs: Directory 'fb000000.gpu-mali' with parent 'vdd_gpu_s0' already present! Aug 18 07:13:00 PMOX2 kernel: RKNPU fdab0000.npu: can't request region for resource [mem 0xfdab0000-0xfdabffff] Aug 18 07:13:00 PMOX2 kernel: RKNPU fdab0000.npu: can't request region for resource [mem 0xfdac0000-0xfdacffff] Aug 18 07:13:00 PMOX2 kernel: RKNPU fdab0000.npu: can't request region for resource [mem 0xfdad0000-0xfdadffff] Aug 18 07:13:00 PMOX2 kernel: RKNPU fdab0000.npu: RKNPU: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: RKNPU fdab0000.npu: Failed to get specification_serial_number Aug 18 07:13:00 PMOX2 kernel: RKNPU fdab0000.npu: Failed to get leakage Aug 18 07:13:00 PMOX2 kernel: debugfs: Directory 'fdab0000.npu-rknpu' with parent 'vdd_npu_s0' already present! Aug 18 07:13:00 PMOX2 kernel: debugfs: Directory 'fdab0000.npu-rknpu' with parent 'vdd_npu_s0' already present! Aug 18 07:13:00 PMOX2 kernel: rk_hdmirx fdee0000.hdmirx-controller: hdmirx_cancel_cpu_limit_freq freq qos nod add Aug 18 07:13:00 PMOX2 systemd-tmpfiles[765]: Setting file flags is only supported on regular files and directories, cannot set > Aug 18 07:13:00 PMOX2 blkmapd[786]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory Aug 18 07:13:01 PMOX2 pmxcfs[1241]: [quorum] crit: quorum_initialize failed: 2 Aug 18 07:13:01 PMOX2 pmxcfs[1241]: [quorum] crit: can't initialize service Aug 18 07:13:01 PMOX2 pmxcfs[1241]: [confdb] crit: cmap_initialize failed: 2 Aug 18 07:13:01 PMOX2 pmxcfs[1241]: [confdb] crit: can't initialize service Aug 18 07:13:01 PMOX2 pmxcfs[1241]: [dcdb] crit: cpg_initialize failed: 2 Aug 18 07:13:01 PMOX2 pmxcfs[1241]: [dcdb] crit: can't initialize service Aug 18 07:13:01 PMOX2 pmxcfs[1241]: [status] crit: cpg_initialize failed: 2 Aug 18 07:13:01 PMOX2 pmxcfs[1241]: [status] crit: can't initialize service Aug 18 07:13:20 PMOX2 kernel: [GTP-ERR][__do_register_ext_module:79] Module [goodix-fwu] timeout

Hi i want to know if it’s possible to connect a raxda rock 5B with armbian on a touch screen Joy-it LCD10 V2 Module écran tactile 25.7 cm (10.1 pouces) 1280 x 800 Pixel by usb and hdmi ?

I am Running Armbian 24.5.1 Jammy with Linux 6.1.115-vendor-rk35xx on Radxa Rock5b (and it works great!!) when running sudo apt dist-upgrade or sudo apt upgrade I get Die folgenden Pakete sind zurückgehalten worden: armbian-bsp-cli-rock-5b " Packages retained" apt list --installed | grep armbian-bsp-cli-rock-5b gives: armbian-bsp-cli-rock-5b-legacy/jammy,now 24.5.1 arm64 [installiert] armbian-bsp-cli-rock-5b/jammy,now 24.5.1 arm64 [Installiert,aktualisierbar auf: 25.5.1] ## installed, can be updated can/shall I force the the use of "armbian-bsp-cli-rock-5b/jammy,now 24.5.1 arm64 [Installiert,aktualisierbar auf: 25.5.1]" ? how? what is the correct procedure to update to 25.5.x? thanks

Hello all! I have a radxa rock 5b (8GB, not the plus version) and am running armbian (bookworm) on it. The kernel version (uname -r) reports as 6.12.32-current-rockchip64. By and large almost everything seems to be working - video playback in VLC is fine, 3d acceleration is working (I get around 58-60fps in the game 'torcs' as an example). The only thing I can't seem to get working (and can't find much about it) is the hdmi input. I see some five devices listed in dev (from /dev/video0 to /dev/video4) although none of these seem to relate to the hdmi input. Does the hdmi input work on the 5b under armbian at all? thanks ljones

Any fixes for this? Some rock chip ICs need custom PCie overlay to set pcie speeds, maybe the kernel just has it set to gen 2? 0001:11:00.0 Non-Volatile memory controller: Micron/Crucial Technology Device 5421 (rev 01) (prog-if 02 [NVM Express]) Subsystem: Micron/Crucial Technology Device 5021 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 126 Region 0: Memory at f1200000 (64-bit, non-prefetchable) [size=16K] Capabilities: [80] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 unlimited ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s (downgraded), Width x2 (downgraded) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp+ 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCap2: Supported Link Speeds: 2.5-16GT/s, Crosslink- Retimer+ 2Retimers+ DRS- LnkCtl2: Target Link Speed: 16GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ EqualizationPhase1+ EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: Upstream Port Capabilities: [d0] MSI-X: Enable+ Count=9 Masked- Vector table: BAR=0 offset=00002000 PBA: BAR=0 offset=00003000 Capabilities: [e0] MSI: Enable- Count=1/8 Maskable+ 64bit+ Address: 0000000000000000 Data: 0000 Masking: 00000000 Pending: 00000000 Capabilities: [f8] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100 v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Capabilities: [110 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=10us PortTPowerOnTime=300us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns L1SubCtl2: T_PwrOn=10us Capabilities: [128 v1] Alternative Routing-ID Interpretation (ARI) ARICap: MFVC- ACS-, Next Function: 0 ARICtl: MFVC- ACS-, Function Group: 0 Capabilities: [1e0 v1] Data Link Feature <?> Capabilities: [200 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [300 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Capabilities: [340 v1] Physical Layer 16.0 GT/s <?> Capabilities: [378 v1] Lane Margining at the Receiver <?> Kernel driver in use: nvme

Why does HDMI Audio work on Debian 12 Bookworm 6.1 version and not on Debian 12 Bookworm 6.12? I have updated to latest version and still no HDMI audio. Is there a patch or something i can do to fix this?