Orangepi RV2 Board with Spacemit-Famliy both Current and Edge

[sven-ola]

Description

This PR supports a new board: Xunlong Orange Pi RV2. I already applied for maintainership for this board, but currently the board configs are *.wip. Note, that the smaller sibling, the Orange Pi R2V is also supported, but I do not own the HW, thus it's unsupported probably.

Documentation summary for feature / change

You can read about this PR in the Armbian forum, see the respective thread under https://forum.armbian.com/topic/56846-orange-pi-rv2/ I also generated and uploaded testing images built with this on my private project website (see https://privat-in.de/ goto downloads): current-trixie-minimal, edge-trixie-minimal, and edge-trixie-desktop-mate.

Here is a list of features (valid both for 6.6/current and for 6.18/edge if not noted otherwise)

• Boots from SD, eMMC, and indirect via MTD from upper M2 (2230) and lower M2 (2280). Note, that the original Xunlong SW does not boot from upper 2230.
• Boot files can be installed via armbian-install (write to MTD / write to eMMC).
• Most hardware runs. That includes UARTs, both Eth, HDMI, HDMI-audio, internal audio, internal Wifi / BT, USB2, USB3, both M.2 slots.
• There are a number of device tree overlays for the pin socket. Can be activated via extlinux.conf (fdtoverlays option).
• There are changes for other Spacemit board (namely BPI F3, MusePiPro), those are marked in the commit comment with "Spacemit:" or "General". No critical changes AFAICT.

How Has This Been Tested?

This was tested with the images one can download. I have a number of people that tried my images and provided feedback (see Forum thread linked above).

Notes

• There was a discussion with the upsteam kernel maintainer on a removed kernel thread for the rCPU in the context of a non-working HDMI audio. See jmontleon/linux-spacemit@d6a6ebe
• From this discussion: we can strip debug info the esos.elf FW file that is in the Armbian tree. With this, the kernel module tranferring the FW can save 400k of memory. This is not include in the PR
• From my wishlist: Mediatek Wifi drivers and Device-Mapper drivers are a thing. Should be activated all as module for this and other boards.
• Internal Wifi/BT driver (Spacemit adapted bcmdhd) was included in the 6.6/current kernel tree. This driver is not included with the 6.18/edge kernel tree, therefore I added this as an DKMS/external driver. I tried to activate EXTRAWIFI=yes, but this conflicts with patches for the other Spacemit boards.
• Also, the OPI R2S (smaller sister board) is supported. For this I added the r8125 driver via ./patch/kernel/archive/spacemit-* in two steps: 1 patch with the driver subdir (should apply to future kernel trees as well) and 1 patch for Makefile/Kconfig. Hope it's OK this way.
• There are a number for HW features not supported. The GPU is unsupported (and likely with stay so). See PowerVR on Mesa, the https://docs.mesa3d.org/drivers/powervr.html lists Imagination BXE-2-32 on the table-of-unsupported. Also no HW video decoding, probably Mipi/DSI and Mipi/CSI will not work. This extra Realtime-CPU needs investigation, there's an unsupported extra rUART maybe for a prompt or so...

Summary by CodeRabbit

• New Features

  • Support for Orange Pi R2S and RV2: device trees, board init, Wi‑Fi/Bluetooth wiring, a Bluetooth service, and platform MTD flashing for firmware/U‑Boot.
  • New brcm_patchram_plus utility for Broadcom Bluetooth patchram programming.

• Improvements

  • Added Realtek 2.5GbE, CAN/FlexCAN, IR/remote, ES8323 audio and USB CEC support; expanded SPI‑NOR mapping to 16MB; new DT overlays; riscv64 added to MATE environment.
  • Enhanced Broadcom wireless packaging/installer.

• Bug Fixes

  • HDMI audio dummy‑codec dependency and RV2 headphone GPIO handling corrected.

[github-actions]

