Active threads

Hi @armfan. From what I am able to extract from the flood of braindumps you have a non-working NVME with 2TB that is not working for some reason. HTH // Sven-Ola

Well as you see, I am not Again, just use dd to grab a backup (dd if=/dev/mtdblock0 of=/somewhere/to/store/spi.backup)

Just an update. Both kernel-7.0.11-edge-rockchip64-26.8.0-trunk.94 and 6.18.34-current-rockchip64-26.8.0-trunk.94 both still NO analog audio output on Headphone Jack on Orange Pi 5-Plus Kernel-6.18.10-current-rockchip64-6.2.1 and 6.19.5-edge-rockchip64 both support analog audio output on Headphone Jack. By the way kernel-6.1.115-vendor-rk35xx also NO analog audio output. kernel-6.1.75-vendor-rk35xx support analog audio output.

I had same issue. i was able to boot using UEFI spi by flashing https://github.com/edk2-porting/edk2-rk3588/releases the rock5b image from this github link. i used this specific armbian image, although it may work with others https://dl.armbian.com/rock-5b/Noble_current_minimal

# Orange Pi Zero 3 (1.5GB) Random Crashes — Root Cause Found & Fixed (No Recompilation Required) **Board:** Orange Pi Zero 3 — 1.5GB LPDDR4 variant **SoC:** Allwinner H618 **OS:** Armbian Trixie **Kernels tested:** 6.6.75-legacy, 6.18.33-current, 6.16.8-edge **Status:** ✅ SOLVED — 72+ hours stable uptime confirmed --- ## The Problem My Orange Pi Zero 3 (1.5GB model) was randomly crashing every few hours under all three Armbian kernel branches. The symptoms were: - System freezes with no response (SSH drops, ping still works briefly) - Kernel oops logged: `kswapd0 → ext4_es_scan → paging request fault` - Random segfaults on normal binaries (`sudo`, `curl`, `apt`) - Corrupted library names in memory (e.g. `libGap-Jg.sK.0` instead of `libcrypto.so.3`) - `memtester` passed clean (2 loops, 1GB) - `badblocks` found zero bad blocks - `fsck` found no filesystem errors - Crashes happened even at full idle, with only ~200MB RAM in use The crashes occurred on **all three kernel branches** — legacy, current, and edge — ruling out a kernel-specific bug as the root cause. --- ## Investigation ### What we ruled out (in order) | Suspect | Test | Result | |---|---|---| | SD card physical failure | `badblocks -sv` | 0 bad blocks | | Filesystem corruption | `fsck -f` | Clean | | RAM hardware failure | `memtester 1G x2` | No errors | | eth-optimize.sh (ring buffer 1024, txqueuelen 10000) | Removed from crontab | Extended stability but didn't fix | | Kernel version | Tested 6.6.75, 6.18.33, 6.16.8 | All crashed | | DRAM size detection bug | `dmesg \| grep Memory:` | Consistently showed 1572864K (correct 1.5GB) | ### The kernel oops — the real clue ``` kernel: Unable to handle kernel paging request at virtual address 14ae620800000018 kernel: CPU: 0 PID: 56 Comm: kswapd0 kernel: Call trace: kernel: __es_tree_search.isra.0+0x20/0xa4 kernel: es_reclaim_extents+0x58/0xf0 kernel: ext4_es_scan+0xf0/0x29c kernel: do_shrink_slab+0x174/0x298 kernel: shrink_slab+0xb4/0x2f0 kernel: kswapd+0x18c/0x3b8 ``` The address `14ae620800000018` is in "address between user and kernel address ranges" — a classic corrupted/invalid pointer. This happens when the kernel accesses memory that physically doesn't exist or wraps around. ### DRAM address wraparound — the root cause The H618 1.5GB LPDDR4 variant has a known DRAM address wraparound issue, documented in the linux-sunxi community (notably by **ag123** in Armbian forums and **Jernej Skrabec's** u-boot size scan patches): > *"It is quite possible the addresses wrap around in the 1.5GB LPDDR4 DRAM chips and the 'test' for memory there returns a false positive."* In this specific case, the **size** is correctly detected as 1.5GB — but the **upper address region** (above 1GB physical) exhibits wraparound behavior. When the kernel accesses the upper ~512MB region (via page cache, kswapd reclaim, or slab allocation), writes to those addresses silently corrupt data in the lower region — because the addresses "wrap" back. This explains why: - `memtester` passes (it tests sequentially in a contiguous region, doesn't trigger wraparound patterns) - Size appears correct (1572864K = 1.5GB every boot) - Crashes are random in timing (depends on when page cache/kswapd reaches the upper region) - ALL kernels are affected (this is a u-boot/hardware level issue, not kernel-specific) --- ## The Fix ### Standard approach (requires u-boot recompilation) The proper fix is `CONFIG_DRAM_SUN50I_H616_TRIM_SIZE=y` in u-boot, or Jernej Skrabec's adjusted size scan procedure (columns-first scanning). This correctly detects and excludes the wraparound region, allowing full 1.5GB usage. ### Our approach — kernel `mem=` parameter (no recompilation needed) Since the wraparound occurs in the **upper address region**, we can simply tell the kernel to only use the safe lower 1GB: Edit `/boot/armbianEnv.txt` and add `mem=1024M` to `extraargs`: ```bash sudo nano /boot/armbianEnv.txt ``` Change: ``` extraargs=... existing params ... ``` To: ``` extraargs=mem=1024M ... existing params ... ``` Reboot and verify: ```bash cat /proc/cmdline | grep -o "mem=1024M" cat /proc/iomem | grep "System RAM" free -h ``` Expected output: ``` mem=1024M 40080000-7fffffff : System RAM total used free Mem: 974Mi ... ``` The `iomem` map confirms the kernel's physical RAM range is **exactly** `0x40080000–0x7fffffff` — stopping at the 1GB boundary. The upper wraparound region (`0x80000000` and above) is completely excluded from the kernel's memory map. ### Why this works The wraparound region begins at or above `0x80000000` (1GB physical offset). With `mem=1024M`: - Kernel allocator, page cache, slab, and all processes stay within `0x40000000–0x80000000` - `kswapd` never reclaims pages from the problematic upper region - The corrupted-pointer crash path is never triggered ### Tradeoffs vs. u-boot fix | | mem=1024M | u-boot TRIM fix | |---|---|---| | Requires recompilation | ❌ No | ✅ Yes | | RAM available | ~974MB | ~1.4GB | | Works on all kernels | ✅ Yes | ✅ Yes | | Fixes root cause | Workaround | Proper fix | For SDR servers, home automation, and similar light workloads where ~974MB is more than sufficient (our system uses ~130–200MB), this is a perfectly viable permanent solution. --- ## Results | Metric | Before fix | After fix | |---|---|---| | Uptime | 1–8 hours max | **72+ hours** (and counting) | | Kernel oops | Multiple per session | **Zero** | | Segfaults | Random, on any binary | **Zero** | | `sudo apt update` | Crashed frequently | Runs perfectly | | Memory corruption | Frequent bit-flips | **None observed** | System configuration at time of testing: - **Kernel:** 6.16.8-edge-sunxi64 - **Kernel param:** `mem=1024M` - **CPU governor:** ondemand - **Workload:** OpenWebRX+, SpyServer, RTL-TCP (x2), radiosonde_auto_rx, Xray proxy --- ## How to apply ```bash # Backup first sudo cp /boot/armbianEnv.txt /boot/armbianEnv.txt.bak # Add mem=1024M to extraargs sudo sed -i 's/^extraargs=/extraargs=mem=1024M /' /boot/armbianEnv.txt # Verify grep extraargs /boot/armbianEnv.txt # Reboot sudo reboot ``` After reboot, confirm: ```bash # Should show mem=1024M cat /proc/cmdline | grep -o "mem=1024M" # Should show ~974Mi total free -h # Should show System RAM ending at 0x7fffffff cat /proc/iomem | grep "System RAM" ``` --- ## References - ag123's analysis of 1.5GB wraparound: Armbian Community Forums - Jernej Skrabec's u-boot DRAM size scan fix: [linux-sunxi mailing list](https://www.mail-archive.com/u-boot@lists.denx.de/msg516769.html) - H618 LPDDR4 support patch: [u-boot mailing list](https://lore.kernel.org/all/20231111091000.26744-2-iuncuim@gmail.com/T/) - ag88's 1.5GB u-boot fix (alternative approach): GitHub --- ## Notes This fix was developed and tested on a **1.5GB LPDDR4** Orange Pi Zero 3. The 1GB, 2GB, and 4GB variants use different DRAM configurations and may not be affected by this specific issue. If you have a 1.5GB board and experience similar random crashes, try `mem=1024M` before spending time on kernel debugging or hardware replacement. It may save you days of investigation. **Tested and confirmed working by:** Özgür Çetinoğlu **Location:** Athens, Greece **Setup:** 24/7 SDR server (OpenWebRX+, radiosonde tracking) **Date:** June 2026

