All Activity

For microSD card slot to even work at all, it is listed as a change that landed only in 7.2. https://www.phoronix.com/news/SpacemiT-K1-K3-Linux-7.2 This is why you get root filesystem UUID not found with 7.0-7.1

Sorry, forgot about that. Here are logs from a boot of Debian minimal with GNOME and updated packages: https://paste.armbian.com/eyaxadazow

https://github.com/ThomasKaiser/sbc-bench/blob/master/results/rca7s.txt here are my results with an old (November 2025) kernel

test with 1.5V CPU voltage, the SBC draws over two amps. You need a really good active heatsink. 7-Zip (r) 25.01 (arm64) : Igor Pavlov : Public domain : 2025-08-03 64-bit arm_v:8-A locale=en_US.UTF-8 Threads:8 OPEN_MAX:1024, ASM Compiler: ver:14.2.0 GCC 14.2.0 : UNALIGNED Linux : 6.6.98-vendor-sun60iw2 : #2 SMP PREEMPT Fri May 15 10:57:21 CEST 2026 : aarch64 PageSize:4KB hwcap:119FFB:CRC32:SHA1:SHA2:AES:ASIMD arm64 1T CPU Freq (MHz): 1267 2000 2000 2000 2000 2000 2000 4T CPU Freq (MHz): 366% 1621 367% 1631 8T CPU Freq (MHz): 742% 1561 746% 1580 RAM size: 5906 MB, # CPU hardware threads: 8 RAM usage: 1779 MB, # Benchmark threads: 8 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 9894 757 1272 9625 | 226530 685 2821 19317 23: 9405 767 1249 9583 | 219768 687 2768 19010 24: 8867 766 1245 9535 | 213378 689 2717 18722 25: 8382 753 1271 9571 | 205891 692 2649 18320 ---------------------------------- | ------------------------------ Avr: 9137 761 1259 9578 | 216392 688 2739 18842 Tot: 724 1999 14210 And the same test with 1.32V, SBC draws 1.5 amps Last login: Fri Jun 5 11:11:21 2026 from 192.168.11.50 root@radxa-cubie-a7s:~# 7zr b 7-Zip (r) 25.01 (arm64) : Igor Pavlov : Public domain : 2025-08-03 64-bit arm_v:8-A locale=en_US.UTF-8 Threads:8 OPEN_MAX:1024, ASM Compiler: ver:14.2.0 GCC 14.2.0 : UNALIGNED Linux : 6.6.98-vendor-sun60iw2 : #2 SMP PREEMPT Fri May 15 10:57:21 CEST 2026 : aarch64 PageSize:4KB hwcap:119FFB:CRC32:SHA1:SHA2:AES:ASIMD arm64 1T CPU Freq (MHz): 1393 1682 2000 2000 2000 2000 2000 4T CPU Freq (MHz): 369% 1606 367% 1634 8T CPU Freq (MHz): 743% 1552 745% 1573 RAM size: 5906 MB, # CPU hardware threads: 8 RAM usage: 1779 MB, # Benchmark threads: 8 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 9314 722 1254 9061 | 224321 686 2790 19128 23: 8943 752 1211 9113 | 217854 688 2739 18845 24: 8556 749 1228 9200 | 210699 688 2686 18487 25: 8216 754 1244 9382 | 202281 686 2623 17999 ---------------------------------- | ------------------------------ Avr: 8758 745 1234 9189 | 213789 687 2710 18615 Tot: 716 1972 13902 root@radxa-cubie-a7s:~#

