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

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

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: ./compile.sh BOARD=orangepirv2 BRANCH=current RELEASE=trixie KERNEL_CONFIGURE=no BUILD_MINIMAL=yes KERNEL_GIT=shallow Write output/images/*.img to SD and boot with that. Use armbian-install to copy boot cfg on MTD. Again copy that *.img to /dev/nvme0n1. 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

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

Thanks. Found a post from @igor basically stating the same. I'll continue to work on the RV2 here for that reason.

Grmbl. As it turns out after some reversing and building uboot for the RV2, there seems to be a toolchain by xunlong with much similarities to armbian-build on https://github.com/orangepi-xunlong/orangepi-build.git There is an Ubuntu image for the RV2 one can download from gdrive and install to SD. This image has a package linux-u-boot-orangepirv2-current.deb installed. With very much the same postinst script than the similar package from Armbian / Banana Pi F3. Hence the RV2 package obviously was build from their build tree, family file is external/config/sources/families/ky.conf which looks familiar. Also their project has some non-documentation, meaning there is a "build.sh" and a very small README.md. I'm unsure if I should continue this...

Need to post some corrections. The board loads and starts uboot directly from an inserted SD, so no need to be extra careful. Also: the upper M.2 is not recognized by stock uboot, so may next step is to compile u-boot to investigate.

As a follow up: got my board yesterday. 2GB RAM as announced, no obvious bringup probs. The Ubuntu image runs from SD, UART ok, got 80mb/s from SD and around ~300mb/s from an 128GB 2230 NVME. No boot from upper m.2, only lower m.2 boots (works as announced). The SBC starts via uboot stored on the 16mbyte SPI flash, so I think it should be possible to also boot from upper m.2 since the uboot recognizes media both m.2 slots. Currently unclear how to recover from damaged SPI flash, so I need to proceed carefully. Uboot env is closed (bootdelay=0), so first task is to open up uboot cmd line. Theres a boot switch that seems to trigger some USB boot from ROM but thats undocumented AFAICT. Plenty to investigate for my 50 bucks 😉

@Igor wrote about upcoming Muse Pi Pro (a SpacemiT K1 board). Orange Pi RV2 features a "Ky X1" SoC which may be a variant of the SpacemiT SoC and at least similar to the already compile-able Banana Pi F3 board. However, Xunlong seems to be serious about the differences, since the published patch sets on github.com/orangepi-xunlong to kernel and u-boot have a GPL-2 copyright notice, stating I expect my RV2 arriving tomorrow. Thus, it would be very appreciated if support for this board pops up in time 😉 Otherwise I may try my luck with adding Armbian support on my own (without expecting success soon). For clarification, I compiled a list of RISC-V64 boards currently available: Banana Pi F3, runs on SpacemiT K1 8-core X60 RISV-V@1.5? (2 TOPS NPU, 2x1 Gbit, M.2@m, mPCIe, eMMC@soldered, SD/TF) Orange Pi RV, runs on StarFive JH 7110 4-core RISC-V@1.5 (1x1 Gbit, M.2@m, SD/TF, SPI-flash) Orange Pi RV2, runs on Ky X1, 8-core RISC-V@1.5, variant of SpacemiT K1? (2 TOPS NPU, 2x1 Gbit, M.2@m2280, M.2@m2230, SD/TF, eMMC@socket, SPI-flash) Muse Pi Pro runs on overclocked SpacemiT K1 8-core X60 RISC-V@1.8 (2 TOPS NPU, 1x1 Gbit, M.2@m, mPCIe, eMMC@soldered, SPI-flash) Best // Sven-Ola