@Taz the sources for that repository is a clone of my build. It’s a very basic attempt to build a 6.19 kernel. You are better off using my build. If you got 6.6 booting then 6.18 should work as well.

This article describes how I successfully configured a PWM fan on an Orange Pi 5 Max running Armbian Debian Trixie Minimal vendor 6.1.115, using the opifancontrol utility. Special thanks to Jamie Sinclair for creating and sharing the opifancontrol project with the community. I have an Orange Pi 5 Max installed in a metal case and running several Docker containers, including Frigate, Immich, Samba, and others. The case originally came with a internal 30x30x10 mm fan, which was not able to provide sufficient cooling. Under load, CPU temperatures were reaching nearly 70°C. To improve cooling, I installed an external 40x40x10 mm PWM fan that was originally used on an Odroid HC4. The fan was mounted using screws, which required drilling holes in the case cover. I also added several ventilation holes, in the case cover above the CPU area to improve airflow. After these modifications, the CPU temperature now stays around 48°C. 1. Install wiringOP Follow the instructions from the wiringOP project: Download wiringOP $ apt-get update $ apt-get install -y git $ git clone https://github.com/orangepi-xunlong/wiringOP.git Build wiringOP $ cd wiringOP $ ./build clean $ ./build Verify the installation: $ gpio readall This command should display the Orange Pi 5 Max GPIO pin map. 2. Configure GPIO Pin 7 as a PWM Output In Armbian, configure GPIO Pin 7 (PWM3_IR_M3) as a PWM output. $ sudo armbian-config Navigate to: System └─ Kernel └─ Overlays Select: rk3588-pwm3-m3 Press the space bar to enable it, save the configuration, and reboot the system. 3. Install opifancontrol: https://github.com/jamsinclair/opifancontrol $ su $ cd /usr/local/bin/ $ wget https://github.com/jamsinclair/opifancontrol/blob/main/opifancontrol.sh $ chmod +x /usr/local/bin/opifancontrol.sh $ curl -sSL https://raw.githubusercontent.com/jamsinclair/opifancontrol/main/install.sh | bash Enable the service to start automatically at boot: $ systemctl enable opifancontrol.service Start the service: $ systemctl start opifancontrol.service Check the service status: $ systemctl status opifancontrol.service 4. PWM Fan Wiring I used a 5V, 4-wire, 4,000 RPM fan from an Odroid HC4. Connection details: Fan Wire Function GPIO Pin Red +5V Power Pin 4 Black GND Pin 6 Blue PWM Speed Control Pin 7 Yellow TACH (RPM Sensor) Not Connected 5. Adjust the Fan Control Configuration Edit the configuration file: $ sudo nano /etc/opifancontrol.conf My settings are: TEMP_LOW=45 FAN_LOW=60 TEMP_MED=60 FAN_MED=75 TEMP_HIGH=70 FAN_HIGH=100 RAMP_UP_DELAY_SECONDS=30 RAMP_DOWN_DELAY_SECONDS=60 After saving the configuration file, restart the service: $ sudo systemctl stop opifancontrol.service $ sudo systemctl start opifancontrol.service With these settings and the hardware modifications described above, my Orange Pi 5 Max now operates significantly cooler, maintaining temperatures around 48°C while running multiple Docker services