I wanted to report a specific regression regarding CPU frequency scaling on the Radxa Cubie A7S and share the DTS workaround that fully restores complete functionality. The Regression Behavior November Kernel State: Using the kernel branch/commit built back in November (running Linux version 6.6.98-vendor-sun60iw2 #SMP PREEMPT Wed Nov 19 2025 ), CPU frequency scaling worked perfectly out of the box. All available frequencies scaled smoothly across both core clusters, and the benchmark results for my specific A7S board were fully aligned with Thomas Kaiser's provided optimization targets. May Kernel State: After updating to the recent kernel build (mid-May 2026), CPU frequency scaling completely broke under the stock DTB configuration. The core clusters refused to scale through their operational performance points properly. The Frequency Trick & DTS Fix The root cause was isolated to how cpufreq binds under the newer kernel configuration, specifically linked to the inclusion of CONFIG_CPUFREQ_DT_PLATDEV=y. To make the scaling work seamlessly on the latest May kernel, the underlying Device Tree needs a dedicated adjustment in the opp-table and driver mapping. By manually adapting the standard DTS bindings for the sun60iw2 platform to explicitly force correct platform-device scaling registration, all operational frequencies are now fully functional and stable again on the new kernel. Request for Review/Merge@Nick (or current DTB maintainer), cubie_a7s.zip could you please verify this behavior against the latest repository changes? If everything checks out on your end, please pull this DTS patch into the main Armbian sunxi tree so that the Cubie A7S doesn't remain locked to lower fallback states on fresh updates.Let me know if you need the raw diff -u dump of the modified .dts files attached! cubie_a7s.zip

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. If it really stops sometimes in the middle of u-boot::nvme::init then you may have some power issue with this NVME. For comparison: I placed my NVME in the lower m.2 and booted via MTD the u-boot armbian-installed from the "current" image downloadable from my site. See attached capture file. HTH // Sven-Ola nvme-lower-uboot-may-26-2026.cap

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.

Thanks for your help Werner. I'm surprised that the SPI version of U-Boot would prevent an SD Card booting. Once the SPI U-Boot had failed to boot from NVME, USB, etc one would hope that the oPi5 delegated all responsibility to the SD Card, to minimize the risk of bricking. I'm a bit reluctant to wipe my SPI which currently works with NVME. As with SmoothCrimnal75 my SPI version of U-Boot will boot a 26.5 Armbian SD Card using a USB adapter, it only fails from the SD Card slot. So I can use the USB adapter for testing the new release. If I want to transfer it to the NVME, I suspect my current U-Boot SPI will work for that too.

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.

@sven-ola About the issue you saw (re. UUID=63ee7593-e111-4547-ac2f-6bdb8519ce11..), what I have done is flash either of the two images at https://sven-ola.commando.de/privat-in/ to a 128GB MicroSD card using Win32DiskImager or Rufus on Windows, and then booted the RV2 with it, that's all. The RV2 has had two PCI devices connected at boot. This should not affect the boot sequence. I sent you all kinds of weird boot sequences I had especially with the Linux 7.10 Armbian image. I gave a few hours to try these Armbian images on the RV2, and ultimately it's not stable. The biggest issue is to boot from the M.2 SSD. Then, the 6.18 boots well from MicroSD but the 7.10 not. Finally my SFP+ NIC doesn't work well on the 6.18. I had more success with the testing in the beginning, e.g. I got the 7.10 image to work booted from the SSD. Could there be an issue with power supply, for example with the 5V to 3.3V converter on the PCB. For power supply I use a good 5V @ 5A USBC power supply. The most successful test I did was, flash a MicroSD card with the 6.18 image, and boot it on the RV2. Then from inside that environment, do dd if=Armbian-unofficial_26.05.0-trunk_Orangepirv2_trixie_edge_7.1.0-rc3_minimal.img of=/dev/nvme0n1 bs=100M status=progress; sync . Booting from that NVMe did work a few times. I installed the u-boot bundled with Armbian to the SPI using armbian-config. I'm not sure this was a good idea, at least it did not make NVMe booting work better.

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

Then wipe spi and retry. You can also pull a backup, simply via dd

I'm having trouble booting my Orange Pi5 off an SD Armbian_26.5.1_Orangepi5_trixie_vendor_6.1.115_minimal.img. I just get a blank screen. Older versions of Armbian do boot off an SD card, it also boots off NVME. I do have an old version of U-Boot flashed on SPI (Thanks to Joshua Riek), which I use because it is compatible with my KingSpec NVME drives, other versions of U-Boot did not recognize KingSpec NVME, including Armbian versions of U-Boot. I last tested Armbian U-Boot about 6 months ago, it failed. The Console log looks normal-ish right up to the point it just stops. Console Log --- DDR 9fffbe1e78 cym 24/02/04-10:09:20,fwver: v1.16 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB Manufacturer ID:0x1 CH0 RX Vref:28.5%, TX Vref:19.8%,20.8% CH1 RX Vref:29.3%, TX Vref:20.8%,20.8% CH2 RX Vref:28.5%, TX Vref:21.8%,21.8% CH3 RX Vref:29.7%, TX Vref:22.8%,21.8% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL board init U-Boot SPL 2017.09 (Aug 31 2024 - 15:22:22) unknown raw ID 41 18 20 Trying to boot from MMC2 spl: partition error Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK ## Checking u-boot 0x00800000 ... sha256(642bfeda4e...) + OK ## Checking fdt-1 0x008d6c48 ... sha256(7b2c4c6dbe...) + OK ## Checking atf-2 0x000f0000 ... sha256(b2af21b504...) + OK ## Checking atf-3 0xff100000 ... sha256(70505bb764...) + OK Jumping to U-Boot(0x00800000) via ARM Trusted Firmware(0x00040000) Total: 266.68/489.129 ms --- +

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.

Hello @4A studio. The armbian-config tool may change large parts of the system configuration without a real "undo". I am not sure if I understand your situation correct: Board does not boot. You see UART output but no UART login prompt? Board is booting. But you don't see a live picture on your HDMI monitor?

Hey @armfan. UUID=63ee7593-e111-4547-ac2f-6bdb8519ce11 was read from /boot/extlinux/extlinux.conf which is correct for the edge/7.1.0rc3 image. However, something must be wrong with your SD card if u-boot can read UUID from extlinux.conf, but kernel does not find corresponding file system on the same boot media. This is the expected kernel startup : [ 0.000000] Booting Linux on hartid 0 [ 0.000000] Linux version 7.1.0-rc3-edge-spacemit (build@armbian) (riscv64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU l [ 0.000000] Machine model: OrangePi RV2 [ 0.000000] SBI specification v1.0 detected [ 0.000000] SBI implementation ID=0x1 Version=0x10003 [ 0.000000] SBI IPI extension detected [ 0.000000] SBI RFENCE extension detected [ 0.000000] earlycon: sbi0 at I/O port 0x0 (options '') [ 0.000000] printk: legacy bootconsole [sbi0] enabled Loading, please wait... Starting systemd-udevd version 257.13-1~deb13u1 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. HTH // Sven-Ola

@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.

I have the same issue than @1111Windows had back in March. That's because I chose the wrong option in armbian-config. How do I revert to original (or, at least, working) u-boot? UART connection through putty is working.

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.

@sven-olaTrying the latest RC2 and RC3 7.1 bundles at https://sven-ola.commando.de/privat-in/ by flashing it to a MicroSD card and booting from it, I get the following boot failure. Booting your 6.18 image works though. Any idea how make it work? By the way, is the U-Boot binary inside Armbian the same in your 7.1 and 6.18 versions? Perhaps I could boot the 6.18 from MicroSD card, use it to flash the SPI, and then try to boot the 7.1 from the SPI? Update: I booted the RV2 off MicroSD card via the old 6.18 version. From inside this 6.18, I did "dd if=the-7.1-version of=/dev/nvme0n1 bs=1M status=progress", powered off, took out the MicroSD, and booted, and it worked! Now a question back to you: @sven-ola Now that the boot process works, do I still need to install the latest Armbian-bundled u-boot on the SPI chip via "armbian-install"?

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.