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

Hi I managed to fix an issue with the usb-c port of the orange pi 5 plus. It seems the device is not activated unless you put it in host mode yourself: as user root: echo host >/sys/kernel/debug/usb/fc000000.usb/mode I have tried a usb-c network card and usb stick. Both work after this command! I noticed this when I installed the 6.1.115-vendor-rk35xx kernel. This one does not need this setting, it switches automatically from device mode to host and vice versa. I had alot of problems with analog sound on older kernels, e.g. youtube just hangs unless you mute the sound. But sound in noble 6.19.0-edge-rockchip64 works now, I switched to pipewire however. Thanks to the maintainers of Armbian and OrangePi for this awesomeness!

Dear Armbian-Enthusiasts! I would like to install Armbian with Virtualbox, so that I can run Home Assistant (HA) in a VM environment (Intel chip .vdi) - yes, no container. Would chose this image "Armbian 25.11.1 Minimal / IOT 6.1 kernel" (rolling release) Installing Virtualbox with: sudo apt install virtualbox Is this possible? Best wishes, Greg Links: https://www.home-assistant.io/installation/linux/ https://wiki.debian.org/VirtualBox https://www.armbian.com/orange-pi-5-plus/

Hello, good afternoon. I'm using a translator, so I apologize if it's not clear. I have an Orange Pi 5 Plus SBC which I have Android installed on the m2 drive. I install Armbian on a microSD card. I don't remember what problem I was having, but I had to format the SPI Flash. After that, the Armbian version worked fine. Also, after formatting the SPI Flash, my microphone stopped working on Android (it works on Armbian). Could this be due to formatting the SPI Flash? Thank you.

I have built and used it with the latest source and still HDMI audio and analog audio does not work. Is there any way to get HDMI audio to work other than using the vendor kernel?

Built image with such flags: Etched img to sdcard and SBC has no response on power up. U-boot log: OS boots normally if I use ext4, but would like to stick to f2fs. Btrfs or f2fs used to work if I used 7 months old armbian-build git checkpoint but not any more. Anyone else had similar problems?

Since I am interested in the connection ability, I figured the info we gather should go into ONE thread. I have tried to build new kernels, but can only see USB controllers and devices two ports. I have seen a lot of work by Sebasitian Reichel @ Collabora, and his patches, but these do not seem to have the desired result on my test board. Orange PI 5. There seems to be an issue with the port mux, FUSB302, that either connects the last USB to the "vertical" port or to the "USB C" connector. I will comment my findings and attempts to correct this in this thread, and think we could find out where we are if you add your findings, successes and failures, rather than cluttering everywhere Regards, Gullik

I'm kinda new here, and lets first say thank you for Armbian, it has kinda saved me from having to do a lot more work than I have had to, to get my Orange Pi 5 Plus to a state where it's really a pretty cool little test/experimental system... BUT, I wondered... since many of these devices have accessible PCIe in one form or another, and the Mali GPU is a bit of a blocker... Perhaps it would be good to build the kernel with the modules for open source GPUs for Mesa... AMDGPU, XE, and i915.. Currently I'm in this position... I know I could clone the project from GIT, and build my own kernel, but this seems like an obvious next step and I wonder how many other people would try this if the modules were available. root@mouse:/home/james# lscpu | head -5 Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 root@mouse:/home/james# free -h total used free shared buff/cache available Mem: 30Gi 4.1Gi 18Gi 723Mi 9.2Gi 26Gi Swap: 15Gi 0B 15Gi root@mouse:/home/james# df -h . Filesystem Size Used Avail Use% Mounted on /dev/sda1 800G 322G 475G 41% /home root@mouse:/home/james# lspci 0000:00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0000:01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] (rev c7) 0000:01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] 0002:20:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0002:21:00.0 Network controller: Intel Corporation Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak] (rev 1a) 0003:30:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0003:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0004:41:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) root@mouse:/home/james# modprobe amdgpu modprobe: FATAL: Module amdgpu not found in directory /lib/modules/6.18.16-current-rockchip64 root@mouse:/home/james#

