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

Yesterday I was happy to see the new and fresh Armbian release for the Rock 5 ITX after about 1 year from the last update. I also tried the Armbian Imager and the SD creation was very easy and smooth. I selected the recommended release based on Ubuntu 24.04 + Gnome desktop. Unfortunately when the desktop was about to start, everything when black, stucked and zero interface. On the other hand, the OS is alive and I can connect remotely via SSH. Did anyone have the same problem? Possible solution? [EDIT]. sudo systemctl restart gdm and desktop pops up. Restarting the system, black again.

hi there, I'm a complete Linux noob so please forgive my ignorance. But I do have 25+ years experience in IT so am relatively conversant with basic principles - so please be patient I did try to search for any previous threads but couldn't find any. I'm trying to setup a RADXA Rock 5 ITX with OpenMediaVault for my NAS. I have a 2TB NVMe m.2 SSD that I'll use for the OS. For the NAS storage I'm using 4x Western Digital 16TB SATA III drives. I downloaded the Armbian 25.2.2 bootable image from https://www.armbian.com/radxa-rock-5-itx/ and used Balena Etcher (the legit version from Balena-io) to make my bootable microSD card. When I boot, I receive an error message of "failed to mount /dev/mount/mmcblk0p1 as root file system" I'm guessing this is because there is no emmc on this board other than what's provided for RooibOS flash? Do I just need to reconfigure the Armbian Bookworm setup script to use / look for the NVMe m.2 SSD instead of the emmc? If so, is there a way to do that on a Windows PC? If not, I may just have to go with the standard RooibOS install using Armbian Noble just to get a Linux system up and running, then edit the Armbian setup script, reflash the Rock 5 ITX and start again? Or is there something else I'm missing? Thanks in advance for your help.

After my last update on my radxa5-ITX, apart from the name changes of the NIC (related?), I remarked that I could not cryptroot-unlock the root partition because of dm_mod apparently missing from initramfs. To give some context, this is how I set things up some while ago and things went pretty smooth until recently. Too bad armbian does not keep the previous kernel (though I get the reason why). Inspecting the boot partition, cat config-6.1.115-vendor-rk35xx | grep DM_CRYPT CONFIG_DM_CRYPT=m the kernel seems to have been compiled with the proper option and lsinitramfs initrd.img-6.1.115-vendor-rk35xx | grep 'usr.*cryptsetup' usr/lib/aarch64-linux-gnu/libcryptsetup.so.12 usr/lib/aarch64-linux-gnu/libcryptsetup.so.12.9.0 usr/lib/cryptsetup usr/lib/cryptsetup/askpass usr/lib/cryptsetup/functions usr/sbin/cryptsetup and initramfs seems properly linked to the relevant libraries so I do not understand why device mapper remains unavailable. At this point, I have no hypothesis except a very unlikely one An unlikely hypothesis Could failure to initialize the device mapper have nothing to do with dm_mod availability but be solely the side effect of Because I always unlocked the root part either from console or from a dropbear session, I understood device mapper init as an anterior step, independent from NIC availability. But is it really the case. What am I missing?