I have posted a new release on GitHub. Improved version. https://github.com/joilg/x88pro New: Support for Seekwave EA6521 Wifi Chip on Hardware Version 1.4 Frontdisplay shows now Systen Clock. USB3 support now SuperSpeed (5Gbps) IR Remote control implenented Target OS Ubuntu resolute 26.01 LAN is limited to 100mbps. (major advantage is the low quiescent current in standby mode. An external PHY with 1Gbps consumes a significant amount of power in Wake-on-LAN mod) Feedback welcome.

@hmoob What part do you need clarify? I can help you but I need more information.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Has anyone successfully set up a MIPI screen with their LCD ribbon connectors on Armbian? Any wisdom from someone who has done this would be appreciated.

That sounds like a Klipper message, not from the armbian OS. If there is new functionality in Klipper it will show this error, but you don't always need to reflash the MCU depending on if you use those functions. You can post in a more detailed error and versions in a Klipper forum for advice.

I ran into this as well. Downgrade to kernel 6.12.58 fixed the physical interface. My board that initially had Trixie required the NetworkManager fix to get wifi working even after reverting. Something about the upgrade and/or downgrade broke netplan.

As a data point, I had a CB1 with Trixie that was working fine with netplan until I did an apt upgrade to 26.2.1 and kernel 6.18.xx. The upgrade made my physical interface disappear, which required a kernel downgrade (to 6.12.58) to get back. But even after the downgrade my wireless interfaces still wouldn't connect. The ultimate fix was to switch this board to NetworkManager like I did with my other CB1 that was running bookworm and required the NetworkManager fix from day one.

