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

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.

@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

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: HTH // 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). LG // 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 you should get on the board Can you please elaborate on the "got it"? TIA // 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

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

As a followup: we have some help from @c0rnelius who digged out a solution to that kthread=high load issue (see latest commit / patches in my branch on https://github.com/sven-ola/armbian-build/tree/orangepi-rv2). Maybe this helps for the R2S too?

Hi @maxsub we see a high load (== 2.00 on idle) on RV2 and probably other SpacemiT devices. Both on 6.6.99 and 6.18.8 kernels. Caused by an active kthread() that is needed for the communication to the rCPU. Note: rCPU means the extra realtime RISCV-CPU that is powered by the realtime OS we load on boot with CONFIG_EXTRA_FIRMWARE="esos.elf". On the RV2 the high load display has no temperature side effects, but maybe this is not true for R2S. We have a photo of the R2S on the PullRQ (see https://github.com/armbian/build/pull/9299#issuecomment-3811665824 ) so the large cooling cap obviously is necessary? Can you retry with a 6.18.8 kernel with disabled kthread on the R2S? Just rename the last 3 patches in build/patch/kernel/archive/spacemit-6.18 from {016,017,018}*.patch to *.disabled and rebuild. TIA // Sven-Ola

I think I've completed all tasks. Thus the OpiRV2 PR now waits for a team member to press the [merge] button probably. @maxsub I compiled 6.6.99 kernel on my board with 2Gb RAM once. Needed 3 hours and a decent swap file. HTH // Sven-Ola

@maxsub: if you still have compile probs, I just uploaded new images to my site on https://privat-in.de (navigate to downloads). LG // Sven-Ola

@maxsub: Out-of-RAM may be possible if it simply spits out "killed". My machine has 32 Gb RAM and 16 Gb swap, does not encountered the OOM-killer lately. Until now, but exhausting RAM is probably kernel-dev-hobby 😗

Next idea: run ./compile.sh kernel-config and switch off DEBUG_INFO_BTF. But this should not happen. Also (probably) this BTF stuff now pops up here and there anyhow...

The try ./compile.sh docker-shell to start the Armbian compile environment. In the VM, check the pahole package version. If it's missing, you probably need to re-create by removing all from docker images|grep armbian which should be re-created on the next round. <whisper><small><hidden>And if nothing helps, docker system prune --force --all?</hidden></small></whisper> HTH // Sven-Ola

Hello @maxsub Compiling without Docker? You probably need apt-get install pahole, since ./compile.sh docker-shell shows: From the relevant kernel Kconfig: HTH // Sven-Ola

Hello @maxsub! Thank you for testing this. Especially on the R2S, since I do not have this device at hand. I am in the final spurt to get this merged into Armbian, but there are one or two rabbits to be hunted down (aka coding quirks). You compiled BRANCH=current and kernel=6.6.99. Can you repeat and recompile with BRANCH=edge, which is the same u-boot but should give you kernel 6.18.7? LG // 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

I uploaded fresh images, that includes a trixie-edge-desktop-mate image I tested with my Hardware. Mate looks good and working, but switching between internal / HDMI audio needs some fiddling with the audio setting widget (may be a misunderstanding between pulseaudio and drivers). Changeing Sound-Pref:HW:profiles seems to do the trick. There is no chromium for RISCV, thus you need to install firefox-esr or netsurf-gtk manually. I think this is ready for primetime now, so I clicked on the "Pull-Request" button (see https://github.com/armbian/build/pull/9299). Got lots of auto email from the Github robots, will check tomorrow. LG // Sven-Ola

In the meantime, I fixed internal audio for "edge" (was: missing headphone GPIO). And also investigated around the esos.elf RTOS firmware. There's a license for that, which I added to my tree. The license basically says: use but do not infect with GPL: https://gitee.com/spacemit-buildroot/buildroot-ext/blob/k1-bl-v2.2.y/board/spacemit/k1/target_overlay/lib/firmware/LICENSE.spacemit_esos. Continuing on kthread issue. LG // Sven-Ola

Hello @JamesCL! I got the same error. You need to select at least one desktop package - error shows up with empty DESKTOP_APPGROUPS_SELECTED= Hello @Malay: That was on my todo list. I grabbed an eMMC from an old Odroid. It tried to boot if inserted. Thus boot sequence is: SD/TF, then eMMC, then MTD. So I booted with SD. eMMC showed up in /dev/mmcblk2. I started armbian-install, selected "Install on eMMC". Now it tries to boot that old Odroid image. So boot0, uboot, and SBI are there. Should work if you copy an image to /dev/mmcblk2. @All others: if that kernel thread for realtime-CPU (and HDMI audio) is active, the board always reports a load=2.0 or higher. This does not cause a very un-responsive Wayland-Gnome3-Desktop, this has other causes. Anyhow, this desires more investigation, since running a polling process to grab data from a realtime CPU does not sound right, there has to be an Interrupt or so, so I may again revert the reverted reversion (of the RPMSG kthread). Also I learned, that the Fedora project has an even larger esos.elf (rCPU firmware). I am curious what additional stuff may be in there 🤔 LG // Sven-Ola

Already got answer from upstream programmer❣️ That kernel thread in RPMSG was removed due to excessive CPU usage. I got the impression that this is true: edge:desktop is nearly un-usable. Also they say: there is kernel 6.19 from upstream/upstream in the make. For now, I'm reverting HDMI audio (and all other rCPU funcs) for edge. LG // Sven-Ola

Hello @JamesCL! The current image from https://privat-in.de/ should work. I will upload new images any minute now. However: if you only need Ethernet, Orange Pi R2S [1] is a better choice probably, b/c you got extra 2 times 2.5 gbit with that... Best // Sven-Ola [1] http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-R2S.html

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