Hello! I'm new to this forum but i follow the SBC comunity for a long time. I have a Pine 64, a bunch of raspberryies, 2 nanopies and some "japanese" arm64 tablet. Now i have bought a Radxa 5 Mini-ITX and i'm very happy with it. I was capable to compile ffmpeg with the rockchip extensions and exploit the RK3588 VPU and the NPU with face recognition. Now i was testing the HDMI Input of the board and unfortunaly discovered that the video is capturing just fine but i'm out of luck with the audio side. On the kernel 6.1.115 (last BSP at the moment i think) the recording device of the audio input is not visible in arecode -l This is what i see: **** List of CAPTURE Hardware Devices **** card 4: rockchipes8316 [rockchip-es8316], device 0: dailink-multicodecs ES8316 HiFi-0 [dailink-multicodecs ES8316 HiFi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 But the hdmi input audio card is still found under /proc/asound/cards: root@rock-5-itx:~# cat /proc/asound/cards 0 [rockchiphdmi1 ]: rockchip-hdmi1 - rockchip-hdmi1 rockchip-hdmi1 1 [rockchiphdmi0 ]: rockchip-hdmi0 - rockchip-hdmi0 rockchip-hdmi0 2 [rockchiphdmi2 ]: rockchip-hdmi2 - rockchip-hdmi2 rockchip-hdmi2 3 [rockchiphdmiin ]: rockchip-hdmiin - rockchip-hdmiin rockchip-hdmiin 4 [rockchipes8316 ]: rockchip-es8316 - rockchip-es8316 rockchip-es8316 5 [rockchipspdiftx]: simple-card - rockchip,spdif-tx1 rockchip,spdif-tx1 Furthermore if i go under /proc/asound/pcm: root@rock-5-itx:~# cat /proc/asound/pcm 00-00: rockchip-hdmi1 i2s-hifi-0 : rockchip-hdmi1 i2s-hifi-0 : playback 1 01-00: rockchip-hdmi0 spdif-hifi-0 : rockchip-hdmi0 spdif-hifi-0 : playback 1 02-00: rockchip-hdmi2 spdif-hifi-0 : rockchip-hdmi2 spdif-hifi-0 : playback 1 03-00: rockchip-hdmiin i2s-hifi-0 : 04-00: dailink-multicodecs ES8316 HiFi-0 : dailink-multicodecs ES8316 HiFi-0 : playback 1 : capture 1 05-00: fe4f0000.spdif-tx-dit-hifi dit-hifi-0 : fe4f0000.spdif-tx-dit-hifi dit-hifi-0 : playback 1 So the HDMI Input is still found (rockchip-hdmiin) but is not exposing any playback or capture jack So i tried to investigate and found that rockchip as changed the sound driver at some point as i found out here: https://zhuanlan.zhihu.com/p/664345417 (Link in Chinese) (I don't know if i can post link so let me know) Now i found that if i manualy install the 6.1.75 Kernel i found the device and i am able to record the audio: root@rock-5-itx:~# arecord -l **** List of CAPTURE Hardware Devices **** card 0: rockchiphdmiin [rockchip-hdmiin], device 0: rockchip-hdmiin i2s-hifi-0 [rockchip-hdmiin i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: rockchipes8316 [rockchip-es8316], device 0: dailink-multicodecs ES8316 HiFi-0 [dailink-multicodecs ES8316 HiFi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 Anyone can't test this? Maybe is for all the RK3588 or only the Radxa 5 ITX.

The HDMI0(Port next to Headphone Jack) is driven by DP1 on rk3588 via RA620(a dp2hdmi converter). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/rockchip?h=v6.18&id=07c53a9e970712b1a479dd0ec4adfe184482c22f ROCKCHIP_DW_DP is needed in order to have working 2nd HDMI port. In menuconfig : Device Drivers ---> Direct Rendering Manager (XFree86 4.Graphics support ---> 1.0 and higher DRI support) ---> Rockchip specific extensions for Synopsys DW DP <pre> │ CONFIG_ROCKCHIP_DW_DP: │ │ │ │ This selects support for Rockchip SoC specific extensions │ │ to enable Synopsys DesignWare Cores based DisplayPort transmit │ │ controller support on Rockchip SoC, If you want to enable DP on │ │ rk3588 based SoC, you should select this option. │ │ │ │ Symbol: ROCKCHIP_DW_DP [=n] │ </pre> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi?h=v6.18&id=64566e35757faded57a65d65e84b5ca95974ee19

I installed Debian 12 (Bookworm)XFCE from the official Armbian website onto the NVME SSD of the board. Everything works fine except the 4 hard drives that are connected to boards SATA connectors. They do appear and work when i boot into the Debian provided by Radxa, so I know hardware isn't an issue. I think that they also worked during the very first boot of the system but after ``` apt update && apt upgrade ``` and reboot, they stop working. Any advice would be much appreciated. ``` rock-5-itx:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mtdblock0 31:0 0 16M 0 disk mmcblk0 179:0 0 7.3G 0 disk mmcblk0boot0 179:32 0 4M 1 disk mmcblk0boot1 179:64 0 4M 1 disk zram0 252:0 0 11.6G 0 disk [SWAP] zram1 252:1 0 50M 0 disk /var/log zram2 252:2 0 0B 0 disk nvme0n1 259:0 0 476.9G 0 disk └─nvme0n1p1 259:1 0 472.1G 0 part /var/log.hdd / ``` https://paste.armbian.com/qiwimusofo

If any of you have experienced skipping and popping when seeking with vlc, you can try setting the audio sink to ALSA and one of the rockchip-es8316 options. That will smooth out the audio playback BUT you will quickly discover that anything pulseaudio related is locked out of using the soundcard while vlc is up. Instead, try this. Set vlc audio back to pulseaudio (or automatic, seems to map to the same thing) and then change these two lines in /etc/pulse/daemon.conf: -; default-sample-rate = 44100 -; alternate-sample-rate = 48000 +default-sample-rate = 48000 +alternate-sample-rate = 44100 Restart pulseaudio with systemctl --user restart pulseaudio and see if vlc plays nice with everything else as well as supporting smooth playback after seeking. It does for me. It seems that forcing pulseaudio to resample causes all sorts of hilarity (vlc seems to like putting everything out at 48000). I'm sure there's a reason why. I'm also sure if I know, I'll be sorry I do. I wonder, how hard is it to get the Vulkan video hardware decoding working? Has anyone gotten it to work?

