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! The board gets unnormally hot with when i attach the 2.5G Router Hat. (Powered though the HAT) I tried vendor and edge kernel. Same result. Using the radxa image, its significantly cooler. First look through dts i cannot find any problem. Maybe someone has a better understanding? Thanks Jakob

Hello, I have experimented with a Realtek USB 2.5Gbe USB Ethernet dongle and find that it works fine with the vendor kernel but not with kernels 6.12.x or 6.18.y. I have included an iperf3 example below, you can see that the dongle manages a few runs at high speed before it quietly fails and seizes up. I use a number of these dongles and they tend to work fine on other set-ups. Any thoughts about a resolution? dmesg output: [Tue Mar 17 11:37:00 2026] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd [Tue Mar 17 11:37:00 2026] usb 2-1: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=31.00 [Tue Mar 17 11:37:00 2026] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [Tue Mar 17 11:37:00 2026] usb 2-1: Product: USB 10/100/1G/2.5G LAN [Tue Mar 17 11:37:00 2026] usb 2-1: Manufacturer: Realtek [Tue Mar 17 11:37:00 2026] usb 2-1: SerialNumber: 0013000001 [Tue Mar 17 11:37:00 2026] usbcore: registered new device driver r8152-cfgselector [Tue Mar 17 11:37:00 2026] r8152-cfgselector 2-1: reset SuperSpeed USB device number 2 using xhci-hcd [Tue Mar 17 11:37:01 2026] r8152 2-1:1.0 eth0: v1.12.13 [Tue Mar 17 11:37:01 2026] usbcore: registered new interface driver r8152 [Tue Mar 17 11:37:01 2026] usbcore: registered new interface driver cdc_ether [Tue Mar 17 11:37:01 2026] usbcore: registered new interface driver cdc_ncm [Tue Mar 17 11:37:01 2026] usbcore: registered new interface driver cdc_wdm [Tue Mar 17 11:37:01 2026] usbcore: registered new interface driver cdc_mbim [Tue Mar 17 11:37:01 2026] r8152 2-1:1.0 enx00e04c680142: renamed from eth0 [Tue Mar 17 11:37:02 2026] xhci-hcd xhci-hcd.3.auto: WARN: HC couldn't access mem fast enough for slot 1 ep 6 [Tue Mar 17 11:37:02 2026] r8152 2-1:1.0 enx00e04c680142: intr status -63 [Tue Mar 17 11:37:07 2026] xhci-hcd xhci-hcd.3.auto: WARN: HC couldn't access mem fast enough for slot 1 ep 6 [Tue Mar 17 11:37:07 2026] r8152 2-1:1.0 enx00e04c680142: intr status -63 [Tue Mar 17 11:37:35 2026] xhci-hcd xhci-hcd.3.auto: WARN: HC couldn't access mem fast enough for slot 1 ep 6 [Tue Mar 17 11:37:35 2026] r8152 2-1:1.0 enx00e04c680142: intr status -63 Subsequent iperf3 example: iperf3 -c nx1 Connecting to host nx1, port 5201 [ 5] local 192.168.1.191 port 58598 connected to 192.168.1.14 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 221 MBytes 1.85 Gbits/sec 0 5.35 MBytes [ 5] 1.00-2.00 sec 280 MBytes 2.35 Gbits/sec 0 5.35 MBytes [ 5] 2.00-3.00 sec 280 MBytes 2.35 Gbits/sec 0 5.35 MBytes [ 5] 3.00-4.00 sec 18.1 MBytes 152 Mbits/sec 1 1.41 KBytes [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 800 MBytes 670 Mbits/sec 1 sender [ 5] 0.00-10.86 sec 796 MBytes 615 Mbits/sec receiver

I have a RK3588 (Radxa Rock 5C) system running Armbian Debian Trixie. I have the heatsink and the fan installed as well. I set the fan PWM to 255 as soon as temperature reaches 50 degrees via a systemd service. When using all 8 cores, the system overheats (>110 degrees) and eventually shuts down. For example, when compiling ffmpeg, it works fine with 'make -j6', but 'make -j8' results in a shutdown before compilation is complete. Likewise I had thermal issues when using llama.cpp. Shouldn't the OS throttle the CPU when temperature reaches high levels? I think that is not happening at the moment. Online search referred me to cpufrequtils to set a conservative governor, but it looks like cpufrequtils does not exist for Trixie. Any suggestions on how I should approach this?

