Search the Community

Hi. According to this patch Orange pi 5 Pro DTS (which BTW i use for my successful Orange Pi 5 Pro edge build) there will be a split of DTSI files. Most of the code in rk3588s-orangepi-5.dtsi will be transferred to new rk3588s-orangepi-5-5b.dtsi. In my current build for Orange Pi 5 and 5 Pro I have: rk3588s-orangepi-5-5b.dtsi rk3588s-orangepi-5b.dts rk3588s-orangepi-5.dts rk3588s-orangepi-5.dtsi rk3588s-orangepi-5-pro.dts. Please note I have Orange Pi 5 Pro with SPI chip soldered on so for Orange Pi 5 Pro build with EMMC (99.99% of cases) in rk3588s-orangepi-5-pro.dts set: /* SFC */ &sfc { status = "disabled"; }; and &sdhci { status = "okay"; }; rk3588s-orangepi-5-pro.dts rk3588s-orangepi-5b.dts rk3588s-orangepi-5-5b.dtsi rk3588s-orangepi-5.dtsi rk3588s-orangepi-5.dts

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

Is there any working image for orangepi5-pro? I am having trouble to understand a few things in the https://www.armbian.com/orange-pi-5-pro/ It says: But downloding the image on that page brings Armbian_community_25.8.0-trunk.38_Orangepi5pro_bookworm_vendor_6.1.115_minimal.img.xz which is version 25.8.0 and that image wont boot.

Dear community, I just wanted to politely and respectfully ask whether somebody from the Orange Pi 5 or Orange Pi 5 Plus maintainer group wants to maintain the Orange Pi 5 Pro as well? It's using almost the same SoC, a Rockchip RK3588S. Right now, the device is on "community" maintenance, which is a bit sad since its brother/sister boards are on "standard". This means everyone who uses it has to use rolling release instead of being on a stable version. Being relatively close to the other two RK3588-based boards, I hope this can be done? But I don't want to sound like an ass for asking. I just wanted to use the two "Pro" I've bought for projects that need reliability, and was a bit saddened to hear they're rolling release-only. Kind regards

Anyone got the dedicated Fan header working correctly? It won't spin at all. Enabled the fanctrl overlay. changed pwm rate,the fan won't budge.. Tried stress the CPU but this only cause shutdown

Good day, I have recently purchased an Orange Pi 5 Pro and want to use Armbian on it. Armbian (Debian 13 Trixie) does not boot and gives a initramfs error. I have read on erasing the SPI flash memory, but have a few questions. Will erasing the SPI flash memory affect the booting of other operating systems. Is it safe to erase the SPI flash memory? What is the issue around Armbian not booting because of the SPI flash memory? How exactly would I safely erase the SPI flash memory? Thank You

Hi, Just received this unit yesterday with my surprise and lack of reading, the unit does not include eMMC or SPI so I am unable to boot directly into nvme drive. Are there instructions somewhere on how to setup the device to boot from MicroSD but use nvme as main drive? Thank you.

BOARD - Orange Pi 5 Pro PROBLEM Device Tree overlays defined in armbianEnv.txt are not being applied during boot. The overlay file exists but is not loaded by the system. verbosity=1 bootlogo=false console=both extraargs=cma=256M fdtfile=rockchip/rk3588s-orangepi-5-pro.dtb rootdev=UUID=a8beb1c4-8079-4e64-8216-8e893f7809d4 rootfstype=ext4 overlays=orangepi-5-pro-disable-leds usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I also tried with overlay_prefix=rockchip overlays=orangepi-5-pro-disable-leds The Kernel is Linux orangepi5pro 6.1.115-vendor-rk35xx #1 SMP Mon Feb 23 05:39:00 UTC 2026 aarch64 GNU/Linux Additional Information I tested the same overlay using the official build system from: https://github.com/orangepi-xunlong/orangepi-build and it works correctly there. This suggests the issue may be related to how Armbian loads overlays for RK3588 boards. Question Is overlay loading from armbianEnv.txt supported on the Orange Pi 5 Pro with the vendor-rk35xx kernel, or is there another mechanism required (extlinux overlays, user overlays, etc.)? https://paste.armbian.com/xiteginoku