Dear all, I got myself an Radxa Rock 5 ITX+ as I thought I'd saw that this board had premium support. After it arrived, I saw that only the ITX (non-plus) variant had premium support, which since latest Armbian release some days ago seems to has been downgraded to standard support. I cleared both the eMMC and SPI flash to make sure the preinstalled OS were gone and would not interfere with the boot up process. Then I built myself a latest image with trixie and vendor kernel but I realized that (after booting from sdcard successfully), the Nvme was never picked up. The ITX+ has two M.2 full-size slots instead of only one - and is missing the SATA controller instead. To make sure I did nothing wrong with the building process I grabbed myself some old images like e.g. Armbian_24.11.1_Rock-5-itx_bookworm_vendor_6.1.75_cinnamon-backported-mesa_desktop.img.xz Armbian_25.2.2_Rock-5-itx_bookworm_vendor_6.1.99_cinnamon-backported-mesa_desktop.img.xz but they don't show working Nvmes either. So I got myself the latest nightly Trixie build (Rolling releases images with Armbian Linux v6.1 / Build Date: Sep 6, 2025 / Debian Debian 13 (Trixie)) from https://www.armbian.com/radxa-rock-5-itx/ and booted that, to also see that both populated Nvme slots are not picked up. lspci shows two Nvmes: 0000:01:00.0 Non-Volatile memory controller: Solid State Storage Technology Corporation NVMe SSD M.2 (rev 01) 0001:11:00.0 Non-Volatile memory controller: Solid State Storage Technology Corporation NVMe SSD M.2 (rev 01) Bot dmesg shows issues during boot: [ 14.165404] pci 0001:10:00.0: Primary bus is hard wired to 0 [ 14.165410] pci 0001:10:00.0: bridge configuration invalid ([bus 01-ff]), reconfiguring [ 14.165514] pci 0001:11:00.0: [1e95:3500] type 00 class 0x010802 [ 14.165568] pci 0001:11:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit] [ 14.165794] pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus 00-0f] (conflicts with (null) [bus 00-0f]) [ 14.165901] pci 0000:01:00.0: [1e95:3500] type 00 class 0x010802 [ 14.166009] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit] [ 14.166147] pci 0001:11:00.0: 15.752 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x2 link at 0001:10:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) [ 14.166379] cpu cpu6: l=15000 h=85000 hyst=5000 l_limit=0 h_limit=2208000000 h_table=0 [ 14.166699] pci_bus 0001:11: busn_res: [bus 11-1f] end is updated to 11 [ 14.166721] pci 0001:10:00.0: BAR 8: assigned [mem 0xf1200000-0xf12fffff] [ 14.166729] pci 0001:10:00.0: BAR 6: assigned [mem 0xf1300000-0xf130ffff pref] [ 14.166729] pci 0000:01:00.0: 15.752 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x2 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) [ 14.166737] pci 0001:11:00.0: BAR 0: assigned [mem 0xf1200000-0xf1203fff 64bit] [ 14.166785] pci 0001:10:00.0: PCI bridge to [bus 11] [ 14.166792] pci 0001:10:00.0: bridge window [mem 0xf1200000-0xf12fffff] [ 14.168281] pcieport 0001:10:00.0: PME: Signaling with IRQ 128 [ 14.168548] nvme nvme0: pci function 0001:11:00.0 [ 14.168576] nvme 0001:11:00.0: enabling device (0000 -> 0002) [ 14.176536] pci 0000:00:00.0: BAR 8: assigned [mem 0xf0200000-0xf02fffff] [ 14.176542] pci 0000:00:00.0: BAR 6: assigned [mem 0xf0300000-0xf030ffff pref] [ 14.176546] pci 0000:01:00.0: BAR 0: assigned [mem 0xf0200000-0xf0203fff 64bit] [ 14.176569] pci 0000:00:00.0: PCI bridge to [bus 01-ff] [ 14.176573] pci 0000:00:00.0: bridge window [mem 0xf0200000-0xf02fffff] [ 14.177418] pcieport 0000:00:00.0: PME: Signaling with IRQ 138 [ 14.177557] nvme nvme1: pci function 0000:01:00.0 [ 14.177582] nvme 0000:01:00.0: enabling device (0000 -> 0002) [ 14.181202] nvme nvme0: Removing after probe failure status: -19 [ 14.185702] cpu cpu6: EM: OPP:1008000 is inefficient [ 14.185716] cpu cpu6: EM: OPP:816000 is inefficient [ 14.185965] cpu cpu6: EM: created perf domain [ 14.190212] nvme nvme1: Removing after probe failure status: -19 ( full log: https://paste.next.armbian.com/labujaguke.yaml ) Any idea on how to fix this and get them working? That would be really lovely, Thanks a lot for all your support!

