sven-ola Posted February 9 Author Posted February 9 (edited) Continued GPU hacks. I uploaded a medley from Armbian (uboot,kernel) plus OrangePi-Ubuntu-Noble (userspace) from downloaded Xunlong image to my https://privat-in.de site (-> Downloads, grab Armbian+OrangePi.img.xz). Root PW is "orangepi" and it has 3 scripts /boot/boot-6.x.x to switch kernels between 6.6.36-ky, 6.6.99 and 6.18.x (both from Armbian). While the original "ky" kernel has GPU support (instantly visible with the Gnome GUI reacting < 2 seconds), the Armbian kernels have no GPU. Turns out: the kernel DRM driver name needs to be "rvdisplay" instead of "spacemit". This works at least with Armbian-Stable-6.6.99, while Armbian-Edge-6.18.x probably needs further kicking. The Armbian kernels have the following (prelim) change: --- a/drivers/gpu/drm/spacemit/spacemit_drm.c +++ b/drivers/gpu/drm/spacemit/spacemit_drm.c @@ -24,7 +24,7 @@ #include "spacemit_dmmu.h" #include "spacemit_gem.h" -#define DRIVER_NAME "spacemit" +#define DRIVER_NAME "rvdisplay" #define DRIVER_DESC "Spacemit SoCs' DRM Driver" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 Note, that Xorg has no GPU, the GPU stuff only works with Wayland (gnome-shell + mutter). Also: no luck with that Bianbu-Linux. It's damn slow Gnome (slower that OrangePi with Software rendering) and none of the kernels brings the GPU to live (even the original Bianbu kernel with a orangepirv2 DTB does not work). @c0rnelius Bananapi R3 and Musepi Pro have working GPU? HTH // Sven-Ola Edited February 9 by sven-ola 0 Quote
maxsub Posted February 9 Posted February 9 In your downloads site, does this one have the GPU hack? Armbian-unofficial_26.02.0-trunk_Orangepirv2_trixie_current_6.6.99_minimal.img. I can do some testing. Thank you. 0 Quote
sven-ola Posted February 10 Author Posted February 10 Hi @maxsub, no, thats a normal image. Hacking is the looong filename: Armbian-unofficial_26.02.0-trunk_Orangepirv2_trixie_edge_6.18.8_minimal+Orangepirv2_1.0.0_ubuntu_noble_desktop_gnome_linux6.6.63.img.xz 0 Quote
c0rnelius Posted February 10 Posted February 10 3 hours ago, sven-ola said: Bananapi F3 and Musepi Pro have working GPU? When I got the MusePi Pro it came pre flashed so I tested the install. I don't recall it having an amazing DE experience. Not sure about the GPU but like most SBC's I wouldn't expect great things in that department. Which makes me wonder about the MuseBook. 0 Quote
sven-ola Posted February 10 Author Posted February 10 @c0rnelius then the GPU probably works, since without GPU e.g the Bianbu first time wizard (language, kbd, timezone, user) needs 20 minutes while uptime reports load=10. I'm damn sure you have noticed an extraslow GUI 0 Quote
sven-ola Posted February 10 Author Posted February 10 (edited) That "rvdisplay" string is found in the following files: libVK_IMG.so, libsutu_display.so, and libpvr_dri_support.so. When comparing the OpiRV2 versions of these files with https://gitee.com/spacemit-buildroot/img-gpu-powervr I got 9a640=spacemit vs 9a2d0=rvdisplay. Thus, Xunlong has source code for these (different offsets, rvdisplay is one char longer). So no need to hack Armbian kernel, I presume GPU works if we use *.so from gitee repo. HTH // Sven-Ola Edited February 10 by sven-ola 0 Quote
maxsub Posted February 10 Posted February 10 So this is built fully from source by patching the xunlong source onto the edge code base? Armbian-unofficial_26.02.0-trunk_Orangepirv2_trixie_edge_6.18.8_minimal+Orangepirv2_1.0.0_ubuntu_noble_desktop_gnome_linux6.6.63.img.xz 0 Quote
sven-ola Posted February 10 Author Posted February 10 @maxsub no, its hacked. At least from my side. For us, that GPU stuff is closed, patented, tighly licensed and so on. LG // Sven-Ola 0 Quote
cal5582 Posted February 12 Posted February 12 not sure if this is the right place to ask, but i was able to get it to recompile the kernel with the xe driver flag turned on, and got a working booting 6.18.9 image, which is amazing, i have never been able to get anything newer than the 6.6 kernel the manufacturer provided working. so thank you so much for all your hard work. theres only one problem, when i do the lspci command, i dont see anything attached to that slot. i tried two different intel arc gpus, an arc 350 and an arc 310 neither detects. so i pulled out an ibm fpga card and plugged it into the same powered oculink adapter, and lo and behold the fpga card detected, so my pcie adapter setup is good. is there any advice you could offer besides enabling the xe2 driver in kernel that i may have to persue? i know this is kind of off topic, id just like to get hardware accelerated graphics working on this device. 0 Quote
maxsub Posted February 12 Posted February 12 You mean the M.2 PCIe slot? My RV2 board has no oculink slot, only 2 PCIe slots, one for NVMe and one for SSD. 0 Quote
cal5582 Posted February 12 Posted February 12 (edited) nvme drive is in the bottom slot, oculink adapter going to a powered external pci-e adapter in the top nvme slot. i was able to plug a non-gpu in it and get a device to detect. just both my intel arc gpus failed to detect. edit, new discovery, when the fpga device is active on the 2nd nvme slot i can no longer see my original nvme drive if booting off the sd card. very strange. almost like its a lane bifrucation issue. ignore that, misconfig on my end. Edited February 12 by cal5582 0 Quote
brunorro Posted February 12 Posted February 12 Thank you, @sven-ola , your work is amazing About the GPU, I suppose that spacemit can do something like what this guy did to make work the BXM-4-64 on the TH1520 https://mwilczynski.dev/posts/riscv-gpu-zink/ Anyways, my hardware knowledge is way far away from this... 0 Quote
sven-ola Posted February 12 Author Posted February 12 @cal5582 Hav you plugged in your Oculink/Intel Arc combination to a standard PC's M.2 slot? Just to make sure, it's not the power supply for our power hungry graphical friends. If it is not the power supply (5V, 12V) then there is one difference from PC to OpiRV2: the OpiRV2's M.2 slot has only 2 PCIe lanes connected, while a standard PC has M.2/M-key connectors with 4 lanes normally. A graphics card may be used to a high number of lanes, so not only hungry for power but also for lanes. Also: there seems to exist Oculink adapters with an optical link between PC/board and card. In that case, I would expect an extra PCIe bridge to be shown with lspci. 0 Quote
sven-ola Posted February 12 Author Posted February 12 (edited) @brunorro What a read! That's cool stuff - hopefully those guys'n'gals visit the next station on their journey soon: from TH1520, via JH7110, then (hopefully) X1. At least that mailbox communication sounds similar with the SpacemiT SoC: power management via extra rCPU is also a thing here. Thank you for the link // Sven-Ola Edited February 12 by sven-ola 1 Quote
sven-ola Posted 1 hour ago Author Posted 1 hour ago Good news: this is merged in Armbian main now, many thanks to @c0rnelius and @Igor for reviewing this. So no more need to grab my fork, just clone Armbian/build:main. I was able to build and quick-test orangepirv2/edge-kernel and this looks fine including Wifi. There are of course unsolved quirks currently. With edge-kernel, Wayland does not work, we need to use Xorg. And with the current bcmdhd Wifi driver, AP mode is not possible. This is caused by outdated file in armbian-firmware for bcmdhd and may be the same on OrangePi5. There is a mechanism to load a different fw_bcm43456c5_ag.bin (the one downloadable from github/xunlong seems to work). LG // Sven-Ola 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.