Orange Pi RV2

[sven-ola]

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

[sven-ola]

In the meantime, I spotted the pending MR from https://github.com/tmshlvck for this in the Pull Request Backlog. There are a number of issues with that, besides that it's very similar. Adding *.deb from xunlong without review is (mmm), better stay away from this. I'm not sure if the camera *.json is required. Not anything from the xunlong tree needs to be copied probably.

 

I cleaned out my version (see https://github.com/sven-ola/armbian-build/tree/orangepi-rv2), but while this is open since October, I postpone to trigger another MR on that issue.

 

My goal is: boot from upper 2230 SSD and use lower M.2 for Wifi (there are cheap Mediatek 3-band Wifi cards with 2280 adapter). If anyone wants similar setup, just checkout my branch from the link above and:

1. ./compile.sh BOARD=orangepirv2 BRANCH=current RELEASE=trixie KERNEL_CONFIGURE=no BUILD_MINIMAL=yes KERNEL_GIT=shallow
2. Write output/images/*.img to SD and boot with that.
3. Use armbian-install to copy boot cfg on MTD.
4. Again copy that *.img to /dev/nvme0n1.
5. Remove SD card, reboot board.

While investigating, there are a number of hints that the Ky X1 is in fact a SpacemiT K1 variant. Maybe stripped down, since the RCPU firmware (esos.elf) is much smaller. 

 

I have noticed, that Xunlong is not exactly welcome here. Chinese difficulties with the words upstream and donation probably. I think the hard work is to maintain / port the kernel and u-boot code drops with future versions. On the other hand: this board is cheap,  offers a way to practice with a new CPU arch, and has the expected minimum number of M.2 slots. 

 

 

I'm currently compiling a kernel on that board. ETA 3 hours or so, board is not very fast. Anyhow, temp stays below 80°C if operated upright (above foto). No unusual hotspots, board and RAM seems stable, wifi and ethernet works.

 

 

HTH and LG // Sven-Ola

[sven-ola]

Today investigated, why BCM Bluetooth was not working with my image. What a rabbit hole 🙄 Also added OrangePi R2S board. Smaller brother of RV2 (I have no board but it's probably working). 

 

For the Bluetooth: everyone is obviously happy to hack the BCM firmware file instead of implementing bcm init into hciattach. The brcm_patchram_plus firmware hacking tool was added for this arch and that arch as a binary under BSP for different boards. Not very Debian-style. I grabbed the working source, compared to the one avail in Android AOSP and added it to my branch, added lib6-dev-riscv64-cross to the Docker image and now have a working image with BT.

 

LG && HTH // Sven-Ola

[sven-ola]

As a followup: hardware crypto is damn slow on the Ky / SpacemIt platform, at least for default LUKS block encryption with AES. This probably also affects the Banana Pi F3 image.

 

With default sector-size of 512 byte, HW-AES is 5 times slower than SW-AES, while cryptsetup benchmark reports 5 times faster.

 

Main reason: block size. With sector-size of 4096 LUKS is reasonable fast. Also there is leftover debug (cannot be switched off) and a small bugs in the driver that triggers SW crypto fallback after HW crypto succeeds. Patches: https://github.com/sven-ola/armbian-build/tree/orangepi-rv2/patch/kernel/ky-current

 

Best // Sven-Ola 

Edited December 29, 2025 by sven-ola

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

Edited yesterday at 05:20 PM by sven-ola
+=IMG