All Activity

@Nick A I compiled the image for version 6.18.19 using the parameters you preset, but the system fails to boot correctly on the A7S. Upon power-up, the green LED stays solid for about 15 seconds. Then, the green LED flashes once, and the blue LED turns solid (unlike the official system where the blue LED blinks). After that, the system becomes unresponsive. There is no signal output on the DP interface, and the Ethernet port indicator light does not turn on even when a cable is connected. Here is the hash value of the compiled file. I'm not sure if there was an issue with my compilation process, as the network connection dropped several times, and it took a few attempts to finally complete the build. Image: Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a7s_trixie_edge_6.18.19_xfce_desktop.img sha256: a7c6baf463b233bad0abb08d2fcfde7ac107509d69fada77ebaafc2bd00979c5

perhaps the patch is no longer necessary once this lands upstream. We will see once we get there

It is not that one. The 2.0 load was just cosmetic, the CPU was actually idle. But with this one it is actually doing something, which is also increasing heat (if no fan). With the expanded core list, you can see the CPU5 and CPU7 have "system" load of 49% and 36%. On a fully idle system. Interrupts file attached. It seems pretty normal to me. interrupts

If i recall correctly this patch is causing problems: patch/kernel/archive/rockchip64-7.0/rk3588-1221-arm64-fix-typec-for-orangepi-5-5b.patch After split the code it wants to patch has will be moved from arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi to arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi Anyway I'm not sure what this patch meant to fix. Can't find much info on it but it looks like the altmodes block is advertising DP mode over USB-C so enables port to transmit direct video and audio signals. Please someone correct me on this one if I'm wrong. If so it adds future to the system rather then fixing it. I think its better to leave it at default source - host mode.

Why should they?

I was just giving heads up. Basically patch is ready with only few "naming disagreements" and reviewers wants to push it upstream soon probably still within 7.1 release candidate. Once it will happen all the builds for orange pi 5/5b/pro and so on will fail so its worth to be prepared.

Hi Werner. I have done so already around half an hour ago.

feel free to send a pr replacing the current patch for review

If you want to do the work you can open a pr including these changes into Armbian. However I believe all opi5* boards are in decent state I'd simply wait for upstream . the patchew link is dead btw.

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

Hello @rm_, there was a "CPU load bug" with uptime reporting 2.00 on idle. What you show us in your screenshot is far below 2.00. Would you mind to check /proc/interrupts? @armfan I compiled current and edge and uploaded the result to my site (https://privat-in.de). However, I presume you will need extra Wifi drivers enabled, thus you probably need to compile yourself.

Please note that it is a known issue that Turnip / Vulkan broken on Snapdragon SM8550 / Adreno 740 on Mesa 25.3.x. See https://gitlab.freedesktop.org/mesa/mesa/-/work_items/14656 The workaround is to apply patch from https://github.com/batocera-linux/batocera.linux/blob/master/board/batocera/patches/mesa3d/001-fix-freedreno-vulkan.patch and rebuild 001-fix-freedreno-vulkan.patch

And the CPU load bug is still not fixed even in 6.18, amazing. After the system has been up for a while, these crop up in "top", consuming quite a bit of CPU for no discernible reason. The system is otherwise idle and there's nothing running. I stopped qbittorrent and samba, this strange load does not disappear. And it seems to increase over time, a bit after the screenshot, around 30-60% now.

Hi @armfan. To answer some of your queries: this is embedded land, we do not boot from USB normally. Just grab an SD card, flash with "dd", insert and boot from that medium. With 7.0 I have successfully booted from SD - other boot methods may or may not work. To compile your own image with 7.1 cutting edge kernel follow the steps mentioned in the following posting in this thread, see "you are on your own..." HTH // Sven-Ola

duplicate https://forum.armbian.com/topic/59601-sd-card-boot-cant-find-my-sda1hdd-after-warning-and-fsck/?do=findComment&comment=237240

That's default Debian behavior. Ubuntu includes sbin in PATH afaik. In any case Armbian does not alter this.

Ah, I think I know why I didn't 'find' it - trying to run the command as regular user didn't work since it's in /usr/sbin and this path has been removed from the $PATH of regular users. I need to be root in order to have it available. @Werner thank you again for the pointer.

Hi guys, I too have one of these paperweights I'd like to use for a real HA instance to have as a backup if my actual server takes a dump. I was hoping for root access as I'm not a novice when it comes to custom bootloader and roms on other devices but this is a whole different monster. Any tips would be appreciated.

Just as an update, for anyone who cares. The above setup worked well, but I couldn't help but attempting to get video hardware acceleration in a browser. Since my post above, Armbian support for the Nanopi R6S went platinum (thanks to @Efe Çetin), kernel 7 came out and mesa 26 should provide all that is needed for vaapi/v4l2 support in firefox. Unfortunately, minimal Armbian Debian with kernel 7 combined with mesa 26 looks to be some time away - that would allow me to run sway, and likely with firefox using video decode acceleration. OTOH, vendor kernel at 6.1 doesn't seem to allow sway to run at all. So I tried Armbian Debian 13 minimal with kernel 6.18, which runs sway just fine, but the mesa version is stuck at 25.2 which in the standard Debian package does not by default support the rockchip hardware yet, I think. In addition, there seems to be some incompatibility with the repository provided here (or I am doing something wrong, which I wouldn't deny). Fortunately, looking at the Armbian git files I saw that the standard Armbian Ubuntu Noble with vendor 6.1 and Gnome (KDE version doesn't run well) appears to a) work fine with wayland, and b) automatically uses the Amazingfate (liujianfeng1994) PPA. This provides chromium with video hardware decode support, and I can still set up jellyfin. So at this point, without having to compile everything myself from scratch, this is the best setup from my perspective. Shout out to @Efe Çetin for making it this convenient - which it truly is, even though Gnome isn't my preferred DM.

