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

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.

So I'm fairly new to Armbian (although I have already managed to successfully create a custom build with most of what I need). Sadly, I've very much hit a blocker. I really need to use linux-tools/perf on an RK3588 board with a vendor kernel (I'm using the Mali OpenCL, and the ARM packages are mostly locked) and I need to do some performance tuning. I cannot figure out how to get these tools deployed. 1. There are no linux-tools packages build -- which is fair enough, I'm probably in a minority. Some parts of the tools directories are culled during a cleaning process for the headers, I can see that 2. I am happy to copy over the kernel source and build on the device, but this is a patched vendor kernel. Can I just rsync across `cache/sources/linux-kernel-worktree`? Is that the patched kernel source tree? 3. There are some old allusions in the forums to using armbian-config to get sources -- I'm guessing that's long deprecated 4. Would it be appropriate at some point to create a .deb for the actual kernel sources, just in case -- or even, ideally, the linux-tools packages themselves? I am very happy to invest effort into helping make this happen, but I am starting from cold into this fairly complex build infrastructure, so any help or pointers I'd be extremely grateful.

Hello I have burned bookworm onto a sd card,booted on it with a Rock 5B+ and installed the bootloader on the SPI flash of the board and transferred the OS to the nvme drive. Now I I'm trying to install the new trixie image, but I can't burn it on my nvme drive. With USBImage it does not work. It doesn't detect my nvme drive installed on my USB adapter. With belena Etcher it throws an error during the validation of the image. Win32Imager doesn't load at all on Windows 11. I don't know which other tool (Windows) I could use. I'm stuck. How can I boot again from my SD card on a Rock 5b+?

Was on the edge vendor kernel and now swapped to 6.1.115-vendor-rk35xx And i just cant seem to get full hardware functionality with Jellyfin, Specifically tone mapping and subtitle burning crash. Atleast the tone mapping seems to be a lack of /dev/mali0 Is there a kernal or version that has all the drivers / firmware support for a fully jellyfin use? Sorry if I'm mincing words.

Hey everyone, for the past couple of days I've been looking into the Mesa-VPU script made by AmazingFate that's used to patch Mesa/VPU onto a custom build of Armbian. https://github.com/armbian/build/blob/main/extensions/mesa-vpu.sh I already have an install of Armbian (Debian XFCE 6.12.28-current-rockchip64 ) on my Rock5b and was looking into applying as much as I can without re-building an image or starting from scratch. From my understanding, You'd need the vendor rk3588 kernel if you want the best possible compatibility with things like the VPU for multimedia acceleration (Someone please correct me if this is not the case lol) What follows is what I was able to piece together after troubleshooting, reading the Mesa changelog & trying to apply as many packages as I can from AmazingFate's kernel extension script. I've also included some tweaks for XFCE to hopefully provide a smooth graphical experience. Although my Rock5b is used as a headless server and doesnt have anything plugged into the HDMI port, I can say that the following changes have made a huge difference in graphical performance of VNC. Please keep in mind that i'm not a developer for Armbian. I just wanted to share this as a guide i've put together to hopefully help someone else who's tried the same (Please let me know your thoughts or if there was anything i've missed. Like I said, this is what has worked for me) (Obviously the correct fix is to rebuild Armbian with Mesa-VPU. What follows was done as an experiment) #################### GUIDE BELOW. THIS IS NOT A SHELL SCRIPT! PLEASE READ AND DO NOT COPY/PASTE ENTIRETY INTO TERMINAL!############################# #### -- 01 Setup AmazingFate Panfork-Mesa repo for mali-g610-firmware 01 -- #### ## 1A: import gpg key and use it to sign repo ## wget -qO - https://download.opensuse.org/repositories/home:/amazingfate:/panfork-mesa/Debian_12/Release.key | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/panfork-mesa.gpg ## 1B: Add Repo to apt sources & update ## echo "deb https://download.opensuse.org/repositories/home:/amazingfate:/panfork-mesa/Debian_12/ /" | sudo tee /etc/apt/sources.list.d/panfork-mesa.list sudo apt update ## 1C: Install firmware ## sudo apt install mali-g610-firmware libmali-g610-x11 ## 1D: **RECOMMENDED** : Remove panfork-mesa repo ## sudo rm -rf /etc/apt/sources.list.d/panfork-mesa.list sudo rm -rf /etc/apt/trusted.gpg.d/panfork-mesa.gpg #### -- 02 Enable Debian Experimental Repo for recent Mesa Packages 02 -- #### sudo nano /etc/apt/sources.list ## 2A: Add the following to the bottom of the document... ## deb http://deb.debian.org/debian unstable main contrib non-free deb http://deb.debian.org/debian experimental main ## 2B: Update and install Mesa Packages ## sudo apt update sudo apt install -t experimental mesa-vulkan-drivers mesa-utils libgl1-mesa-dri libglx-mesa0 mesa-vdpau-drivers mesa-va-drivers mesa-opencl-icd mesa-libgallium ## 2C: **RECOMMENDED** : Re-open apt sources and remove Experimental/Unstable repos... ## sudo nano /etc/apt/sources.list #Remove the following and update apt...# deb http://deb.debian.org/debian unstable main contrib non-free deb http://deb.debian.org/debian experimental main sudo apt update #### -- 03 Add rockchip-multimedia Ubuntu Repo to Apt 03 -- #### echo "deb [arch=arm64] https://ppa.launchpadcontent.net/liujianfeng1994/rockchip-multimedia/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/rockchip-multimedia.list ## 3A: Download Key and add convert to gpg ## curl -o rockchip-multimedia.asc "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x8065BE1FC67AABDE" gpg --dearmor rockchip-multimedia.asc sudo mv rockchip-multimedia.asc.gpg /etc/apt/keyrings/rockchip-multimedia.gpg ## 3B: Add PPA Repo and update ## echo "deb [arch=arm64 signed-by=/etc/apt/keyrings/rockchip-multimedia.gpg] https://ppa.launchpadcontent.net/liujianfeng1994/rockchip-multimedia/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/rockchip-multimedia.list sudo apt update ## 3C: Install packages ## sudo apt install libv4l-rkmpp chromium gstreamer1.0-rockchip1 rockchip-multimedia-config ## 3D: **OPTIONAL** : Disable rockchip-multimedia PPA repo ## sudo mv /etc/apt/sources.list.d/rockchip-multimedia.list /etc/apt/sources.list.d/rockchip-multimedia.list.disabled sudo apt update #### -- 04 Optimize XFCE/Xorg and Reboot 04 -- #### ## 4A: Open default xorg config ## sudo nano /etc/X11/xorg.conf.d/01-armbian-defaults.conf #Add the following... # Section "Device" Identifier "Mali-G610" Driver "modesetting" Option "DRI" "3" # Required for Mali GPUs Option "GALLIUM_DRIVER" "panfrost" Option "PageFlip" "on" # Reduces tearing Option "TearFree" "true" # Xfce-specific anti-tearing EndSection ## 4B: Add XFCE Specific tweaks ## sudo nano /etc/X11/xorg.conf.d/20-xfce-tweaks.conf #Add the following... # Section "Extensions" Option "COMPOSITE" "Enable" EndSection Section "ServerFlags" Option "AutoAddGPU" "off" # Prevents duplicate GPU detection EndSection ## 4C: Reboot ## sudo reboot now

I am attempting to set up rock-5b-plus to use as a Desktop device, with OBS Studio for livestreaming. My ultimate objective is that I wish to plug an HDMI signal (from a camera) into the HDMI input (`hdmiin`) and use this as a "Video Capture Device" for livestreaming from the camera. Steps I have taken so far: 1. Written this to the microSD card: `Armbian_25.2.2_Rock-5b-plus_bookworm_vendor_6.1.99_cinnamon-backported-mesa_desktop.img.xz` downloaded via [this link](https://dl.armbian.com/rock-5b-plus/Bookworm_vendor_cinnamon-backported-mesa) available [here](https://www.armbian.com/rock-5b-plus/). I opted for this one as it appeared to include software to run MESA 2. Booted the rock-5b-plus from the microSD card and gone through first-time setup as well as running `sudo apt update && sudo apt upgrade -y` 3. Opened a Desktop UI on the computer and run `sudo apt install obs-studio -y` 4. On running obs-studio, observe the error message "Failed to initialise video. Your GPU may not be supported, or your graphics driver may need to be updated". 5. Set about trying to install `mali-g610-firmware` using this link for guidance: 6. Run the following to install amazingfate's signing keys: ``` wget -qO- https://build.opensuse.org/projects/home:amazingfate/signing_keys/download?kind=gpg | sudo gpg --dearmor -o /etc/apt/keyrings/obs-home-amazingfate.gpg ``` 7. Append the following to `/etc/apt/sources.list` (although if mesa-bookwork-backport is already in the distro then I'm not sure why I need to do this) ``` deb [signed-by=/etc/apt/keyrings/obs-home-amazingfate.gpg] https://download.opensuse.org/repositories/home:/amazingfate:/mesa-bookworm-backport/Debian_12/ ./ ``` 8. Then update / upgrade / install ``` sudo apt update && sudo apt upgrade -y sudo apt install mali-g610-firmware ``` But it tells me `E: Unable to locate package mali-g610-firmware`. Here is some useful info: ``` chrishobcroft@rock-5b-plus:~$ cat /etc/apt/sources.list deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware #deb-src http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware #deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware deb http://deb.debian.org/debian bookworm-backports main contrib non-free non-free-firmware #deb-src http://deb.debian.org/debian bookworm-backports main contrib non-free non-free-firmware deb http://security.debian.org/ bookworm-security main contrib non-free non-free-firmware #deb-src http://security.debian.org/ bookworm-security main contrib non-free non-free-firmware deb [signed-by=/etc/apt/keyrings/obs-home-amazingfate.gpg] https://download.opensuse.org/repositories/home:/amazingfate:/mesa-bookworm-backport/Debian_12/ ./ ```

Hi, picked up a Rock 5b+ as it looked like the exact right board hardware wise and the rk3588 is getting a reasonable amount of support and happy to see it's officially supported by Armbian. Was able to build and flash the UEFI image and boot into the Fedora installer which would allow a RAID install but unfortunately it doesn't support either the PCIe bifurcation needed for both m.2 slots to work or the hardware acceleration for transcoding. It looks like there's progress being made by Collabora so eventually mainline support should be good enough but for now I'm looking to use Armbian with the BSP kernel as able to boot into it with both drives being detected. Had a look but couldn't seem to find any guides on how to install Armbian to two mirrored drives, could probably get by with one drive but it's going to be located at my parent's house 100 miles away so ideally would want to avoid a failed SSD needing an impromptu day's travel when I'm revising for exams! Happy to learn the build process, manual copy file trees, edit fstab and boot parameters, etc but could do with being pointed in the right direction or at least know if it's a lost cause. It looks like uboot supports mirrored boot disks, and Debian definitely does, so feels like it should be possible even if it's not a typical install. Thanks!

Hey Everyone, I'm sorry if this has been answered elsewhere. I recently purchased a Radxa Rock 5B+ and I installed the debian bookworm test build provided by radxa on there getting started page. https://docs.radxa.com/en/rock5/rock5b/getting-started/install-os/boot_from_sd_card https://github.com/radxa-build/rock-5b-plus-6_1/releases/download/rsdk-t4/rock-5b-plus-6_1_bookworm_kde_t4.output.img.xz I was mainly intent on using the HDMI with gstreamer using custom resolutions, but found that when using custom resolutions they cannot use the YCrCb pixel format only RGB8. It seems based on the following comment that RGB8 videoconvert hardware acceleration is missing from the default GPU drivers so one needs custom drivers. https://forum.radxa.com/t/hdmi-input-on-rock-5b/16242/4 https://forum.radxa.com/t/rk3588-kodi-rkmpp-accelerated-decoding-working-out-of-box/12785 Looking at the ppa they want you to add it seems like it only supports ubuntu and reading more they recommend you install armbian jammy on the rock 5B. I did find one github repo that appears to have the raw scripts related to rockchip-multimedia-config and a folder called debian https://github.com/amazingfate/rockchip-multimedia-config But looking at the files it seems like it relies on the device-tree files, which I feel may be different between the 5B and 5B+. So my two questions are 1) is there a working build of armbian ubuntu jammy or noble, that will install on the Rock 5B+ and work as well as it does for the Rock 5B. 2) Does anyone know if the rockchip-multimedia-config ppa with custom drivers will work on the Rock 5B+ ? Any other tips you all may have would be much appreciated. If I can provide any more details from my end just let me know.

Hi all, https://paste.armbian.com/koqimivaro vendor kernel boots, detects ethernet, wifi & nvme (booting from SD card) and seem to be working well. Also attached are the UART gathered first boot/install logs. I think the SBC accidentally skipped over the root password by resting on the enter key 😁 uart-logs.txt