✅ This PR has been reviewed and approved — all set for merge!

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@patch/u-boot/legacy/u-boot-spacemit-k1/006-orangepi-rv2-spi-flash.patch`:
- Line 4: Update the patch subject to match the chip name used in the code:
change "XM25QH128C" to "XM25QU128C" so the subject aligns with the added device
string "XM25QU128C" and the JEDEC ID 0x204118 present in the patch; ensure the
commit title accurately reflects the 1.8V "QU" variant to avoid confusion.

[sven-ola]

I think I've completed all tasks. Thus this PR waits for a team member to press the [merge] button probably. LG // Sven-Ola

[pyavitz]

patch/kernel/archive/spacemit-6.18/016-Revert-k1x_rproc-avoid-creating-busy-looping-mailbox.patch
patch/kernel/archive/spacemit-6.18/017-Spacemit-lower-kthread-loop-speed-to-1-sec.patch
patch/kernel/archive/spacemit-6.18/018-Spacemit-prevent-uninitialized-thread-shutdown.patch

This series of patches produces an incredibly high load average.
Uptime: 15:32:43 up 3 min, 1 user, load average: 2.46, 1.44, 0.61
Uptime: 15:40:05 up 11 min, 1 user, load average: 2.02, 1.93, 1.18

EDIT:
After removing the series of patches
Uptime: 15:51:12 up 4 min, 1 user, load average: 0.04, 0.23, 0.14

I recommend they be removed before merging the PR.

[sven-ola]

EDIT: After removing the series of patches Uptime: 15:51:12 up 4 min, 1 user, load average: 0.04, 0.23, 0.14

I recommend they be removed before merging the PR.

Hello @pyavitz, without this revert the communication to the rCPU does not work. And in turn e.g. HDMI audio DMA is non-functional. Thus I presume the SpacemiT engineers have a reason to put this in.

With the remoteproc thread active we see a system load of exactly 2.00 on idle (e.g. with uptime), but the RISCV main CPU compiles stuff with the same speed, has similar benchmark results, and does not show a higher temperature.

The 2.00 load is there e.g. on current 6.6.99 kernels. I checked the kthread, but that waits for the interrupt from rCPU as designed. For these reasons the revert should stay. I can add #ifdef orangepi to switch this off for the other RISC V board if required.

I discussed this with upstream (see jmontleon/linux-spacemit@d6a6ebe#commitcomment-175479327) but have not found a way to prevent the load display (besides patching /proc/uptime).

[sven-ola]

Hello @pyavitz, without this revert

We have forum user @maxsub who tested OpiR2S (the sister board without HDMI, M.2). He reports a higher temp (and the above R2S board foto suggests that this is an older problem). Please refer to https://forum.armbian.com/topic/56846-orange-pi-rv2/page/2/#findComment-232696 Maybe we really need to revert the revert...

#9299 (comment)

[pyavitz]

EDIT: After removing the series of patches Uptime: 15:51:12 up 4 min, 1 user, load average: 0.04, 0.23, 0.14
I recommend they be removed before merging the PR.

Hello @pyavitz, without this revert the communication to the rCPU does not work. And in turn e.g. HDMI audio DMA is non-functional. Thus I presume the SpacemiT engineers have a reason to put this in.

With the remoteproc thread active we see a system load of exactly 2.00 on idle (e.g. with uptime), but the RISCV main CPU compiles stuff with the same speed, has similar benchmark results, and does not show a higher temperature.

The 2.00 load is there e.g. on current 6.6.99 kernels. I checked the kthread, but that waits for the interrupt from rCPU as designed. For these reasons the revert should stay. I can add #ifdef orangepi to switch this off for the other RISC V board if required.

I discussed this with upstream (see jmontleon/linux-spacemit@d6a6ebe#commitcomment-175479327) but have not found a way to prevent the load display (besides patching /proc/uptime).

Just putting this out there.

At some point in the near future I will be introducing mainline, which will reside on the edge BRANCH. 6.18.y will become current and 6.6.y legacy.

At least that was my plan.

Of course how the branches get moved around and what stays and goes is up for debate.

[pyavitz]

This may or may not be of interest.
https://gitee.com/spacemit-buildroot/linux-6.6/issues/IAQOKP?from=project-issue
https://strl.cat/posts/2025/08/2025-08-07-qzowm

@sven-ola
Adjusting patch 017 and adding the following appears to normalize the load avg. I'm not sure if it breaks anything on your end though.

017-Spacemit-lower-kthread-loop-speed-to-1-sec.patch
019-Add-a-wait_for_completion_idle_timeout-to-normalize-.patch

Uptime:      07:51:56 up 15 min, 1 user, load average: 0.16, 0.06, 0.08

[sven-ola]

Adjusting patch 017

@pyavitz Thanks for the gitee link, I'll try your changes.

[sven-ola]

@pyavitz Great! I now have HDMI audio and standard idle system load=0.00. I have pushed your changes here.

We still may have a similar problem on R2S: high load, CPU gets hot. Let's wait for some feedback from forum user @maxsub on https://forum.armbian.com/topic/56846-orange-pi-rv2/page/2/