Tested: - Odroid C4 / HC4 - Tinkerboard - Odroid XU4 - Rockpi E

Hi, I'm using it at the moment as a containers server, thanks for link. I not that changing kernel may run in trouble, so I still keep the 6.1.115 and wait for update. Thanks for your help Regards

It's fixed in 7.1.0-rc6-bleedingedge-rockchip64 Cheers !

Hi there, I recently upgraded my Orange Pi 5 Plus to "Armbian 26.5.1" and noticed in the MOTD (on logins) that it is still showing version "26.2.1". I found differences in this 2 files, and the latter is the one used as reference for MOTD: cat /etc/os-release: PRETTY_NAME="Armbian 26.5.1 trixie" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.5 ID=debian HOME_URL="https://www.armbian.com" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" ARMBIAN_PRETTY_NAME="Armbian 26.5.1 trixie" cat /etc/armbian-release: # PLEASE DO NOT EDIT THIS FILE BOARD=orangepi5-plus BOARD_NAME="Orange Pi 5 Plus" BOARDFAMILY=rockchip-rk3588 BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=77f919f6c LINUXFAMILY=rockchip64 ARCH=arm64 BOOT_SOC=rk3588 IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image KERNEL_TARGET=current,edge,vendor KERNEL_TEST_TARGET=vendor,current FORCE_BOOTSCRIPT_UPDATE= FORCE_UBOOT_UPDATE= OVERLAY_DIR="/boot/dtb/rockchip/overlay" VENDOR="Armbian" VENDORCOLOR="247;16;0" VENDORDOCS="https://docs.armbian.com" VENDORURL="https://www.armbian.com" VENDORSUPPORT="https://forum.armbian.com" VENDORBUGS="https://www.armbian.com/bugs" BOOTSCRIPT_FORCE_UPDATE="no" BOOTSCRIPT_DST="boot.cmd" VERSION=26.2.1 REVISION=26.2.1 BRANCH=edge Can somebody explain why armbian-release doesn't get properly updated? I belive this is not the first time I see this, I recall seeing this behaviour from previuos upgrades too. Thanks!