armbianmonitor picks up the wrong temperature to show as "Tcpu". 19:40:09 1600/1600 MHz 0.63 12% 0% 12% 0% 0% 0% 34.9 °C 0/1 19:40:14 1600/1600 MHz 0.66 12% 0% 12% 0% 0% 0% 34.9 °C 0/1 19:40:19 614/ 614 MHz 0.60 5% 0% 4% 0% 0% 0% 34.9 °C 0/1 19:40:24 614/ 614 MHz 0.56 0% 0% 0% 0% 0% 0% 34.9 °C 0/1 19:40:29 614/ 614 MHz 0.51 0% 0% 0% 0% 0% 0% 34.9 °C 0/1 19:40:34 614/ 614 MHz 0.55 1% 0% 0% 0% 0% 0% 34.9 °C 0/1 19:40:39 1000/1000 MHz 0.51 3% 1% 1% 0% 0% 0% 34.9 °C 0/1 19:40:44 614/ 614 MHz 0.47 0% 0% 0% 0% 0% 0% 34.9 °C 0/1 Time CPU_cl0/CPU_cl1 load %cpu %sys %usr %nice %io %irq Tcpu C.St. 19:40:49 1600/1600 MHz 0.51 12% 3% 8% 0% 0% 0% 34.9 °C 0/1 19:40:54 1600/1600 MHz 0.55 15% 4% 10% 0% 0% 0% 34.9 °C 0/1 19:41:00 1600/1600 MHz 0.58 15% 4% 10% 0% 0% 0% 34.9 °C 0/1 19:41:05 1600/1600 MHz 0.70 15% 4% 10% 0% 0% 0% 34.9 °C 0/1^C Meanwhile in 'sensors': cluster1_thermal-virtual-0 Adapter: Virtual device temp1: +45.0°C nvme-pci-10100 Adapter: PCI adapter Composite: +34.9°C (low = -40.1°C, high = +119.8°C) (crit = +129.8°C) Sensor 1: +42.9°C (low = -40.1°C, high = +139.8°C) Sensor 2: +34.9°C (low = -40.1°C, high = +119.8°C) cluster0_thermal-virtual-0 Adapter: Virtual device temp1: +45.0°C So it shows the NVMe SSD temperature instead.

I have a Orange Pi Zero2W with Armbian. I flashed a SD-card, and then I copy the system and boot to a usb- hdd (sda) and the system boot to sda Want hdd because It write much data and USB 2 don't take mush more speed. But I get a warning about a file-error or something so I run fsck on sda(hdd) that was a systemdisk, but when I run I choose to do it read-only, but anyway it does not boot any more. I think I can take the usb-hdd and run fsck from another computer? I have one system with Ubuntu on a Intel 6 gen, and Raspberry pi 500 and 5. The Pi-machine have raspberry-pi OS and the other Ubuntu 24.04.Does the machine or system have any significans? Or is there another fix to fix so the /boot on SD-card can find sda on USB? /Cheers /Edit. I posted under Orange Pi Zero2, but that was wrong place, and get moved, but at the same time get my thread classed as solved, but the solving was just to get the question on right place. I have also cleared my question a little bit and I can not take away the other.

Thanks Nick A for the A7S image! I've been trying out v0.6.4 using Sway on top of the server image w/ a pair of Viture Luma Pro AR glasses as a display. A few things I noticed: - It seems like a display needs to be plugged in at some point during boot for DP to work, but can be unplugged and replugged afterwards without breaking anything. I'd guess that this is the same issue @qq20739111 noted. - Audio over DP doesn't seem to work, and I don't see any sinks available through pactl. Fwiw, I've at least verified DP audio to work on the vendor image, and Bluetooth audio to work on this one. If it'd be useful, here are some boot logs taken over UART: DP plugged in at boot, display output works - https://paste.armbian.eu/vuvoyufuto.yaml DP plugged in after boot finished, no display output - https://paste.armbian.eu/ohoqorupiy.yaml

Off course do I have Orange Pi Zero2W, as I wrote in the beginning, but I thougt there also was an 2E verion and thoungt that orange pi zero 2 was a "over group" with only diffence ethernet and wifi.

I started to have similar issue with recent rolling release (after 26.2.1) mainline kernels: 6.18.2x, 7.0.x, 7.1.0-rc. https://paste.armbian.com/yobewudugo The log seems having all previous boot logs of this board and 6.18.10, 6.18.8 and 6.1.115 can enumerate NVMe SSD but others can't. I did a PCI rescan with 7.1.0-rc2 after booting the board and NVMe SSD was found and corresponding kernel log can be found in the 1st kernel log. I have Armbian image on SD card, btw. sudo bash -c "echo 1 > /sys/bus/pci/rescan"