Hi, I’m new to the forum and just wanted to take a moment to appreciate the incredible work Armbian has done for the community. I have been tinkering around with Radxa rock 5 ITX SBC and Armbian. I flashed UEFI EDK2 for Radxa rock 5 ITX &nbsp;v1.1 from EDK2 porting to RK3588 initiative. While I can install ARM64 version of Ubuntu and Debian, none of them had support for H/W transcoding. So I decided to build an Armbian which used vendor kernel and had `uefi-edk2-3588` extension. Full build report is linked in this Armbian paste ./compile.sh \ BOARD=rock-5-itx \ RELEASE=trixie \ BRANCH=vendor \ BUILD_MINIMAL=yes \ BUILD_DESKTOP=no \ KERNEL_CONFIGURE=no \ NETWORKING_STACK=systemd-networkd \ EXPERT=yes \ CLEAN_LEVEL=extras \ ENABLE_EXTENSIONS=mesa-vpu,uefi-edk2-rk3588 \ KERNEL_BTF=yes \ SHARE_LOG=yes \ CONSOLE_AUTOLOGIN=no \ build I flashed the resulting image to a usb stick and booted system off it. This is when I had encountered problems. armbian-upgrade complained about a readonly system root@rock-5-itx:~# armbian-upgrade Hit:1 http://deb.debian.org/debian trixie InRelease Hit:2 http://deb.debian.org/debian trixie-updates InRelease Hit:3 http://security.debian.org trixie-security InRelease Hit:4 http://deb.debian.org/debian trixie-backports InRelease Hit:5 https://github.armbian.com/configng stable InRelease Ign:6 http://mirror.twds.com.tw/armbian-apt trixie InRelease Err:7 http://mirror.twds.com.tw/armbian-apt trixie Release Could not open file /var/lib/apt/lists/partial/apt.armbian.com_dists_trixie_Release - open (30: Read-only file system) [IP: 103.147.22.36 80] Warning: chown to _apt:root of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (30: Read-only file system) Warning: chmod 0700 of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (30: Read-only file system) Warning: chown to _apt:root of directory /var/lib/apt/lists/auxfiles failed - SetupAPTPartialDirectory (30: Read-only file system) Warning: chmod 0755 of directory /var/lib/apt/lists/auxfiles failed - SetupAPTPartialDirectory (30: Read-only file system) Warning: Not using locking for read only lock file /var/lib/apt/lists/lock Warning: Problem unlinking the file /var/lib/apt/lists/partial/.apt-acquire-privs-test.foxhPQ - IsAccessibleBySandboxUser (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/.apt-acquire-privs-test.ZQLLDs - IsAccessibleBySandboxUser (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/.apt-acquire-privs-test.k64ifr - IsAccessibleBySandboxUser (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/.apt-acquire-privs-test.kWgd4F - IsAccessibleBySandboxUser (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/.apt-acquire-privs-test.pSkidL - IsAccessibleBySandboxUser (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/.apt-acquire-privs-test.PoF76X - IsAccessibleBySandboxUser (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/deb.debian.org_debian_dists_trixie_InRelease - PrepareFiles (30: Read-only file system) Warning: chown to _apt:root of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: chmod 0600 of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/deb.debian.org_debian_dists_trixie-updates_InRelease - PrepareFiles (30: Read-only file system) Warning: chown to root:root of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie_InRelease failed - 201::URIDone (30: Read-only file system) Warning: chmod 0644 of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie_InRelease failed - 201::URIDone (30: Read-only file system) Warning: chown to _apt:root of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: chmod 0600 of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/security.debian.org_dists_trixie-security_InRelease - PrepareFiles (30: Read-only file system) Warning: chown to root:root of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_InRelease failed - 201::URIDone (30: Read-only file system) Warning: chmod 0644 of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_InRelease failed - 201::URIDone (30: Read-only file system) Warning: chown to _apt:root of file /var/lib/apt/lists/security.debian.org_dists_trixie-security_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: chmod 0600 of file /var/lib/apt/lists/security.debian.org_dists_trixie-security_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: chown to root:root of file /var/lib/apt/lists/security.debian.org_dists_trixie-security_InRelease failed - 201::URIDone (30: Read-only file system) Warning: chmod 0644 of file /var/lib/apt/lists/security.debian.org_dists_trixie-security_InRelease failed - 201::URIDone (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/deb.debian.org_debian_dists_trixie-backports_InRelease - PrepareFiles (30: Read-only file system) Warning: chown to _apt:root of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-backports_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: chmod 0600 of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-backports_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/github.armbian.com_configng_dists_stable_InRelease - PrepareFiles (30: Read-only file system) Warning: chown to root:root of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-backports_InRelease failed - 201::URIDone (30: Read-only file system) Warning: chmod 0644 of file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-backports_InRelease failed - 201::URIDone (30: Read-only file system) Warning: chown to _apt:root of file /var/lib/apt/lists/github.armbian.com_configng_dists_stable_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: chmod 0600 of file /var/lib/apt/lists/github.armbian.com_configng_dists_stable_InRelease failed - Item::QueueURI (30: Read-only file system) Warning: chown to root:root of file /var/lib/apt/lists/github.armbian.com_configng_dists_stable_InRelease failed - 201::URIDone (30: Read-only file system) Warning: chmod 0644 of file /var/lib/apt/lists/github.armbian.com_configng_dists_stable_InRelease failed - 201::URIDone (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/apt.armbian.com_dists_trixie_InRelease - PrepareFiles (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/partial/apt.armbian.com_dists_trixie_Release - PrepareFiles (30: Read-only file system) Error: The repository 'http://apt.armbian.com trixie Release' no longer has a Release file. Notice: Updating from such a repository can't be done securely, and is therefore disabled by default. Notice: See apt-secure(8) manpage for repository creation and user configuration details. Warning: Problem unlinking the file /var/lib/apt/lists/github.armbian.com_configng_dists_stable_main_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie_main_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie_contrib_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie_non-free_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie_non-free-firmware_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_contrib_binary-arm64_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_main_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_non-free-firmware_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_non-free_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_contrib_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_non-free_binary-arm64_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-updates_non-free-firmware_binary-arm64_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-backports_non-free_binary-arm64_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-backports_non-free-firmware_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-backports_non-free_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-backports_contrib_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/deb.debian.org_debian_dists_trixie-backports_main_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/security.debian.org_dists_trixie-security_non-free_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/security.debian.org_dists_trixie-security_main_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/security.debian.org_dists_trixie-security_non-free-firmware_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/security.debian.org_dists_trixie-security_contrib_binary-all_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/security.debian.org_dists_trixie-security_non-free-firmware_binary-arm64_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/security.debian.org_dists_trixie-security_non-free_binary-arm64_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Problem unlinking the file /var/lib/apt/lists/security.debian.org_dists_trixie-security_contrib_binary-arm64_Packages - TransItem::TransactionCommit (30: Read-only file system) Warning: Not using locking for read only lock file /var/lib/dpkg/lock-frontend Warning: Not using locking for read only lock file /var/lib/dpkg/lock Error: Archives directory /var/cache/apt/archives/partial is missing. - Acquire (2: No such file or directory) Warning: chown to _apt:root of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (30: Read-only file system) Warning: chmod 0700 of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (30: Read-only file system) Warning: chown to _apt:root of directory /var/lib/apt/lists/auxfiles failed - SetupAPTPartialDirectory (30: Read-only file system) Warning: chmod 0755 of directory /var/lib/apt/lists/auxfiles failed - SetupAPTPartialDirectory (30: Read-only file system) Warning: Not using locking for read only lock file /var/lib/apt/lists/lock Warning: Not using locking for read only lock file /var/lib/dpkg/lock-frontend Warning: Not using locking for read only lock file /var/lib/dpkg/lock Error: Archives directory /var/cache/apt/archives/partial is missing. - Acquire (2: No such file or directory) armbian-install only shows /dev/ but lsblk and blkid can see all drives. I am sorry for the long post.