These Chinese people are very creative. I never imagined seeing a TV box with a SATA port. @Astlin You will need to interact with the .dts file to build a .dtb file with this capability. Before taking any action, check if your board is not from this other JP-Box project. https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-7.1/dt/rk3566-jp-tvbox.dts The topic you should interact with is this one here: https://forum.armbian.com/topic/31887-jianpian-rk3566-tv-box-8g32g-develop-log/#comment-175700 I don't actually have access to the JP-box @Astlin. If you are using the H96 max RK3566 firmware, the SATA port may not be enabled, but you can enable kernel changes within the Armbian compilation menu and insert your changes into the board's DTS file. https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-7.1/dt/rk3566-h96-tvbox.dts I believe the person responsible for this sign is @tdleiyao @ning have tested our DTB file on JianPian device https://github.com/armbian/build/blob/main/config/boards/jp-tvbox-3566.tvb If you have time, we can update the JP-box project in the correct topic. https://forum.armbian.com/topic/31887-jianpian-rk3566-tv-box-8g32g-develop-log/#comment-175700 I have maintained a sample repository with the necessary data to enable RK3566 cards in Armbian. https://github.com/hqnicolas/ArmBoardBringUp The reason JP-box isn't working is that it was enabled in kernel 6.6, and we're already on 7.1, nobody updates this since then. You can use the H96 modifications as start point. this modifications apply to the JP-box, but some functions, such as the SATA port, require customization.

Hi, my knowledge about Armbian is limited. For such a specific configuration/compilation I suggest that you open a new topic under "Allwinner sunxi". Best regards.

The solution I've found is to use a HDMI to VGA converter and use the VGA port

@Sancho perfect. I will try it out and will inform you later. I have also discovered that the power adaptors packed with the iSG Box are low quality and some of those can't even reach 1,5 A. Which can cause instability issues and failed HA updates, install, armbian crashes, etc.

Thanks for sharing the header file. I have downloaded that and deployed using dpkg -i <packge name> In order to deploy the VFD, the steps I have followed are given here. I have enclosed the attachment that contains commands and their outcome to keep this post shorter. Below given error message while trying to start the openvfd.service root@x98h:~/linux_openvfd#systemctl daemon-reload root@x98h:~/linux_openvfd# systemctl start openvfd.service Job for openvfd.service failed because the control process exited with error code. See "systemctl status openvfd.service" and "journalctl -xeu openvfd.service" for details. root@x98h:~/linux_openvfd# systemctl status openvfd.service × openvfd.service - openvfd Loaded: loaded (/etc/systemd/system/openvfd.service; disabled; preset: ena> Active: failed (Result: exit-code) since Tue 2026-06-02 00:07:40 IST; 4min> Process: 2297 ExecStartPre=/usr/bin/sh -c . /etc/openvfd.conf; /usr/sbin/mo> Process: 2299 ExecStopPost=/usr/sbin/rmmod openvfd (code=exited, status=1/F> CPU: 47ms Jun 02 00:07:40 x98h systemd[1]: Starting openvfd.service - openvfd... Jun 02 00:07:40 x98h sh[2298]: modprobe: ERROR: could not insert 'openvfd': Exe> Jun 02 00:07:40 x98h systemd[1]: openvfd.service: Control process exited, code=> Jun 02 00:07:40 x98h rmmod[2299]: rmmod: ERROR: Module openvfd is not currently> Jun 02 00:07:40 x98h systemd[1]: openvfd.service: Failed with result 'exit-code> Jun 02 00:07:40 x98h systemd[1]: Failed to start openvfd.service - openvfd. Jun 02 00:07:40 x98h systemd[1]: Failed to start openvfd.service - openvfd. ░░ Subject: A start job for unit openvfd.service has failed ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A start job for unit openvfd.service has finished with a failure. ░░ ░░ The job identifier is 782 and the job result is failed. Jun 02 00:15:18 x98h systemd[1]: Starting openvfd.service - openvfd... ░░ Subject: A start job for unit openvfd.service has begun execution ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A start job for unit openvfd.service has begun execution. ░░ ░░ The job identifier is 855. Jun 02 00:15:18 x98h sh[2317]: modprobe: ERROR: could not insert 'openvfd': Exec format error Jun 02 00:15:18 x98h systemd[1]: openvfd.service: Control process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ An ExecStartPre= process belonging to unit openvfd.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Jun 02 00:15:18 x98h rmmod[2318]: rmmod: ERROR: Module openvfd is not currently loaded Jun 02 00:15:18 x98h systemd[1]: openvfd.service: Failed with result 'exit-code'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ The unit openvfd.service has entered the 'failed' state with result 'exit-code'. Jun 02 00:15:18 x98h systemd[1]: Failed to start openvfd.service - openvfd. ░░ Subject: A start job for unit openvfd.service has failed ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A start job for unit openvfd.service has finished with a failure. ░░ ░░ The job identifier is 855 and the job result is failed. VFD_Service_Logs.txt