Dear team, On Armbian_25.11.1_Orangepi5-plus_trixie_current_6.12.58_minimal.img not possible to boot kernel, only u-boot seems available ? Bellow is the debug log on tty DDR V1.13 25cee80c4f cym 23/08/11-09:31:58 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB Manufacturer ID:0xff CH0 RX Vref:28.5%, TX Vref:22.8%,21.8% CH1 RX Vref:27.1%, TX Vref:21.8%,21.8% CH2 RX Vref:27.9%, TX Vref:21.8%,21.8% CH3 RX Vref:28.5%, TX Vref:20.8%,20.8% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL board init U-Boot SPL 2017.09-orangepi (Nov 15 2023 - 16:53:25) Trying to boot from MMC1 Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK ## Checking u-boot 0x00a00000 ... sha256(e17d8b540a...) + OK ## Checking fdt-1 0x00ad1370 ... sha256(5411c775cf...) + OK ## Checking atf-2 0x000f0000 ... sha256(b2af21b504...) + OK ## Checking atf-3 0xff100000 ... sha256(70505bb764...) + OK Jumping to U-Boot(0x00a00000) via ARM Trusted Firmware(0x00040000) Total: 719.759 ms ....and nothing I also changed the verbosity level in /boot/armbianEnv.txt, but without success! Thanks in advance for your help

I've already benchmarked a computer-interactivbe task (like image processing) on the Orangepi 5 plus's processor——and it wrapped up in just 40 minutes, which is impressively fast. Therefore, I' like to try the NPU. Anyone know how to tap into its NPU for AI workloads?

I am running Ubuntu 24.04 Noble (Armbian Linux 6.1.115-vendor-rk35xx) and no additional packages affecting VPU performance have been installed; everything is stock. Jellyfin is running in Docker, and transcoding works perfectly, except for some movies. I tried to play a 4K video in Chrome (native HEVC support), set the bitrate to 40mbps, and the video played normally at a transcoding speed of about 3x, but after a while, Orange Pi crashed. In Firefox inside neko (where there is no hardware acceleration and HEVC), the crash happened even faster, after ~2 seconds of playback. The crash happens as if the board loses power: journalctl is not saved, nothing is visible via ssh. I use a 100W Baseus GaN Pro Desktop Power Strip (model CCGAN100-1ACE) and the Orange Pi is the only device connected to it. I also have a 100W cable that shows the current consumption in watts. During transcoding, it showed 10, and then the board hard rebooted again, so I don't think this is related to power issues. Before that, I used Ubuntu 24.04 from Joshua Riek, and there was a problem with the Mali driver crashing under heavy load or simply after a while. A similar hard reboot also occurred if the driver was “too slow” to crash. Here is Jellyfin's video info: ffprobe: I also have a 4 GB model of Orange Pi 5 (not B), and there were no problems with transcoding this video; it was just slow due to the small amount of RAM. I don't even know where to start. What should I do to at least understand the cause of this issue?

i recently purchased an orange pi 5 plus 16gb with the wifi / bt card, the aluminum wifi case, fan and 1tb ssd. when i go to the official website i see different images there none of which seem to work 100%. i mean i was able to get each up and running but what i noticed is that the graphical drivers would not load. i saw a youtube video claiming armbian has the right driver support for the mali 610 gpu. can someone assist me getting this to work? im big into emulation gaming and right now it doesnt even have Vulkan support i crave. someone help thanks

Hi, I've read on here that you can apparently switch to a stable edge branch through Armbian Config, but the closest I can find is 'switch to rolling packages repository' and 'distribution upgrade to rolling unstable'. Are either of these correct? I'm running the Ubuntu Noble 6.12 kernel, btw. Many thanks.

Hi All, I'm struggling with my Orange PI 5 Plus and various Armbian Flavors for 3 days. My Preferred DE, Armbian_25.8.1_Orangepi5-plus_noble_vendor_6.1.115_kde-neon_desktop, after all setup on second boot... failed msg: wait until boot finishes... XFCE, Sound does not work over HDMI. Finally, Armbian_25.8.1_Orangepi5-plus_trixie_vendor_6.1.115_cinnamon_desktop, is doing well. Except for, I'm missing start button. If I want Firefox, I have to open it via cmd If I want to capture screen... I dont know even the name to call via cmd... See my Phone shot https://drive.google.com/file/d/1d6K4i_yshHCrKvXR-13VFkpWzPKx8GaA/view?usp=sharing Could somebody tell me what is wrong? Thanks,

