Orange Pi RV2

[maxsub]

Is this specific patch that reverts the busy looping thread?

https://github.com/armbian/build/commit/99ad08839eed42d647e716a3ed090ea318d01d2e

 

[sven-ola]

@maxsub yes and no. That 900*.patch never was meant to be in the Armbian repo, I wounder how this made it in the Armbian repo. Some black git magic...

 

Patch experimentally rolls back an upstream change (...that removes the kthread under discussion and by this prevents the main CPU from communicating to the remote CPU). Upstream (the Fedora folks that emitted the SpacemiT code drops) has removed the kthread to prevent high CPU load b/c they use RV2 for their RISCV compile farm or so. The 900*.patch was an experiment by me to understand the impact on HDMI audio / ADMA).

 

Long blabla. This proposed and committed change solves the issue for my pull RQ on the topic: https://github.com/armbian/build/pull/9299/changes/613737fab5aadc2d0a288a10a98aa0a433db4e76

[maxsub]

I patched that, am rebuilding and will post the R2S temps after that patch.

 

[maxsub]

The patch brought the idle load average drastically down on the R2S from 2.0 to 0.18.

However the temp remains at 57-58 deg C.

 

orangepi@orangepir2s:~$ cat /sys/class/thermal/thermal_zone1/temp 

56000

orangepi@orangepir2s:~$ htop

orangepi@orangepir2s:~$ cat /sys/class/thermal/thermal_zone1/temp 

57000

[c0rnelius]

14 minutes ago, maxsub said:

The patch brought the idle load average drastically down on the R2S from 2.0 to 0.18.

However the temp remains at 57-58 deg C.

 

That's not bad honestly. The K1 series runs hot in general. If you add heavy lifting to thee equation it would require a fan.

 

I have the MusePi Pro and BPI-F3 and both run hot.

[maxsub]

Thank you. Looking forward to all these contributions hitting the main branch so I can depend on the standard edge and current builds!

 

[sven-ola]

For me, those 57°C is fine without further cooling. Starting cool on my RV2 is:

 

root@orangepirv2:~# uptime;cat $(find /sys -name temp)
 18:55:15 up 0 min,  1 user,  load average: 0.90, 0.25, 0.08
27000
28000

 

Now some work, will probably max out at 95° or so

 

root@orangepirv2:~# uptime;cat $(find /sys -name temp)
 19:23:11 up 28 min,  3 users,  load average: 7.61, 6.79, 3.86
90000
90000

 

Stop compiling and wait a bit gives this which is fine IMO

 

root@orangepirv2:~# uptime;cat $(find /sys -name temp)
 19:35:07 up 40 min,  3 users,  load average: 0.00, 0.64, 1.81
56000
58000

 

[maxsub]

I have been testing the R2S extensively. The 1GbE is very stable, but the 2.5GbE drops frequently. I do not have debug logs yet but it is something I need to analyze.

 

I also have a wireless AP running on the R2S. Performance is poor: 1GbE WAN connection, but I am getting only 20Mbps throughput but it is stable.

[maxsub]

On RV2 with the edge branch WiFi does not work. 

[sven-ola]

Hu? In difference to Spacemit 6.6.99, the 6.18 kernel has no bcmdhd included. For that reason I put in an adapted version of bcmdhd in a DKMS, installed via a source deb from my repo on codeberg.org/sven-ola. B/c DKMS needs a compiler on the board, the edge image is larger than current image. Code quality of bcmdhd is questionable so it probably never make it into the official Linux tree, but it works (at least on my board with my image). HTH // Sven-Ola

[maxsub]

Got it! But this DKMS should be loaded by the build:
 

function post_family_tweaks_bsp__orangepirv2_wifi() {

        display_alert "$BOARD" "Force load bmcdhd wireless" "info"

        run_host_command_logged mkdir -pv "${destination}"/etc/modules-load.d

        run_host_command_logged echo "bcmdhd" > "${destination}"/etc/modules-load.d/${BOARD}.conf

}

 

[Malay]

7 часов назад, maxsub сказал:

On RV2 with the edge branch WiFi does not work. 

I confirm that when building an image with the Edge 6.18 kernel, WiFi does not work.

Also, when building an image with the Xfce desktop, the image is approximately 3 GB (it should be more than 4 GB), but it is not there, only the command line works.

Edited Saturday at 04:29 AM by Malay

[sven-ola]

Hello @maxsub, we are talking about git log --oneline -1 which says 613737fab. The post_family_tweaks_bsp__orangepirv2_wifi() from above is exactly what's in there. If you run

Zitat

./compile.sh CPUTHREADS=$(nproc) BOARD=orangepirv2 BRANCH=edge RELEASE=trixie KERNEL_CONFIGURE=no KERNEL_GIT=shallow BUILD_MINIMAL=yes SKIP_ARMBIAN_REPO=yes