Hello. I want to try UEFI boot on this board. And I have one question. Can I use Rockchip vendor kernel with Armbian UEFI?

Armbian_25.2.2_Rock-5-itx_noble_vendor_6.1.99_gnome_desktop.img.xz I first tried this, as it was the first version offered at the top of the page. No matter what I tried, sound would *not* work. Not speakers, not HDMI, nada, zip. I then started trying earlier versions further down the page. Armbian_25.2.2_Rock-5-itx_bookworm_vendor_6.1.99_cinnamon-backported-mesa_desktop.img.xz And this one, sound *did* work, at least through the speaker jack anyway, but I suspect HDMI would too. I'm really suspecting something kernel related is going here (that "Rockchip BSP" note right above it makes me suspect that). In any case, I'd like to use the kernel where sound is working and put a gnome shell in front of it. Which I take means digging into the build system for armbian? I can figure that out on my own but before I get started on that, what I'm looking for from the forumistas, is an indication of which specific kernel I need to use to make sure sound works. What do I need to make sure to specify so I get the behavior of that second install that worked? And Cinnamon may be better or something, but gnome is what I'm used to.

I had this plan on utilizing the Radxa Rock 5 ITX+ as a Moonlight client device to stream games from my desktop computer to my living room TV, and using my 8BitDo Ultimate controller to play. On paper, the board has all the bells and whistles needed to do it, but I am having trouble getting hardware decoding of H264 and/or HEVC to work as expected. From what I gather, I need mesa-vpu support, but the documentation I find is very scattered, and repositories that once held the needed resources are no longer available. I am currently running Armbian_25.DBhsHKsx.2.2_Rock-5-itx_bookworm_vendor_6.1.99_cinnamon-backported-mesa_desktop.img (build date 21st of February, 2025), downloaded from Armbian.com. Hardware decoding does however not work, despite it being marked with "backported mesa". I've been at this for two weeks now with different images, including Armbian and Radxa OS, even going so far as trying to build Armbian myself from scratch. The image I am currently using is however the most stable I have experienced so far. Am I missing something? How do I get hardware decoding to work? Edit: Link to armbianmonitor output