Hi there, I'm really happy with Armbian on my Oprange Pi 5 Plus but recently I noticed that I'm not getting kernel updates so often as before. I use rockchip-edge branch and I'm stuck at kernel "6.18.0-rc6-edge-rockchip64". I know there are new versions being tested (https://github.com/armbian/os/pkgs/container/os%2Fkernel-rockchip64-edge), will they be released to armbian? Maybe you are working hard on Armbian version 26.2 and I'm just anxious Thanks in advance!

It was found that 3.5mm jack has issue with using headset. Speakers are work good on my "uname -a Linux orangepi5-plus 6.19.0-rc5-edge-rockchip64 #1 SMP PREEMPT Mon Jan 12 03:03:14 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux" system but micro is silent. By debugging it was found that register 0x2b(43) "DAC Control 21" has difference between actually used es8388 on OP5+ and original driver's IC es8328. Also microphone bias was never activated by bits 2,3 in register 0x03. I create patch and now microphone work properly. I don't know how to properly share this patch so I will attache it here. orangepi-5-plus_ES8388_Microphone.patch

Hi all Cannot make usable wol on my orange pi 5 plus. Os: Armbian 24.5.1 Bookworm with Linux 6.1.75-vendor-rk35xx WOL tested in magic or unicast settings or all flags enabled (phy, unicast, multicast, broadcast, arp, magic) Test sending wol packets with running tcpdump -i enP3p49s0 '(udp and port 7) or (udp and port 9)' show that orange pi successfully receive wol packets on speeds 1000 or even 10 mbps while powered on. But after sending orange pi to suspend or power off I cannot bring it online via WOL. So I suppose network component outside orange pi is ok and it is something wrong with orange pi. Any ideas?