Hi everyone, I have rock 5c with PWM fan. I want to control the fan speed manually. Running on Armbian 25.11.1 Noble. Sorry if its obvious I am newbie to this

Board : radxa rock 5c lite with NVMe HAT and SPI Flash Module. OS : Armbian 25.11.2 stable 6.1.115-vendor-rk35xx (Debian trixie) Overlays : rock-5a-spi-nor-flash SPI Flash is on /dev/mtdblock0 Boot from SD : OK Boot from SD system on NVMe : OK ---- I want to boot from Flash, so I tried `Install/Update the bootloader on MTD Flash` menu on `armbian-config'. Then I got this message. No SPI image found. I also updated SPI with `rsetup` from Radxa OS, but it does not work(boot from NVMe failed) either. What do I have to do?

Hi Installed Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img and one of the USB-3 port, the top one, doesn't work. No reaction when inserting something, nothing in /var/log/syslog. The same with Armbian_25.11.1_Rock-5c_noble_current_6.12.58_minimal.img The Armbian_25.11.1_Rock-5c_trixie_vendor_6.1.115_minimal.img however is OK. What could be the cause of this problem? Thanks and regards, Chris

Hi I dd the Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img to a SD card (/dev/sdc) and then run a fsck -f /dev/sdc1 and got errors: sudo fsck -f /dev/sdc1 fsck from util-linux 2.39.3 e2fsck 1.47.0 (5-Feb-2023) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Entry '.' in ??? (1065) is duplicate '.' entry. Fix<y>? .... Tried few SD cards, same result. Tried those SD cards with other images, i.e. Armbian_24.8.4_Rock-5c_bookworm_vendor_6.1.75_minimal.img no problems. Could anybody verify this behavior? Thanks Chris Armbian_25.11.1_Rock-5c_trixie_vendor_6.1.115_minimal.img image generates the same problem.

Starting today Oct 27 2025 I'm not able to upgrade armbian on Radxa 5C for any version from 6.12 and up with the multiple exceptions like this: Err:6 http://apt.armbian.com trixie/main arm64 armbian-plymouth-theme all 25.8.2 Hash Sum mismatch Hashes of expected file: - SHA512:718d46957b9e9940ba7569761069864c46b07bd5570db462894b81d2730803dc9f9b0618ed45104c6357b92ddf00600a9664b93bd3eaca8c453b4724ba495688 - SHA256:3ee8733f28c38f66f3a1328c93bf75d00416f8e2d1e7a5c91f4727489d7c1b00 - SHA1:2ad501942596de1a53e9339284635a712346a245 [weak] - MD5Sum:a7dc1e7a3ff05af314e49c0b841ce240 [weak] - Filesize:112140 [weak] Hashes of received file: - SHA512:f37ac430cdadcacde0d016447ff82f58ee81f9142523a39252096fc09cdb90542346bfb496be7993502ac309cfae68d22a740b4d5aadb66b687b89ad88ed4d80 - SHA256:b9a7ed2ceebe4cce4aab2f4366c8a1bd3479dec7923294b231cf529bfff137eb - SHA1:76b110fec39b59188a68e1c7e67aeb18de411bc3 [weak] - MD5Sum:3bc7dc9b0ba091d9227cc3693847ed97 [weak] - Filesize:112140 [weak]

Hi! After installing mesa-va-drivers and vainfo, I'm only getting an error message that `rockchip_drv_video.so` is missing. So, evidently there's a VA driver registered and available (somewhere), but the file is missing? Where do I find it, how do I install it? Thank you

Hello, I'm trying to connect a MIPI DSI display. Currently, backlight is working, but not the display in Armbian (Armbian 25.5.1 Noble Gnome). DTS is loaded and corresponding kernel module panel-simple-dsi is loaded as well. Same DTS works on the official Radxa 5c image (rock-5c_bookworm_kde_b2) (kernel 6.1.43-15) Has anyone faced a similar issue? armbianmonitor -u : https://paste.armbian.com/ocoperohak.yaml Thanks!

Is there any trick to make use of the integrated fan on Radxa 25W PoE Hat? I'm using 4GB Radxa Rock 5C Lite Armbian_25.5.1_Rock-5c_bookworm_vendor_6.1.115_minimal Some guides mention that one should enable an overlay. I didn't find any relevant overlays in armbian-config. In the Radxa repo I found rock-5a-radxa-25w-poe.dts which specifies that it's also compatible with Rock 5C. I've compiled it and enabled it, but by default the fan is not spinning (on high temps) and I'm not sure how to investigate that. Also, does it matter that I have 5C Lite? As it has another chip: RK3582

Hi I am looking for a low power, fanless, solution for a Debian server with a single large 3.5" SATA drive. I don't want to boot from the SATA so I guess I'd buy an eMMC module as well. Currently I have an Orange Pi4 LTS with a weird expansion board and a generic Mini PCIe to SATA, but it isn't stable enough. Given that the Rock 5C has platinum support and works with the Penta SATA hat I'm wondering if it might be more reliable? thanks

I just tested the latest, 2025 May, built image with default/recommended options and there are some missing features. Here is what I have tested: LAN yes WiFi yes BT yes USB3 *partly, some devices are not detected at all, some will take a few minutes before detected* GPU Mali-G610 (Panfrost) HDMI audio *no* Fan control yes temp. sensor htop *no* Temp. sensor Gnome *no* Other: some cursor graphic glitches Armbian-unofficial_25.05.0-trunk_Rock-5c_noble_current_6.12.28_gnome_desktop.img Any ideas on how to get more features supported?

Hi I installed https://dl.armbian.com/rock-5c/Bookworm_current_minimal-homeassistant, configured it to my liking (OS on a mirrored ZFS pool) to discover there is no WiFi, no Bluetooth. It's now kernel 6.12.17-current-rockchip64. Anybody managed to get WiFi and BT working with this kernel? Thanks, Chris

I have a rock 5c headless server running debian minimal with kernel 6.12.20. It runs fine for my use case, but the fan runs at full speed by default. I can manually set different fan speeds in /sys/devices/platform/pwm-fan/hwmon/hwmon2/pwm1 I have selected 'fanctrl' in armbian-config, but this does not reduce the default speed of the fan. I noticed that there are some recent patches published here and here, I assume these patches are there to deal with the fan control deficiency? Could these patches either a) be applied to the rock 5c dts file that comes with the armbian image or b) perhaps it is better to create a user defined overlay in /boot/overlay-user/? Would someone be able to assist with guidance on how to implement the required modifications?

I saw someone using ZFS on their Netgate hardware and their eMMC fails in a year. Would BTRFS significantly shorten lifespan of eMMC/SD card, like ZFS does?

After working in the ssh session for a while, the message suddenly appears: Broadcast message from user@rock-5c (Wed 2025-02-26 11:08:02 CET): The system will suspend now! Judging by the entries of journalctl, suspend is triggered in the kernel, not in systemd $ journalctl -b | grep -i suspend Feb 26 11:00:29 rock-5c kernel: rk806 spi2.0: dvs-suspend-control-by missing! Feb 26 11:00:29 rock-5c kernel: rockchip-dmc dmc: suspend_rate = 528000000 Feb 26 11:00:29 rock-5c kernel: rockchip-dmc dmc: deep_suspend_rate = 2112000000 Feb 26 11:00:29 rock-5c kernel: rockchip-pm rockchip-suspend: not set pwm-regulator-config Feb 26 11:00:29 rock-5c kernel: rockchip-suspend not set sleep-mode-config for mem-lite Feb 26 11:00:29 rock-5c kernel: rockchip-suspend not set wakeup-config for mem-lite Feb 26 11:00:29 rock-5c kernel: rockchip-suspend not set sleep-mode-config for mem-ultra Feb 26 11:00:29 rock-5c kernel: rockchip-suspend not set wakeup-config for mem-ultra Can anyone tell me what the cause is and how I can fix it?

I compiled Armbian Rock-5c bookworm vendor 6.1.99 minimal. WiFi driver extension radxa-aic8800.sh breaks Rock 5C vendor (kernel 6.1.99) boot. I compiled without the extension to confirm. The radxa-aic8800 driver has recently been modified in the download source. I modified radxa-aic8800.sh to download the previous driver version "3.0+git20240327.3561b08f-2" and this does not fix the issue. Ref: Jira AR-2603 Logs attached. Any fix or insight would be good. @amazingfate is this something that you might have ideas about? armbian-hardware-monitor.log rock5c-debug.log

Hello I'm trying to netboot a Rock 5C lite SBC via U-boot and a TFTP + NFS server. U-boot is working fine and is able to fetch the armbian.Image and fdt file (rk3588s-rock-5c.dtb) I provide through pxelinux.cfg/{device_mac_addr} file: LABEL Armbian MENU LABEL Armbian KERNEL /srv/tftp/armbian.Image FDT /srv/tftp/rk3588s-rock-5c.dtb APPEND root=/dev/nfs nfsroot=192.168.1.46:/srv/nfs/armbian,vers=3 rw ip=dhcp rootwait (To be complete I have U-boot installed on a SPI flash module configured to fetch the files with pxe commands: pxe get; pxe boot). To create the armbian.Image (kernel) I used the build repository and edited the kernel config with the attached file (linux-rockchip64-current.config): ./compile kernel-config ROOTFS_TYPE=nfs BOARD=rock-5c EXTRAWIFI=no BRANCH=current cp output/config/linux-rockchip64-current.config config/kernel/ ./compile SHARE_LOG=yes (Unfortunately the log URL resulted in a HTML error strangely? So I'm going to provide it as an attachment instead.) Then I extracted the vmlinuz file provided into output/debs/linux-image... renamed it to armbian.Image and put it on my TFTP server. As you can see I enabled NFS in almost all ways because the rootfs is located on the NFS server (192.168.1.46). However the serial console tells me it cannot boot (serial_output.txt). It seems there's an issue with NFS whereas I thought I had enable it. [ 113.632537] VFS: Unable to mount root fs via NFS. I'm pretty sure this is not the right way to get the bootable image (I mean by extracting it from the deb archives). So I gave a try with https://github.com/ophub/kernel/releases/tag/kernel_rk3588 and it went further at least sending me into an initramfs I guess but failing to mount the NFS rootfs. Can anyone bring some lights to me? BR Thomas linux-rockchip64-current.config serial_output.txt log-build-B310C8B5-F0CC-4A98-90F3-D1EBE517955E.log

Hi, I bought a Rock 5C with the official fan/heatsink: https://radxa.com/products/accessories/heatsink-6540b/ After installing the Armbian server image, I ran these two commands: ```bash ls /sys/class/thermal/cooling_device*/type cat /sys/class/thermal/cooling_device*/type ``` and found that there is no `pwm-fan`. Then I installed the official Radxa Debian image and ran these two commands again. `pwm-fan` exists and I can make it starts spinning by running: ```bash echo 255 | sudo tee /sys/devices/platform/pwm-fan/hwmon/hwmon*/pwm1 ``` Is the fan module supported in Armbian? If yes, how do I activate it?

I'm booting it from Armbian_24.11.1_Rock-5c_bookworm_vendor_6.1.75_minimal.img.xz image from a SD card. When launching `armbian-install`, there's only one option: (5) - Install to SD card I would like to install the bootloader to the SPI flash module but the option is not present. Furthermore it seems that my SPI module isn't detected either when running ls /dev/mtd* -> no mtdblock I decided to move on and I flashed https://dl.radxa.com/rock5/5c/images/loader/spi/rock-5c-spi-image-20240528.img to my 5C lite SPI flash module. However, there's no display and both LEDs are lighted up (green and blue) without blinking. I suggest it didn't work well. Can someone confirm? BR

Hi, I am running the latest Armbian image with Noble + GNOME for the Rock 5C. I have build it using the `compile.sh` script without altering the kernel, desktop enabled, based on Noble, with GNOME, no applications, no extensions. Added the kisak PPA repo afterwards and enabled the panthor overlay for hardware acceleration. Should be close to the `Armbian_24.11.1_Rock-5c_noble_vendor_6.1.75_gnome-kisak_desktop.img` image, I think. With Chromium (few tabs), VSCodium (working on some code) and a couple of terminals open, things were crashing all the time. Here is a reproducable example with Chromium, when navigating to the URL: https://www.geeksforgeeks.org/ulimit-soft-limits-and-hard-limits-in-linux/ sander@rock-5c:~$ chromium [3743:3743:1213/231308.263364:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.ScreenSaver.GetActive: object_path= /org/freedesktop/ScreenSaver: org.freedesktop.DBus.Error.NotSupported: This method is not part of the idle inhibition specification: https://specifications.freedesktop.org/idle-inhibit-spec/latest/ [3743:3795:1213/231308.438912:ERROR:backend_impl.cc(989)] Critical error found -8 [3743:3795:1213/231308.439341:ERROR:entry_impl.cc(955)] Failed to save user data [3743:3795:1213/231308.821432:ERROR:backend_impl.cc(989)] Critical error found -8 [3743:3795:1213/231308.821616:ERROR:entry_impl.cc(955)] Failed to save user data [3743:3743:1213/231308.821621:ERROR:gpu_disk_cache.cc(233)] Failed retry to open blob cache entry: -2 [3845:3861:1213/231317.658891:ERROR:ffmpeg_common.cc(970)] Unsupported pixel format: -1 [4052:4052:1213/231324.240574:ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11) [4057:4057:1213/231324.266795:ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11) [3743:3793:1213/231324.269115:ERROR:zygote_communication_linux.cc(164)] Did not receive ping from zygote child [3743:3793:1213/231324.269180:FATAL:check.cc(361)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry! [3764:3764:1213/231324.269109:ERROR:zygote_linux.cc(639)] Zygote could not fork: process_type renderer numfds 5 child_pid -1 [1213/231324.290657:ERROR:elf_dynamic_array_reader.h(64)] tag not found Trace/breakpoint trap I was also not able to use Firefox, at all. Every new tab ended up in a "Snap. Your page crashed" view. The root cause seems to be this: ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11) After some web searching, I found that the thread limits are set to a very low value. (note "max user processes") sander@rock-5c:~$ cat /proc/sys/kernel/threads-max 1685 sander@rock-5c:~$ ulimit -a real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 842 max locked memory (kbytes, -l) 1015884 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 842 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited I searched through the Armbian build repository for code that sets these limits, but I didn't find any. Seems that these limits are set or calculated by rockchip linux kernel. After applying a few configuration changes, the system becomes much more stable and I have not had any crashes so far. # /etc/rc.local (updated) echo 16384 > /proc/sys/kernel/threads-max # /etc/security/limits.d/99-nproc.conf (created) * soft nproc 4096 * hard nproc 4096 # /etc/systemd/system.conf (updated) #DefaultTasksMax=15% DefaultTasksMax=infinity After a reboot, the changes are now applied. And no more crashes! And Firefox now works as well. sander@rock-5c:~$ cat /proc/sys/kernel/threads-max 16384 sander@rock-5c:~$ ulimit -u 4096 Hope this is useful to someone else.

I am trying to boot my Rock 5C Lite from an NVME drive, but have experienced some problems with the vendor kernel. I followed instructions by amazingfate in this forum to create a small SD card with a u-boot image, ie I created a complete Armbian image (vendor kernel) on an SD card too boot up the Rock 5c Lite A second, small capacity SD card was inserted into the USB port using a USB adapter U-boot was transferred from /usr/lib/linux-u-boot-*/ to the small SD card: dd if=./idbloader.img of=/dev/sda seek=64 conv=notrunc status=progress dd if=./u-boot.itb of=/dev/sda seek=16384 conv=notrunc status=progress My chosen Armbian image was transferred to the NVME drive using Balena Etcher Finally I use the small SD card with u-boot in the SD card slot on the 5C Lite and the NVME drive goes in the NVME hat. I tried two different images from here on the NVME drive Debian 12 (Bookworm) with XFCE and bleeding edge kernel v6.11 Debain 12 (Bookworm) with XFCE and vendor kernel v6.1 The board boots fine from the NVME using the v6.11 kernel, but the implementation seems to be nowhere near complete. The HDMI port doesn't work, the fan is spinning at full speed but is difficult to control because CPU temp is not reported properly, etc. The bord performs well though, and reports eight functioning CPU's. The board does not boot from the NVME using the v6.1 vendor kernel. It tries to start up the kernel but gets stuck. Please see the attachment below for a copy of my complete console output at high verbosity. Would someone be able to help to get the vendor kernel to work? UART-Log_Vendor-Kernel.txt

Login, type "sudo armbianmonitor -u" and copy the URL here. the command failed with the following error : /usr/bin/armbianmonitor: ligne 976: iostat : commande introuvable img used : Armbian_24.8.4_Rock-5c_bookworm_vendor_6.1.75-omv_minimal.img.xz hardware : https://docs.radxa.com/en/accessories/penta-sata-hat https://docs.radxa.com/en/rock5/rock5c 4 ssd samasung evo 870 The image works perfectly when flashed on a SD card and booting from the SD card, the Radxa pentaHat works, the disk are powered (green led for the hat, blue led per each disk). However, when the image is flashed on emmc, the OS boot normaly but the pentaHat does not work, the disk are not powered and not detected by the os (green led Ok, no blue led for the disk) Does any of you have an idea why it works using the SD card and not with the emmc ? is their some settings or overlay that could help fix this issue. I tried the radxa img for the rock5c and it works with either emmc or sd card (https://github.com/radxa-build/rock-5c/releases) Thank you for your answers and help!