you should get on the board

Zitat

root@orangepirv2:~# dkms status
bcmdhd-spacemit-sdio/101.10.591.84.37-4, 6.18.8-edge-spacemit, riscv64: installed

Can you please elaborate on the "got it"? TIA // Sven-Ola

[sven-ola]

Hello @Malay! Same for you: cannot reproduce. Can you rebuild with SKIP_ARMBIAN_REPO=yes? This builds a little longer but skips cached stuff. Alternatively, rm -r ./cache from the build dir. To help with this, I will start the following commands on my PC and upload the results later to https://privat-in.de/ (Download section).

Zitat

sudo rm -r cache/ output/ -f

./compile.sh CPUTHREADS=$(nproc) BOARD=orangepirv2 BRANCH=edge RELEASE=trixie KERNEL_CONFIGURE=no KERNEL_GIT=shallow BUILD_DESKTOP=yes DESKTOP_ENVIRONMENT=xfce DESKTOP_APPGROUPS_SELECTED="chat desktop_tools editors email internet multimedia office programming remote_desktop" DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base EXPERT=yes

LG // Sven-Ola

[sven-ola]

Compiled, flashed, uploaded. I got a running XFCE desktop and a working wifi applet. If you still have different results, I may provide a VPN endpoint and an SSH pubkey to log in to your machine. Here's my upload dir:

Zitat

1,2G    Armbian-unofficial_26.02.0-trunk_Orangepir2s_trixie_edge_6.18.8_minimal.img
1,3G    Armbian-unofficial_26.02.0-trunk_Orangepirv2_trixie_current_6.6.99_minimal.img
6,1G    Armbian-unofficial_26.02.0-trunk_Orangepirv2_trixie_edge_6.18.8_mate_desktop.img
1,9G    Armbian-unofficial_26.02.0-trunk_Orangepirv2_trixie_edge_6.18.8_minimal.img
5,8G    Armbian-unofficial_26.02.0-trunk_Orangepirv2_trixie_edge_6.18.9_xfce_desktop.img

HTH // Sven-Ola

[maxsub]

@sven-ola The dkms did not get installed by the build. I manually installed it and the wifi works.

I am trying the build with SKIP_ARMBIAN_REPO now as I did not have that before.

 

[maxsub]

The bcmdhd dkms is getting built and the debs are being updated if I use SKIP_ARMBIAN_REPO=yes.

 

[🐳|🔨]   Building for 6.18.9-edge-spacemit

[🐳|🔨]   

[🐳|🔨]   Building initial module bcmdhd-spacemit-sdio/101.10.591.84.37-4 for 6.18.9-edge-spacemit

[🐳|🔨]   The kernel is built without module signing facility, modules won't be signed

[🐳|🔨]   

[🐳|🔨]   Building module(s)............................... done.

[🐳|🔨]   Installing /lib/modules/6.18.9-edge-spacemit/updates/dkms/bcmdhd.ko.xz

[🐳|🔨]   Installing /lib/modules/6.18.9-edge-spacemit/updates/dkms/dhd_static_buf.ko.xz

[🐳|🔨]   Running depmod.... done.

[🐳|🔨]   Processing triggers for man-db (2.13.1-1) ...

When installing the image deb the previous dkms gets deleted.
 

Preparing to unpack linux-image-edge-spacemit_26.02.0-trunk_riscv64__6.18.9-S3aec-D0000-P87b2-C50afHfe35-HK01ba-Vc222-B052a-R448a.deb ...

Armbian 'linux-image-edge-spacemit' for '6.18.9-edge-spacemit': 'prerm' starting.

dkms: removing module bcmdhd-spacemit-sdio/101.10.591.84.37-4 for kernel 6.18.9-edge-spacemit (riscv64)

Module bcmdhd-spacemit-sdio/101.10.591.84.37-4 for kernel 6.18.9-edge-spacemit (riscv64):

Before uninstall, this module version was ACTIVE on this kernel.

Deleting /lib/modules/6.18.9-edge-spacemit/updates/dkms/bcmdhd.ko.xz

Deleting /lib/modules/6.18.9-edge-spacemit/updates/dkms/dhd_static_buf.ko.xz
.........
It gets built during install of the image deb:
 

Autoinstall of module bcmdhd-spacemit-sdio/101.10.591.84.37-4 for kernel 6.18.9-edge-spacemit (riscv64)

Building module(s)..............................................

Installing /lib/modules/6.18.9-edge-spacemit/updates/dkms/bcmdhd.ko.xz

Installing /lib/modules/6.18.9-edge-spacemit/updates/dkms/dhd_static_buf.ko.xz