Continuing the tradition (1, 2) of micro-optimizations for single-board computers that come into my hands. This time I optimized or rather fixed the wake-up function via USB/WoL/WWoL on the Orange Pi 5 Plus. Also got the WiFi adapter RTW8852BE/RTW8852CE working (at least those are the ones I tested). I tested exclusively on the Vendor 6.1.x kernel since the main wake-up features via USB/PCIE/GPIO1-GPIO4 only work in it. I don't currently have the ability to test the new current kernel and I doubt that Power Management will work fully there. Armbian for Orange Pi 5 Plus from the official website, Vendor kernel (kernel 6.1.115-vendor-rk35xx), what does NOT work by default: 1. No WiFi modules that insert into the PCI-E M.2 socket E-Key work - fixed in dts below 2. Wake-up from USB (mouse/keyboard/even Bluetooth dongle) doesn't work - fixed in dts below 3. WoL via Ethernet (on two ports) - fixed in dts below I also conducted power consumption measurements in all these wake-up modes. Let's start with Ethernet ports (WoL won't work by default due to incomplete dts profile). You need to create an overlay file, links I've attached it to this message. To apply this overlay, you need to copy it somewhere on the single-board computer and execute the command: cd <path to rk3588-orangepi-5-plus-Wakeup-GPIO-RTC-USB-WoL-fixes.dts> sudo armbian-add-overlay rk3588-orangepi-5-plus-Wakeup-GPIO-RTC-USB-WoL-fixes.dts Reboot. (if it doesn't boot at all with it or something doesn't work, you can remove these changes from the /boot/overlay-user/ folder) Wake-up Timer Test: sudo sh -c "echo 0 > /sys/class/rtc/rtc0/wakealarm" sudo sh -c "echo `date '+%s' -d '+ 1 minutes'` > /sys/class/rtc/rtc0/wakealarm" sudo systemctl suspend (here we set wake-up in 1 minute from current time, you can choose seconds/minutes/hours and so on, maybe even days - haven't tested. Installing a battery on RTC is not necessary, Type-C power is sufficient) Power Consumption: Testing was performed on Imax B6 Evo / OWON HDS242S. Please note, power consumption of m.2 SSD, SD-card, eMMC is not accounted for here (ideally they should be powered off in sleep mode), but USB devices were not used, bare single-board computer was tested, each module will have its own consumption, especially USB-connected devices, add your values to the sleep mode consumption. Wake-up only via GPIO0 (this includes power button), RTC In this power-saving mode only the rk3588-orangepi-5-plus-Wakeup-GPIO0-RTC-only-fixes.dts profile is used, keep this in mind, it's not compatible with other dts, you need to choose only one option. I got these values: sudo shutdown -h now | 5.4V | 0.005W | 0.001A sudo systemctl suspend | 5.4V | 0.14W | 0.027A Wake-up via GPIO0, GPIO1-4, RTC, USB, WoL In this power-saving mode only the rk3588-orangepi-5-plus-Wakeup-GPIO-RTC-USB-WoL-fixes.dts profile is used, keep this in mind, it's not compatible with other dts, you need to choose only one option. sudo systemctl suspend | 5.4V | 0.25W | 0.046A RTL8125B (eth0 or eth1, can even be both): sudo ethtool -s eth0 wol g && sudo systemctl suspend | 5.4V | 0.33W | 0,061A RTW8852BE (external rtw8852be driver (rtw89 doesn't support WWoL for RTW8852BE in vendor 6.1 kernel)): sudo iw phy0 wowlan enable any && sudo systemctl suspend | 5.4V | 0.30W | 0,055A RTW8852CE (built-in rtw89 driver in the build): sudo iw phy0 wowlan enable magic-packet && sudo systemctl suspend | 5.4V | 0.27W | 0,051A (I want to note that the Ethernet ports on Orange Pi 5 Plus in WoL mode don't light up and don't show link activity, you can only find out if the link is working on the router or on the device to which the single-board computer is connected. In magic-packet standby mode the link switches to 10Mbit and for example on the router loses the assigned IP address, you can find out if the device is alive only by ARP scanning on the router itself or by the link light indication on the router itself. The same applies to WWoL (WiFi) - only on the router or device to which the single-board computer is connected can you check in active clients mode or ARP scan for the presence of MAC address) My Armbian build from the official website on Vendor 6.1 kernel where rtw89 (WiFi) modules are already compiled and pre-installed in the kernel has a peculiarity that this driver supports WWoL function only for RTW8852CE - this is a slightly different chip than the official proprietary WiFi module for Orange Pi 5 Plus which uses RTW8852BE. For WWoL to work on RTW8852BE you need to install a third-party driver, for example I recommend from this source. How to use WoL, WWoL: For wired network use ip and ethtool utilities, for wireless network iw. WoL over LAN WWoL over WiFi External Drivers: For RTW8852BE/RTW8852CE and others there are fairly recent drivers (at the time of writing this manual), here's a brief instruction on how to install them on Orange Pi 5 Plus. Issues: File: rk3588-orangepi-5-plus-Wakeup-GPIO-RTC-USB-WoL-fixes.dts File: rk3588-orangepi-5-plus-Wakeup-GPIO0-RTC-only-fixes.dts Original Link 4PDA

I understand that panthor is not supported for wayland but in that case I would expect libmali to fill in... but I ended up with lvmpipe. The overlay along with another recent post led me to believe that panthor was the expected default and libmali was an artifact, but I'm now questioning that after finding a thread identifying use cases where libmali can be preferred and a comment suggesting panthor wouldn't be available until 6.13. As a result, I am now questioning if there is a reason that software acceleration is the default and the user is expected to determine which path they want to go? I know support for the hardware has been slow going so I understand that it's not well supported yet, but hoping to get a better handle on expectations. Is there an expected default for a Rockchip RK3588 SoC with the Mali‑G610 GPU? Does it vary between 6.1/6.12 and the desktop/server builds?

Why so few Debian (Trixie) images with this batch of newly released images? Not one full desktop image for Debian?

Hi Guys, I just did a new custom Armbian build ./compile.sh BOARD=orangepi5-plus BRANCH=vendor RELEASE=noble KERNEL_ONLY=yes KERNEL_CONFIGURE=no. The image is Armbian-unofficial_25.11.0-trunk_Orangepi5-plus_noble_vendor_6.1.115_cinnamon_desktop and when I installed it on orangepi I see it is not supporting Panfrost/Mail: glxinfo | grep -E "OpenGL renderer|OpenGL version" OpenGL renderer string: llvmpipe (LLVM 20.1.2, 128 bits) OpenGL version string: 4.5 (Compatibility Profile) Mesa 25.0.7-0ubuntu0.24.04.2 but for older image Old_Armbian-unofficial_25.08.0-trunk_Orangepi5-plus_noble_vendor_6.1.115_cinnamon_desktop All was well glxinfo | grep -E "OpenGL renderer|OpenGL version" OpenGL renderer string: Mali-G610 (Panfrost) OpenGL version string: 3.1 Mesa 25.0.7-0ubuntu0.24.04.2 I did need to enable "ARM Mail Display Processor" under Device Drivers -> Graphics support -> ARM devices before I perform custom build. And I did this for both OS version 25.11.0 and 25.08.0. But newer version is not able to use it. Thanks Manish

I have tried to download at least 3 times this image: Armbian_25.8.1_Orangepi5-plus_noble_vendor_6.1.115_gnome_desktop.img.xz All sha256sum verified Ok. And wrote 5 times on 3 different SDCards, and this img does not boot on my OPI-5-Plus. No image on monitor, partition armbi_root not expanded, no green lights... Just unusable (for me). Other img's that boot are OK: Deb-xfce, noble-cinnamon, noble-neon... Someone got success with this img??? I'm looking for a distro that works well on OPI5-Plus, well configured, and that works with HDMI audio. The best for now is Noble-Cinnamon but failed to setup Menu button, and I cant find support until now to solve this issue. Thanks, Cury

I've heard people say that the Orange Pi is a "budget alternative" to the Raspberry Pi. On one hand, the Raspberry Pi has an excellent community, with a large user base that could really help you in your learning journey. On the other hand, the Orange Pi offers great value for money, and it's really tempting because the Raspberry Pi can be a bit pricey. What's your suggestion?

I’m currently using the Armbian build system to generate images for the Orange Pi 5 Plus. To use the PREEMPT_RT kernel, I set the BRANCH to current, and with the PREEMPT_RT configuration on the 6.12 kernel I was able to successfully build the image and boot it. However, in this kernel version there are no dtbo files for peripherals like can0, i2c, etc., so I’m unable to use those interfaces. If I set the BRANCH to vendor, I can use the 6.1 kernel, but in order to use a PREEMPT_RT kernel I need to apply the RT patch. The RT patch currently provided is not compatible with the current BRANCH, so kernel build and image creation fail. My question is: while using the 6.12 current kernel, is there any way to copy and use the dtb and dtbo files from the 6.1 vendor kernel?

Hello, I've been using https://joshua-riek.github.io/ubuntu-rockchip-download/boards/orangepi-5-plus.html with a custom kernel that I built to activate my TPM2.0 device and it works. Now I'm asked to use an UEFI compatible image with my Orange Pi 5 Plus. So what I did is more or less the same thing that in here But instead of the legacy kernel I used the 6.1.115-rockchip-vendor-rk35xx kernel and my device booted, I got an HDMI output, etc. And then I updated it to my custom kernel (6.1.0-1027-rockchip) that has the necessary configurations to allow TPM over SPI. Now I'm trying to activate my TPM2.0 as I did before. To do that I added my compiled *.dtbo (rk3588-spi0-tpm-cs1.dtbo) to /boot/dtb/rockchip/overlay and activated it with armbian-config. After reboot this is my /boot/armbianEnv.txt orangepi@uefi-arm64:~$ cat /boot/armbianEnv.txt verbosity=1 bootlogo=true console=both extraargs=cma=256M overlay_prefix=rk3588 fdtfile=rockchip/rk3588-orangepi-5-plus.dtb rootdev=UUID=3e555b58-fdf4-4e2f-a3af-a8ecfd8034b6 rootfstype=ext4 overlays=spi0-tpm-cs1 param_spidev_spi_bus=0 However I still can't see my tpm under /dev/. I don't know what I'm missing, I'm quite new to this sorry Thank you for your time