I got a 6.1 noble minimal image installed with a latest kubuntu update to KDE 6. Was quite some work to get this all working. But some thing aren't working (e.g. audio?). 6.12 and later supports a range more peripherals. I tried the non-vendor images but no go. How do I install one of those? (Not using ROOBI, I hacked this to use my own)

Has anyone made (or bought!) an adapter that takes the 3 pin TTL-level console port and converts it to a DB9 or RJ45 port that can mount in a PCI bracket? If so, what did you use? And what port did you use to power it as the console port does not provide a 3.3V or 5.5V pin for power (there is a pin labeled "RSV" which seems to supply 5V and may be usable but I don't know its capabilities). I've done this before for other systems using these without too much trouble but when I tried with this board it's not working. Admittedly I haven't hooked it up to a scope to look at the signals, but I'm suspicious of the high baudrate being to blame. I have a couple USB adapters that work (so I know the console itself works), but I want to rackmount this box and wire it up to my console server. I need RS232 to do that.

Hi, I am currently using rock-5-itx to setup a NAS. Everything is working fine. uname -a: Linux amberbyte 6.1.75-vendor-rk35xx #1 SMP Thu Nov 28 03:16:11 UTC 2024 aarch64 GNU/Linux Now, I wanted to update RKNPU version from 0.9.7 to 0.9.8. So, again I recompiled the image with the updated drivers. Using Pi-imager flashed it onto an SD card. When I tried to boot I am getting the following error message from the serial output: ./compile.sh build BOARD=rock-5-itx BRANCH=vendor BUILD_DESKTOP=no BUILD_MINIMAL=yes EXPERT=yes KERNEL_CONFIGURE=yes RELEASE=bookworm DDR 9fffbe1e78 cym 24/02/04-10:09:20,fwver: v1.16 LPDDR5, 2400MHz channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB Manufacturer ID:CH0 RX Vref:26.3%, TX Vref:21.0%,21.0% CH1 RX Vref:27.1%, TX Vref:22.0%,22.0% CH2 RX Vref:27.1%, TX Vref:24.0%,21.0% CH3 RX Vref:27.5%, TX Vref:21.0%,20.0% change to F1: 534MHz change to F2: 1320MHz change to F3: 1968MHz change to F0: 2400MHz out U-Boot SPL board init U-Boot SPL 2017.09-armbian-2017.09-S2284-P8c48-Hfac6-Ve5ad-Bda0a-R448a (Nov 20 2024 - 17:06:35) Trying to boot from MMC2 spl: partition error Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK ## Checking uboot 0x00200000 ... sha256(af1962bdff...) + OK ## Checking fdt 0x00324010 ... sha256(e3b0c44298...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC ## Checking atf-2 0xff100000 ... sha256(70505bb764...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC ## Checking atf-3 0x000f0000 ... sha256(b2af21b504...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000) Total: 813.644/1063.106 ms INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-868-g040d2de11:derrick.huang, fwver: v1.48 NOTICE: BL31: Built : 15:02:44, Dec 19 2024 INFO: spec: 0x1 INFO: code: 0x88 INFO: ext 32k is not valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: l3 cache partition cfg-0 INFO: system boots from cpu-hwid-0 INFO: disable memory repair INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2400MHz INFO: dfs DDR fsp_params[1].freq_mhz= 534MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1320MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1968MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 No valid device tree binary found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb> initcall sequence 00000000002b8500 failed at call 00000000002aaf6c (err=-1) ### ERROR ### Please RESET the board ### I get the same error when I use the desktop image too: ./compile.sh build BOARD=rock-5-itx BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_APPGROUPS_SELECTED='browsers desktop_tools internet programming' DESKTOP_ENVIRONMENT=gnome DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base EXPERT=yes KERNEL_CONFIGURE=yes RELEASE=bookworm But when I use the image downloaded from the armbian website is getting booted up without any issue and it has updated RKNPU drivers. But I have to build a kernel because I want the LSI MEGARAID drivers enabled. Also when I want to make RKNPU driver modular <M> it is unable to finish building the image with an error saying it is unable to find rknpu.ko. So, why is this happenning and is there a way to update the drivers without going through building the kernel? Thank you in advance and any help will be helpful.

Hi, I can not get the back panel audio working, the HDMI analog audio to my display works, but changing the output to Analog out is not working. Any suggestions as to where I can start to troubleshoot? Thanks!

Hi, I am wanting to try running OPNsense under proxmox, but before that I wanted to setup the type-C port as a management port. I have added g_cdc in /etc/modules to load the kernel module and if I run a vendor kernel, it works fine. I plug my laptop in to the boards type-C port and it shows up as an ethernet adapter and I can SSH directly to the Rock 5 ITX. I however would like to use a mainline kernel instead as it generally runs better thanks to the amazing work of the community here. Running 6.12, this same functionality does not work and nothing appears in the network adapters on my laptop when plugging in. Looking on mainline-status, I see that the type-C support (ie USB-C (fusb302)), has been sent but not accepted yet. Once this has been merged and I update to the newest kernel, will the type-C port work like I hope? Any help or advice would be much appreciated!

Hello, I'm quite new to SBC and linux. On one hand I'm learning a lot, but on the other hand I'm struggling to make it work as I would like. I already have a low performance Zimaboard (just 2GB Ram) that I use as a NAS and I want the ROCK 5 ITX 8GB to be used as a general purpose apps server for home automation, streaming music, listening music, etc. One of my use case I'm playing with is the following: 1) music files are on the NAS 2) Music files are played from the Rock5 ITx via the speakers plugged into the headphone jack, 3) The music player is controlled remotely using Lyrion Music Server + Squeezelite. I've already tested the above using the official rock-5-itx_bookworm_kde_b3.output.img.xz image and it works: no rocket science . Unfortunately the vendor official image is not very stable: the docker containers crash randomly and even if the SATA drives are detected and mounted at boot time, the got disconnected randomly after some hours. That's why I decided to go experimental and now I'm playing with the following setup and 6 containers running: OS: Armbian-unofficial 25.05.0-trunk bookworm aarch64 ?******************; Host: Radxa ROCK 5 ITX '*n` .'`^,;;,^`'. ,cc. Kernel: Linux 6.15.0-rc1-edge-rockchip64 !^ ^^ ": Shell: bash 5.2.15 Itttt?' ~~]rr] `{tttt, Terminal: /dev/pts/0 \tttttt!""I_]r("""~tttttt1 CPU: rk3588 (8) @ 2.40 GHz '_tttttttttttt)ftttttttttttti. GPU: Rockchip rk3588-mali [Integrated] \*ztttttttttttttttttttttttttf**[ Memory: 1.80 GiB / 7.75 GiB (23%) l**c)tttttttttttttttttttttttt(z**, Swap: 0 B / 3.87 GiB (0%) .z*x.`tttttttttttttttttttttttt.`u*n Disk (/): 11.90 GiB / 232.35 GiB (5%) - ext4 >` (tttttttttttttttttttttt] "I Disk (/media/bidone): 44.76 GiB / 3.58 TiB (1%) - ext4 ,tttttttttttttttttttttt` Disk (/var/log): 5.31 MiB / 46.84 MiB (11%) - ext4 ./tttttfttttttttfttttt( Local IP (wlP2p33s0): 192.168.X.X 'I)))(\()(tt))|\()({;' Locale: it_IT.UTF-8 Coming back to the play-music-locally use-case, I've a problem with the sound card because I cannot hear the audio. Here the output from Armbianmonitor: https://paste.armbian.com/apaxoburiz I've both ALSA and PulseAudio. Alsamixer works: Hereunder other outputs, but I'm not expert enough to understand what's going on and why audio is not played by the speakers plugged to the board. No sound with "speaker-test" and "/etc/modprobe.d/sound.conf" doesn't exsist. HDMI audio is not detected, but I can live without for the moment. cat /proc/asound/cards 0 [rk3588es8316 ]: rk3588-es8316 - rk3588-es8316 rk3588-es8316 sudo dmesg | grep 'snd\|audio\|firmware' [ 0.000000] psci: PSCIv1.1 detected in firmware. [ 0.150543] /i2c@fec90000/audio-codec@11: Fixed dependency cycle(s) with /i2s@fe470000 [ 1.495212] /i2s@fe470000: Fixed dependency cycle(s) with /i2c@fec90000/audio-codec@11 [ 1.495240] /i2c@fec90000/audio-codec@11: Fixed dependency cycle(s) with /i2s@fe470000 [ 15.623287] rtw89_8852be 0002:21:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin inxi -A Audio: Device-1: audio-graph-card driver: asoc_audio_graph_card Device-2: rk3588-dw-hdmi-qp driver: dwhdmiqp_rockchip API: ALSA v: k6.15.0-rc1-edge-rockchip64 status: kernel-api Server-1: PulseAudio v: 16.1 status: active aplay -l **** List of PLAYBACK Hardware Devices **** card 0: rk3588es8316 [rk3588-es8316], device 0: fe470000.i2s-ES8316 HiFi ES8316 HiFi-0 [fe470000.i2s-ES8316 HiFi ES8316 HiFi-0] Subdevices: 0/1 Subdevice #0: subdevice #0 alsactl init alsa-lib parser.c:2783:(load_toplevel_config) Unable to find the top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'. alsa-lib main.c:1541:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2 Found hardware: "rk3588-es8316" "" "" "" "" Hardware is initialized using a generic method Thank you: advices are appreciated.

Hello, here with a Radxa Rock 5 ITX I experience endless loading at reboot after some system upgrades... But not always. Am I doing something wrong by using the command reboot from ssh ? instead of shutdown and power up ? In that case the system loads to rescue mode, asking for the root password and even if entered correctly does not identify. All comes back to working state with a shutdown and a reboot. Notice : I've made a donation to support the team. Please help.

I'm using a Rock 5 ITX and noticed after installing the latest rk35xx kernel image (6.1.84-vendor-rk35xx) that my system wasn't booting. So I connected to the debug console and observed a kernel oops being emitted. It dumps out a few pages of data, but the initial messages and call trace are: I have all the hex data if someone would use it but it doesn't seem worth including here. The boot flounders around in systemd for a bit but never gets to a login prompt - and I'm not that savvy with uboot to enter single user mode or otherwise dig in more. So I reinstalled from nothing, upgraded all my packages (including the vendor-rk35xx kernel), rebooted, and everything was ok - until I installed zfs-dkms and built the zfs module and rebooted - at which time I got back into the same busted position. And that's where I am now. I suppose I could go without zfs but I've been using it for a couple decades now and prefer it over the alternatives. As I'm not doing anything critical with this system yet, I don't mind futzing around and providing data or otherwise helping to debug what's up. At least for a few days. It does run my jellyfin instance, but I have plex running on another system so I'm too put out. A few months ago something similar (but different!) occurred after a rk35xx kernel upgrade but in that case, the system would at least boot to a login prompt eventually where I was able to downgrade the kernel and get it working again - and then the next version of the package fixed the problem. But in this case, it is effectively bricking the system for me (I'm sure someone that knows more about uboot could interrupt the boot and maybe recover things) to where I just reinstall - but that's not a good way to iterate and test fixes. I run the rk35xx vendor kernel because jellyfin has support for hardware transcoding when using that kernel - and as far as I know it does not when running against mainline - but this vendor kernel seems to be... less than stable! Any advice?

Hi, this week my Rock 5 ITX+ board arrived and I started installing Armbian with vendor kernel (now on 6.1.99-vendor-rk35xx). This board has slightly different hardware than the original ITX. It has two M.2 M-key (2-lanes) instead of one M.2 M-key and four SATA ports. I think because of the different hardware configuration the DTB has to be changed as no SATA controller is present on the board. With the ITX DTB I am experiencing problems with not regonizing NVME disks when activating ASPM in armbianEnv.txt. I have no experience in editing DTBs or applying patches, so I need help to figure out what to do to make things work. armbianmonitor log: https://paste.next.armbian.com/asoxunogeg Thanks Thomas

I I'm getting a 502 Bad gateway when I'm trying to run apt update on the http://apt.armbian.com/dists/noble/InRelease repository. I checked the forum and didn't see a server maintenance notice. And the arbianmonitor seems to fail to post the report too. Is there an infrastructure problem?

Hi there, I wanted to know if anyone know if there are any power limits from the SATA power ports, the question is can you power 1 or more 3.5" NAS disks at the same time? Or as a precaution, I take power from the PSU? Thanks, Dany