sven-ola

Hello @Malay. Never mind - I' am not a native English speaker too. I have not tested the GUI intensively because my Goal is using this little board as a mini-server. Also, I think it's best getting the basics up before turning to the high-level GUI and media stuff.
 
The "current" 6.6.99 kernel seems not to work with Wayland. You can switch to X11, change /etc/gdm3/custom.conf. The "edge" 6.18.7 is works with Wayland. Integrating GPU support is out of my focus currently, I am even unsure if this applies for Orange Pi RV2: https://sdk.spacemit.com/en/graphics/graphics_driver_framework/ ?
 
HW Video decoding is another rabbit hole. The documentation is Chinese at best 🤪
 
LG + HTH // Sven-Ola

Hello @Malay, et.al, after submitting my PullRQ to the Armbian repo, I think it's best to cope first with the annotations I received from that. It complains about missing board photos, and some LLM generated blurb partly valid suggestions, partly not.
 
The current status of Armbian's Spacemit support does not make the RV2 board a good video player: GPU support is missing and I'm pretty unsure if it's possible to include the HW video encoding / decoding feature that is in the chip. Which is 4k@30 with diverse codecs according to the chip description PDF. I am glad, that X11 framebuffer video runs and I am unsure if I can proceed here b/c I am not a video / GPU / EGL / vulkan specialist.
 