Orange Pi 5 pro,whith Armbian_community_26.2.0-trunk.7_Orangepi5pro_noble_vendor_6.1.115_gnome_desktop 。 when I try to start Eclipse/idea/vscode or other JavaApp , java processes crash and gets core dump every time, tested on Jdk 17,21 25 ,both openjdk and oracleJDK。 It seems there is a compatibility issue between the kernel and the JDK. How can I fix it? Or I have to wait kenel update? some error like Current thread (0x0000ffffa802b9b0): JavaThread "main" [_thread_in_vm, id=6202, stack(0x0000ffffaeb62000,0x0000ffffaed60000) (2040K)] Stack: [0x0000ffffaeb62000,0x0000ffffaed60000], sp=0x0000ffffaed5ce40, free space=2027k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xddc444] Symbol::as_C_string() const+0x14 V [libjvm.so+0xbef608] Method::print_external_name(outputStream*, Klass*, Symbol*, Symbol*)+0x40 V [libjvm.so+0xb07e7c] LinkResolver::resolve_method(LinkInfo const&, Bytecodes::Code, JavaThread*)+0x154 V [libjvm.so+0xb0a85c] LinkResolver::linktime_resolve_virtual_method(LinkInfo const&, JavaThread*)+0x3c V [libjvm.so+0xb0b204] LinkResolver::resolve_virtual_call(CallInfo&, Handle, Klass*, LinkInfo const&, bool, JavaThread*)+0x3c V [libjvm.so+0xb0b3a0] LinkResolver::resolve_invokevirtual(CallInfo&, Handle, constantPoolHandle const&, int, JavaThread*)+0xd4 V [libjvm.so+0x887cd4] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x250 V [libjvm.so+0x887f80] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x3c j java.util.AbstractSet.removeAll(Ljava/util/Collection;)Z+8 java.base@25.0.1 j org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolveRevisions(Ljava/util/List;ZLorg/eclipse/osgi/container/ModuleResolver$ResolveProcess$ResolveLogger;Ljava/util/Map;)V+424 j org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolveRevisionsInBatch(Ljava/util/Collection;ZLorg/eclipse/osgi/container/ModuleResolver$ResolveProcess$ResolveLogger;Ljava/util/Map;)V+253 j org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve()Lorg/eclipse/osgi/container/ModuleResolutionReport;+307 j org.eclipse.osgi.container.ModuleResolver.resolveDelta(Ljava/util/Collection;ZLjava/util/Collection;Ljava/util/Map;Lorg/eclipse/osgi/container/ModuleDatabase;)Lorg/eclipse/osgi/container/ModuleResolutionReport;+19 j org.eclipse.osgi.container.ModuleContainer.resolveAndApply(Ljava/util/Collection;ZZLorg/eclipse/osgi/container/ModuleContainer$ResolutionLock$Permits;)Lorg/eclipse/osgi/report/resolution/ResolutionReport;+256 j org.eclipse.osgi.container.ModuleContainer.resolve(Ljava/util/Collection;ZZ)Lorg/eclipse/osgi/report/resolution/ResolutionReport;+63 j org.eclipse.osgi.container.ModuleContainer.refresh(Ljava/util/Collection;)Lorg/eclipse/osgi/report/resolution/ResolutionReport;+34 j org.eclipse.osgi.storage.Storage.checkSystemBundle([Ljava/lang/String;)V+242 j org.eclipse.osgi.storage.Storage.createStorage(Lorg/eclipse/osgi/internal/framework/EquinoxContainer;)Lorg/eclipse/osgi/storage/Storage;+17 j org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(Ljava/util/Map;Lorg/osgi/framework/connect/ModuleConnector;)V+146 j org.eclipse.osgi.launch.Equinox.<init>(Ljava/util/Map;Lorg/osgi/framework/connect/ModuleConnector;)V+10 j org.eclipse.osgi.launch.Equinox.<init>(Ljava/util/Map;)V+3

orange pi 5, orange pi 5 pro, orange pi 5 ultra or orange pi 5 max?

Yesterday, Oct 20th, I installed armbian version "Minimal/IOT images with Armbian Linux v6.1" to the Orange PI 5 PRO and updated kernel using armbian-config to kernel 6.18 RC1(2 options were available 6.12 and 6.18 R1, note 6.12 did not work). Armbian works fine including vulkan support(I tested with swith emulator) with this kernel(6.18 rc1), but today option to update to any kernel is not available anymore. I'm getting warning "No other kernels available!" System is pretty stable with this version. stas@orangepi5pro:~$ uname -r 6.18.0-rc1-edge-rockchip64 stas@orangepi5pro:~$ vulkaninfo --summary ========== VULKANINFO ========== Vulkan Instance Version: 1.4.309 Instance Extensions: count = 24 ------------------------------- VK_EXT_acquire_drm_display : extension revision 1 VK_EXT_acquire_xlib_display : extension revision 1 VK_EXT_debug_report : extension revision 10 VK_EXT_debug_utils : extension revision 2 VK_EXT_direct_mode_display : extension revision 1 VK_EXT_display_surface_counter : extension revision 1 VK_EXT_headless_surface : extension revision 1 VK_EXT_surface_maintenance1 : extension revision 1 VK_EXT_swapchain_colorspace : extension revision 5 VK_KHR_device_group_creation : extension revision 1 VK_KHR_display : extension revision 23 VK_KHR_external_fence_capabilities : extension revision 1 VK_KHR_external_memory_capabilities : extension revision 1 VK_KHR_external_semaphore_capabilities : extension revision 1 VK_KHR_get_display_properties2 : extension revision 1 VK_KHR_get_physical_device_properties2 : extension revision 2 VK_KHR_get_surface_capabilities2 : extension revision 1 VK_KHR_portability_enumeration : extension revision 1 VK_KHR_surface : extension revision 25 VK_KHR_surface_protected_capabilities : extension revision 1 VK_KHR_wayland_surface : extension revision 6 VK_KHR_xcb_surface : extension revision 6 VK_KHR_xlib_surface : extension revision 6 VK_LUNARG_direct_driver_loading : extension revision 1 Instance Layers: count = 2 -------------------------- VK_LAYER_MESA_device_select Linux device selection layer 1.4.303 version 1 VK_LAYER_MESA_overlay Mesa Overlay layer 1.4.303 version 1 Devices: ======== GPU0: apiVersion = 1.1.305 driverVersion = 25.0.7 vendorID = 0x13b5 deviceID = 0xa8670000 deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU deviceName = Mali-G610 driverID = DRIVER_ID_MESA_PANVK driverName = panvk driverInfo = Mesa 25.0.7-2 conformanceVersion = 1.4.1.2

I am trying to extend the chipselect from spi4. Because I will need to control more boards, so I tried to transform GPIO into chipselect (CS). This is the original SPI4: /dts-v1/; / { fragment@0 { target = <0xffffffff>; __overlay__ { status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; pinctrl-names = "default"; pinctrl-0 = <0xffffffff 0xffffffff 0xffffffff>; spidev@0 { compatible = "rockchip,spidev"; status = "okay"; reg = <0x00>; spi-max-frequency = <0x2faf080>; }; spidev@1 { compatible = "rockchip,spidev"; status = "okay"; reg = <0x01>; spi-max-frequency = <0x2faf080>; }; }; }; __fixups__ { spi4 = "/fragment@0:target:0"; spi4m1_cs0 = "/fragment@0/__overlay__:pinctrl-0:0"; spi4m1_cs1 = "/fragment@0/__overlay__:pinctrl-0:4"; spi4m1_pins = "/fragment@0/__overlay__:pinctrl-0:8"; }; }; And this is the my change that is compiling with warning: /dts-v1/; / { fragment@0 { target = <0xffffffff>; __overlay__ { status = "okay"; #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <0xffffffff 0xffffffff 0xffffffff>; cs-gpios = < 0xffffffff 4 1 /* CS2: GPIO1_A4 */ 0xffffffff 6 1 /* CS3: GPIO1_A6 */ 0xffffffff 7 1 /* CS4: GPIO4_A7 */ >; spidev@0 { compatible = "rockchip,spidev"; reg = <0>; spi-max-frequency = <50000000>; status = "okay"; }; spidev@1 { compatible = "rockchip,spidev"; reg = <1>; spi-max-frequency = <50000000>; status = "okay"; }; spidev@2 { compatible = "rockchip,spidev"; reg = <2>; spi-max-frequency = <50000000>; status = "okay"; }; spidev@3 { compatible = "rockchip,spidev"; reg = <3>; spi-max-frequency = <50000000>; status = "okay"; }; spidev@4 { compatible = "rockchip,spidev"; reg = <4>; spi-max-frequency = <50000000>; status = "okay"; }; }; }; __fixups__ { spi4 = "/fragment@0:target:0"; spi4m1_cs0 = "/fragment@0/__overlay__:pinctrl-0:0"; /* CS0 */ spi4m1_cs1 = "/fragment@0/__overlay__:pinctrl-0:4"; /* CS1 */ spi4m1_pins = "/fragment@0/__overlay__:pinctrl-0:8"; /* SCLK/MISO/MOSI */ spi4m1_cs2 = "/fragment@0/__overlay__:cs-gpios:0"; /* CS2 */ spi4m1_cs3 = "/fragment@0/__overlay__:cs-gpios:1"; /* CS3 */ spi4m1_cs4 = "/fragment@0/__overlay__:cs-gpios:2"; /* CS4 */ }; };

Let's divide it into parts - Bluetooth Bluetooth isn't working. I've tried activating UART7 and GPIO pins 19 and 22, but to no avail. I installed the drivers, but to no avail. Bluetooth isn't communicating! - Audio ES8388 For some unknown reason, the ES8388 has audio disabled by default on the ASA. To fix this, simply go to the terminal and run the command user@user alsamixer Then use the buttons to move around until you find OUT1. Out1 above it says MM (mute), so click M to make it 00 with a green background. Audio problem solved - Language I can't set the language to Portuguese in the Gnome interface even after installing the packages manually and through armbiam-config - Kernel Please, even if kernel 6.1.xx++ does not work, use the latest functional kernel, for me kernel 6.1.115 is very functional. No critical problems.

I am downloading three different builds from 6.12 for orange pi 5. I have an orange pi 5 pro but since there is not dtb entry in 6.12 for that sbc in the Armbian 25.8.1 6.12.28 dtb file I used the orange pi 5b.dtb entry which works with the Armbian 25.8.1 6.1.115 images. The result is that the initramfs cant find a root disk - and when checking for drives in initramfs - there are none ls /dev/disks/by-uuid. So the initramfs file isn't running correctly as its not finding drives. I went back and loaded Armbian_24.8.1_Rock-5c-trixid_current_6.12.42_minimal.image and that boots up to root login. However if I change the card type to orangepi-5b. I cannot boot - in exactly the same manner - no drives found by initramfs. I have decided to go back to Armbian_25.8.1_Orangepi5-trixie_vendor_6.1.115_xfce_desktop.img - flash that and change the armbianEnv.txt to use the orangepi-5-pro setting. At 6.1.115, the image dtb/rockchip directory still has an entry for the orangepi-5-pro. - the new one doesn't. I am curious if I am just out of luck getting updates for orange pi 5 pro? will orange pi 5b be supported in the future? I have working images for debian 13 - and 6.1.115 versions, so my orange pi 5 is useable as is. I bought this sbc as I could get a useable NVME M.2 drive. I see that all new Orange pi sbc's are using the RK3588 chipset not the RK3588s variant. Opinions - there are new Orange Pi 5 variants - Ultra, Max, Plus etc. I dont need tons of HDMI, I want an NVME M.2 slot or two to run the OS on fast drives. -Or should I abandon Orange Pi and look elsewhere.

Hi, I have attempted to boot with edge and current branches with no success. I am now trying vendor since its what its running. My process is: ./compile.sh BOARD=orangepi5pro BRANCH=current kernel-config I enable tunneling GRE and some broadcom wifi drivers. ./compile.sh BOARD=orangepi5pro BRANCH=current kernel sudo dpkg -i output/debs/linux-image-*.deb sudo dpkg -i output/debs/linux-headers-*.deb sudo dpkg -i output/debs/linux-dtb-*.deb sudo reboot and after this the system does not boot or post through HDMI. I have to go back and erase /boot and restore a backup to be able to get it working again. What am I missing? P.S. I have /boot partition in SD card and the system partition is in an NVME drive.

Hi everyone! I recently bought an Orange Pi 5 Pro and decided to install kernel 6.10 on it, as I wanted to take advantage of the new drivers available in this kernel. I found that the [Orange Pi 5 Pro page on the Armbian website](https://www.armbian.com/orange-pi-5-pro/) offers distributions with kernel 6.1, but not 6.10. After trying to install kernel 6.10 via `armbian-config` on an already installed system, I encountered an issue: the system stopped booting. ### Questions and Requests for Help 1. **Support for Kernel 6.10 on Orange Pi 5 Pro**: - Am I correct in understanding that kernel 6.10 is currently not supported for my board? - Does anyone have information on whether support for kernel 6.10 for Orange Pi 5 Pro is planned in the future? 2. **Possibility of Installing Kernel 6.10**: - Is there any way to install kernel 6.10 on the Orange Pi 5 Pro? Has anyone already faced this challenge and can share their experience? 3. **Building Armbian Distribution with Kernel 6.10**: - I want to try building the Armbian distribution with kernel 6.10 from source. Can anyone share the configuration and instructions for compiling kernel 6.10 suitable for the Orange Pi 5 Pro? - What steps need to be taken to successfully build and install the kernel on this board? If anyone has successfully built kernel 6.10 for the Orange Pi 5 Pro or has additional tips, please share! Any help would be greatly appreciated. Thanks in advance for any assistance and advice! I hope my experience will be useful to other Orange Pi 5 Pro owners. ### Additional Information Just in case, here is the link to the [Armbian page for Orange Pi 5 Pro](https://www.armbian.com/orange-pi-5-pro/). Thank you!

Hello, I was trying to boot Armbian 6.10 from https://www.armbian.com/orange-pi-5-pro/ minimal or normal desktop, none of them are working/booting, maybe hint what am I doing wrong? Thank you

Hello, I was wondering if the recent update fixed the problem with the lack of gpu support in the OP5 Pro. Thanks in advance.

Im trying to build for a OrangePi 5 Pro. I tried the following compile line, but it didnt boot. Repeat Build Options [ ./compile.sh build BOARD=orangepi5 BRANCH=current BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_APPGROUPS_SELECTED='browsers chat desktop_tools editors email internet multimedia office programming remote_desktop' DESKTOP_ENVIRONMENT=xfce DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base KERNEL_CONFIGURE=yes RELEASE=noble ] What am I doing wrong? Thanks.

Can anyone confirm whether HDMI-CEC is working on the opi5pro? I got one recently and regardless of distro neither cec-utils or v4l-utils can see any devices. e.g. cec-ctl: > cec-ctl -S Driver Info: Driver Name : dwhdmi-rockchip Adapter Name : dw_hdmi_qp Capabilities : 0x0000000e Logical Addresses Transmit Passthrough Driver version : 6.1.75 Available Logical Addresses: 4 Connector Info : None Physical Address : f.f.f.f Logical Address Mask : 0x0000 CEC Version : 2.0 Vendor ID : 0x000c03 (HDMI) OSD Name : 'Playback' Logical Addresses : 1 (Allow RC Passthrough) Logical Address : Not Allocated Primary Device Type : Playback Logical Address Type : Playback All Device Types : Playback RC TV Profile : None Device Features : None Topology: and cec-client, after building libcec6 with -DHAVE_LINUX_API=1 -DHAVE_RPI_LIB=0 for each distro I tried: > echo "scan" | cec-client Linux -s -d 1 opening a connection to the CEC adapter... ERROR: [ 609] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64 ERROR: [ 609] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64 ERROR: [ 903] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64 (... repeats numerous times...) ERROR: [ 1819] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64 CEC bus information =================== device #1: Recorder 1 address: 1.0.0.0 active source: no vendor: Pulse Eight osd string: CECTester CEC version: 1.4 power status: on language: eng currently active source: unknown (-1) ERROR: [ 1820] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64 ERROR: [ 1820] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64 Distros I tried (all with same/similar result): https://dl.armbian.com/orangepi5pro/Noble_vendor_gnome (opi official distro) Orangepi5pro_1.0.4_debian_bookworm_desktop_xfce_linux6.1.43 Joshua-Riek/ubuntu-rockchip/.../v2.4.0/ubuntu-22.04-preinstalled-desktop-arm64-orangepi-5-pro https://dl.armbian.com/orangepi5pro/Bookworm_vendor_minimal And of course I tried every hdmi port and every hdmi cable in the house (including one from my old Raspberry Pi 2 Model B with fully working HDMI-CEC which detects 4 devices). Thanks, would be very interested to know if anyone has better results with the opi5pro.

I have strange issue with small hdmi display, when i connect orange pi to it theres no signal, but whet i connect orange pi to a 15'' display it works fine. also when i connect small display in to a pc output it also works. i tried different distros on that pi with the same behavior. Today i turned it on and it randomly worked but when i try to enter console mode theres no output. theres some weird hdmi errors Nov 11 18:08:12 orangepi5pro kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: bus_width:0x7aae4,bit_rate:502500 Nov 11 18:08:12 orangepi5pro kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy lane can't ready! Nov 11 18:08:12 orangepi5pro kernel: phy phy-fed60000.hdmiphy.7: phy poweron failed --> -22 Nov 11 18:08:12 orangepi5pro kernel: dwhdmi-rockchip fde80000.hdmi: dw_hdmi_qp_setup hdmi set operation mode failed Nov 11 18:08:12 orangepi5pro kernel: dwhdmi-rockchip fde80000.hdmi: Rate 50250000 missing; compute N dynamically Nov 11 18:08:19 orangepi5pro kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_disable] Crtc atomic disable vp0 Nov 11 18:08:19 orangepi5pro kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_disable] *ERROR* unexpected power on pd6 Nov 11 18:08:19 orangepi5pro kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_disable] *ERROR* unexpected power on pd5 Nov 11 18:08:19 orangepi5pro kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 1280x800p61, type: 11(if:HDMI0, flag:0x0) for vp0 dclk: 75000000 Nov 11 18:08:19 orangepi5pro kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx_ropll_cmn_config bus_width:b71b0 rate:502500 Nov 11 18:08:19 orangepi5pro kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy pll locked! Nov 11 18:08:19 orangepi5pro kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] dclk_out0 div: 0 dclk_core0 div: 2 Nov 11 18:08:19 orangepi5pro kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx_ropll_cmn_config bus_width:b71b0 rate:750000 Nov 11 18:08:19 orangepi5pro kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy pll locked! Nov 11 18:08:19 orangepi5pro kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] set dclk_vop0 to 75000000, get 75000000 Nov 11 18:08:19 orangepi5pro kernel: dwhdmi-rockchip fde80000.hdmi: final tmdsclk = 75000000 Nov 11 18:08:19 orangepi5pro kernel: dwhdmi-rockchip fde80000.hdmi: don't use dsc mode Nov 11 18:08:19 orangepi5pro kernel: dwhdmi-rockchip fde80000.hdmi: dw hdmi qp use tmds mode

I've tried installing k3s on my OP5Pro and it did not work out because I was missing a couple of things on the kernel. I read the docs on building a new kernel. Did that and was able to get a working 6.1.75 kernel. Even though i got some errors when installing the generated packages. What I did not find in the documents is how I can work on a new kernel. Say 6.11. Has anyone done this? Can you help me out? Thanks! P.D. On a side note. I built this kernel in the OP it self and it was kinda slow. What image can I load in vmware under a macbook air m3 to compile and build faster?

in using minimal armbian with network configuration through dhcpd, ifupdown, wpa_supplicant systemd-networkd-wait-online failing to start during boot causing long boot time. systemctl restart systemd-networkd-wait-online.service causing an error Job for systemd-networkd-wait-online.service failed because the control process exited with error code. See "systemctl status systemd-networkd-wait-online.service" and "journalctl -xeu systemd-networkd-wait-online.service" for details. Sep 10 22:48:17 orangepi5pro systemd-networkd-wait-online[457]: Timeout occurred while waiting for network connectivity. Sep 10 22:48:17 orangepi5pro systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ An ExecStart= process belonging to unit systemd-networkd-wait-online.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Sep 10 22:48:17 orangepi5pro systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ The unit systemd-networkd-wait-online.service has entered the 'failed' state with result 'exit-code'. Sep 10 22:48:17 orangepi5pro systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Configured. ░░ Subject: A start job for unit systemd-networkd-wait-online.service has failed ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A start job for unit systemd-networkd-wait-online.service has finished with a failure. ░░ ░░ The job identifier is 116 and the job result is failed. IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enP4p65s0 ether no-carrier configuring 3 can0 can routable unmanaged 4 wlan0 wlan routable unmanaged

Looking at lscpu reports turns out that my board is vulnerable to spectre v2 because eBPF is enabled. I tryed to disable it by using sysctl but it seems it doesn't work (this is the solution used by ubuntu distributions to solve the problem 'sudo sysctl kernel.unprivileged_bpf_disabled=1 or 2'). I'm on Debian version. Is this option kernel dependent?

Is there any reason with llmnr has been enabled on each interface while mdns has been globally and x interface disabled? I have some weird issues with llmnr that I don't have with mdns Just to detail my above sentence (on windows pc): when I ping just ipv4 (ping -4) hostname is solved just the first time, subsequent request can't find host when I ping ipv6 or default (ping -6 or just ping) hostname is always solved