Orange Pi 5B subforum has recurring threads about eMMC boot loops, WiFi/Bluetooth regressions on mainline kernels, and the general "what image actually works on this thing" question. Joshua-Riek's ubuntu-rockchip was a common answer to that for a long time, but it was archived recently. This is a personal continuation fork in case it's useful to anyone working through those same issues. What this is: - Fork of Joshua-Riek/ubuntu-rockchip (archived) — same vendor 6.1 kernel base, not mainline - Therefore: onboard WiFi/BT works (no mainline driver regressions), eMMC boots reliably - Scope: Orange Pi 5B + Ubuntu 24.04 (Noble) only. jammy/oracular/plucky suite configs removed. - Single-maintainer hobby project. Best-effort, no SLA. v1.0.0 contents: - Kernel ABI bumped to 6.1.0-1027.27 - Backported CVE-2026-46333 (ssh-keysign-pwn) — upstream commit 31e62c2ebbfd cherry-picked onto noble-security branch - Build-kernel.sh patched for GCC 14+ host compatibility (the 6.1 vendor tree's -Werror defaults conflict with stricter warning-to-error promotion introduced in GCC 14 and inherited by GCC 15)"— the 6.1 vendor tree fails to compile on Ubuntu 24.04+ / Debian Trixie+ hosts due to -Werror promotion. Fix is KCFLAGS=-Wno-error for the kernel proper plus sed-stripping hardcoded -Werror from libbpf, libsubcmd, objtool, and libperf tool Makefiles. Without this, you can't rebuild Joshua's kernel from source on a modern host. - Tested as a daily driver on OPi 5B hardware with reboot loop test, cpu burn. running 4k screensaver. Known limitations (carried over from upstream): - Mali GPU PPA (panfork-mesa) and jjriek/rockchip userspace PPAs are no longer maintained. Frozen at the versions Joshua left them. Not a competitor to Armbian — different scope, different kernel approach. If you're getting clean results with Armbian on your 5B, stick with what works. This is for the case where Armbian's mainline kernel breaks onboard hardware or you specifically need the Joshua-Riek tree. Credit: this is a continuation, not original work. Joshua-Riek did the heavy lifting; LICENSE, NOTICE, and README all credit upstream. Repo: https://github.com/defcom5-rockchip/ubuntu-rockchip Kernel: https://github.com/defcom5-rockchip/linux-rockchip-rk3588 Release: https://github.com/defcom5-rockchip/ubuntu-rockchip/releases/tag/defcom5-v1.0.0 (1.86GB .img.xz + sha256) Peace, defcom5

I was curious and looked into your script, I see parted uses sizes like 32MiB instead of sector numbers I tend to do when using gdisk or fdisk It is only the function write_uboot_platform_ufs() in the image that deals with 512/4k and then it is no issue for Btrfs as this is not related to CPU page-size issues I hinted earlier. So also older kernel is no issue and also RK3576 cannot do e.g. 16k page-size.