Anyhow, thank you for the pointer to the Spacemit FAQ I did not recognize until now. While the PowerVR page from mesa3d states: "no IMG BXE-2-32" (https://docs.mesa3d.org/drivers/powervr.html), the respective Gitee repo contains closed-source BSD licensed Risc64 compiled shard objects (*.so), probably similar to the Nvida binary user space closed drivers that does the GPU support for the big videos cards. This may be worth a look, but as I wrote above, prio task is to bring the support into the Armbian tree.
 
Best // Sven-Ola

🦀 Rust PiCalculator on Orange Pi RV2 (riscv64, Armbian Trixie)
Compiled and ran a high-precision Pi calculator in Rust on my Orange Pi RV2 (K1X, 8-core @ 1.6 GHz) running Armbian-unofficial Trixie riscv64. The goal: test rustc performance and validate big-integer workloads on RISC-V.
✅ Environment
OS: Armbian-unofficial 26.02.0-trunk (Debian Trixie)
Kernel: Linux 6.18.5-edge-spacemit
Rust: rustc 1.85.0, cargo 1.85.0 (built from source)
Display: EZCAP28X @ 1920×1080
Memory: 3.7 GiB RAM, 1.3 GiB used
Disk: ext4, 28.96 GiB total
GPU: Mesa llvmpipe (LLVM 19.1.7)
🧮 Project: PiCalculator
Rust implementation using rug (GMP-backed) to compute 1000 digits of π:
rust
use rug::{float::Constant, Float}; fn main() { let digits: usize = 1000; let bits: u32 = ((digits as f64) * 3.321928).ceil() as u32 + 10; let pi = Float::with_val(bits, Constant::Pi); let s = pi.to_string_radix(10, Some(digits)); println!("{s}"); }
🧩 Build Notes
Needed libgmp-dev and m4 to compile rug cleanly.
cargo build --release succeeded without patching.
Output verified against known π digits.
⚖️ Performance Comparison
Board CPU Time (ms) Real Time (ms) Pi 400 Faster (1.8 GHz, fewer cores) Lower latency RV2 (K1X) Slower per-core, but stable Good throughput
Despite having 8 cores, the RV2’s in-order K1X is slower than the Pi 400’s Cortex-A72 for single-threaded math. Still, the build was smooth and the output correct — a great stress test for rustc on riscv64.
 

I operate an Odroid HC4, that has 4 x A55@1.8 and the board discussed here has 8  x X60@1.?. A fast sysbench says: single thread on OpiRv2 is slower (792 vs 1034) , multithreaded is faster (6342 vs 4151). Compiling a current kernel on RV2 needs 3 hours, nothing one would do do regularly. If you really need speed buy a Radxa Rock 5 (see platinum support devices on this site).
 
Edit1: NPU -> Opi Wiki, USB and SPI yes, for MIPI DSI/CSI you need to test yourself.
Edit2: Just remembered that I have a H618 (Opiz3). Single=708, Multi=2828 with the same Trixie sysbench. 
 
HTH + LG // Sven-Ola

Hello @brunorro. That "current.txt" from above: the UART output shows you are booting an older KY-Uboot from NOR flash. Probably SD card not fully inserted.  "edge.txt" shows a correct SD card boot sequence.
 
Best // Sven-Ola

In the meantime I fiddled with HW crypto and PCIe sleep states. While the former is working on edge and current, the latter may be an individual error with my Samsung PM9b1 128Gb NVME SSD not working in the upper 2230 M.2 on edge.
 
While the current 6.6 kernel does not use ASPM eventually, the edge 6.18 kernel has it and it leads to read errors. Adding pcie_aspm=off to /boot/extlinux/extlinux.conf::append helped, but I think adding a "No ASPM" to pci-quirks for this device is a better solution b/c the PCIe wifi is working (has L1 and L0s sleep).
 
So if you like then test your NVME SSDs with the edge kernel. I'am especially interested in NVMEs reporting Capabilities L1 PM Substates with lspci -v
 
LG // Sven-Ola

Hello @brunorro. Yes, sometimes people are hacking badly. I have it working again after restarting with Armbian/Spacemit: u-boot starts, onboard BT and Wifi works, SD card is again reading with 80mb/s, transfer u-boot and SBI to MTD via armbian-install works (MTD boot is required for starting from SSD), both M.2 slots can boot from NVME. 
 
Sadly, the Broadcom SDIO wifi driver is a smoking mess. This driver needs heavy porting so its not available with linux-6.18 / edge currently.  Are you willing to test anyhow? I can provide a 6.6.99 Trixie image for download if you ACK. There are always things that I may have overlooked such as USB, HDMI. All those little things I have not tested, I' on UART currently.
 
LG // Sven-Ola

PCIe MSI is not working. At least with an Intel iwlwifi M.2 card. For that reason, I investigated the differences between the Xunlong KY tree and the Armbian Spacemit Tree. B/c loading the "official" 552kb esos.elf seems to work (even if the Ky version is only 104kb) on the OrangePi RV2, I started to backport Xunlong changes to Armbian/Spacemit family.
 
Newer kernel, but no luck with that MSI. There should be a DMA-transfer-complete interrupt at the end of the firmware upload. Card is working in my PC. MSI is working on OpiRV2 with NVME. Current status: board runs with spacemit-family kernel, but some minor Does-Not-Work yet: LED, onboard Wifi+BT and I need to check that special RTL eth...
 
LG // Sven-Ola
 
Edit: Pic it or it didn't happen. RV2 underside with WIfi card.

Hey! Got it up and running - I have an Armbian SD card image based on the source trees found on https://github.com/orangepi-xunlong. Since I am a newbie to Armbian, please accept my apologies for beginner errors. Here's what I currently got on my UART:
 
root@orangepirv2:~# uname -a Linux orangepirv2 6.6.63-current-ky #1 SMP PREEMPT Tue Mar 18 02:29:27 UTC 2025 riscv64 GNU/Linux root@orangepirv2:~# cat /etc/os-release PRETTY_NAME="Armbian-unofficial 26.02.0-trunk trixie" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.2 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-unofficial 26.02.0-trunk trixie"  
This is not ready for prime time now. Needs a bit cleanup b/c I pulled in binaries and private project stuff not meant for armbian-build. Currently resides in this fork https://github.com/sven-ola/armbian-build/tree/orangepi-rv2. If you want to give it a try: it's compile.sh opirv2 after checkout. I've also managed to boot from the top 2230 M.2 SSD but this is also handmade (I'm pretty sure there is a script in here that copies the SD card boot blobs to SPI flash, will try before doing the MR).
 
Best // Sven-Ola