Running depmod.....

[sven-ola]

@maxsub: I have not really analyzed Armbian build caching until now. Maybe a previous build for another spacemit board prevents the DKMS from being included? Anyhow, re-installing / updating a kernel image should trigger any active DKMS modules to rebuild for the new kernel on the board, so this looks correct. LG // Sven-Ola

Edited Saturday at 05:38 PM by sven-ola

[sven-ola]

Two addons: I compiled on another notebook and stumbled over a RAM error message from Armbian compile.sh. Notebook has 8GB, so I added the recommended KERNEL_BTF=no to the ./compile.sh args. A dkms status says, the bcmdhd is built and active.

Edited 20 hours ago by sven-ola
Abort GPU stuff, will not continue

[maxsub]

The second time I built it, the image deb worked and the bcmdhd dkms loaded.

 

> dkms status

bcmdhd-spacemit-sdio/101.10.591.84.37-4, 6.18.9-edge-spacemit, riscv64: installed

 

[Malay]

07.02.2026 в 21:57, sven-ola сказал:

Abort GPU stuff, will not continue

Hello @sven-ola ! It's sad. I had a small hope 🙂 But still, thank you very, very much for your work on the firmware!  After removing sudo rm -r cache/ output/ -f and adding the command SKIP_ARMBIAN_REPO=yes - WiFi now works

[sven-ola]

Hello @Malay, et.al, the motivation behind my attempt to include Armbian support for OpiRV2 is to have a better device for my Nextcloud-for-private-persons project. For this, I need a device that can be run at home with a current kernel and headless, but with decent storage. I already have a device (Orange Pi Zero 3, right on the photo), but Orange Pi RV2 (to the left) offers two(!) m.2 slots for NVMEs, some Wifi and Eth as well as decent computing power. Also, both have some extra NOR flash to store LUKS keys and decent pricing. Also that RiscV64 has some appeal, admitted 😉

 

Without GPU support, you can run Mate, LXDE, and XFCE for a GUI, which should be OK for some management tasks. I doubt that RV2 will ever make a good Youtube player, however that may be archived by replacing the Armbian userspace with that Ubuntu-Noble userspace that you can download from Xunlong. This Ubunut also comes with a RiscV64 port of Chromium which is also needed for Youtube and not avail from Debian, but source code *.dsc seems to be offered in the Bianbu pool so that may work out.

 

Anyhow - that GPU porting attempt was based on the PowerVR addons offered as code drop on git@gitee.com:spacemit-buildroot/mesa3d.git. Our Chinese friends grabbed mesa 22.3.5, added their IMG BXE-2-32 this+that to the sources, cherry-picked their way up to mesa 24.0.1 and throw the result over the fence. At least without inking the code via Windows notepad, so no white-space chaos this time.

 

Now, porting this with the closed binary *.so as heavy baggage is all about stable API. Large internal API change -> end of party. I am no graphics specialist, so take this with a pinch of salt. Debian offers mesa since 24.3 with an additional package: mesa-libgallium, you need this for the GPU desktops (Cinnamon, and probably Gnome / KDE). OK - someone or something needs the API from the Mesa internal Gallium driver suite, this needs to be compiled (a *.a is there). So I started to bring that code drop from 24.0 to 24.3, only to stumble over internal API changes. Concrete: we previously have some numeric constants __DRI_IMAGE_COMPONENTS_this+that 0xabcde in Mesa describing image formats (RGB32, BGRA24, 656-16, and so on). The code drop adds a couple of formats probably specific for PowerVR, but the Mesa project completely removed those constants ("nobody uses this"). At that point I thought: this is pointless, I'll pass...

 

HTH // Sven-Ola 

[Malay]

58 минут назад, sven-ola сказал:

Anyhow - that GPU porting

Thank you for such a detailed answer! I'll try to explain a little why I need this. I use OpiRV2 not only as a server for my applications (and, in a sense, for testing some add-ons for automating my home), but also to use OpiRV2 to install Kodi for viewing my home server tvheadend (as they say, to use 2 in 1 to the fullest). But this is impossible without hardware video decoding. I use Kodi without running the Mate and XFCE desktops - because from experience, to use hardware video decoding, you need to run Kodi with the /usr/bin/kodi-standalone --windowing=gbm parameter on single-board motherboards. This works fine on OpiZero3, etc., but here it's a pain in the ass 🙂 Even SD video is completely slow because software codecs are used. I understand that you don't need this and are not interested in it, so I'll just say - thank you for the great work you've done. PS: Regarding Ubuntu-Noble, which can be downloaded from Xunlong - which image are you talking about? If it's from here - http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-RV2.html , then it's terrible - nothing works there, including HDMI audio.