Star64: GPU firmware loading on Armbian

[Der Geist der Maschine]

GPU firmware loading fails on armbian:

Code:

[    0.698528] PVR_K:(Fatal):    1: All RGX Firmware image loads failed for 'rgx.fw.36.50.54.182' (PVRSRV_ERROR_NOT_FOUND) [1599]
[    0.698565] PVR_K:(Error):    1: RGXInit: InitFirmware failed (275) [1556]
[    0.698592] PVR_K:(Error):    1: RGXInit() failed (PVRSRV_ERROR_NOT_FOUND) in PVRSRVCommonDeviceInitialise() [2156]
[    0.698626] PVR_K:(Error):    1: PVRSRVDeviceFinalise() failed (PVRSRV_ERROR_NOT_INITIALISED) in PVRSRVCommonDeviceInitialise() [2170]
[    0.698664] [drm:pvr_drm_load] *ERROR* device (____ptrval____) initialisation failed (err=-19)

This is probably a first step in having GPU support in Xorg and Wayland.

Apply this kernel patch

Code:

schaecsn@pc:~/risc/linux# git diff drivers/gpu/drm/img/img-rogue/Kconfig
diff --git a/drivers/gpu/drm/img/img-rogue/Kconfig b/drivers/gpu/drm/img/img-rogue/Kconfig
index 5b793bb9da0e..6f84a2643e02 100644
--- a/drivers/gpu/drm/img/img-rogue/Kconfig
+++ b/drivers/gpu/drm/img/img-rogue/Kconfig
@@ -1,5 +1,5 @@
config DRM_IMG_ROGUE
-      bool "DRM support for PowerVR GPU"
+      tristate "DRM support for PowerVR GPU"
        select DRM_IMG
        default n
        help

Configure the gpu driver as a module

Code:

schaecsn@pc:~/riscv/linux$ scripts/config -m CONFIG_DRM_IMG_ROGUE

Rebuild the kernel and modules and install them.

The driver needs to be compiled as a kernel module. Unsophisticated guess: that moves out the initialization of the gpu from initrd into systemd-land. That is why the firmware does not need to be in initrd but can reside on the /-filesystem.

The two firmware blobs rgx.fw.36.50.54.182  rgx.sh.36.50.54.182 need to be moved into /lib/firmware/ directory. They come from starfive-'s github repro https://media.githubusercontent.com/medi...866.tar.gz

Code:

schaecsn@star64:~$ sudo mv img-gpu-powervr-bin-1.17.6210866/target/lib/firmware/* /lib/firmware/

A reboot shows successful firmware load

Code:

[  26.414834] PVR_K:  362: Read BVNC 36.50.54.182 from HW device registers
[  26.414879] PVR_K:  362: RGX Device registered BVNC 36.50.54.182 with 1 core in the system
[  26.422574] PVR_K:  362: RGX Firmware image 'rgx.fw.36.50.54.182' loaded
[  26.442903] PVR_K:  362: Shader binary image 'rgx.sh.36.50.54.182' loaded

Th next step in having GPU support in Xorg and Wayland is probably installing the libs, bin, and headers from said img-gpu-powervr-bin-1.17.6210866.tar.gz "[this] is a GPU library packages from Imagination and provide GPU firmware, libOpenCL, vulkan, gles2, gles3. This library is not open source, only provide with binary library." I have not tried that.

[Fishwaldo]

This is where you are going to have lots of "fun" - GPU support requires tons of patches to various userland apps, including mesa, wayland, apps etc to correctly use the GPU. The challenge is the patches starfive distribute are for older versions of userspace, namely mesa, that don't apply to current mainline (same issue for VPU as well). I tried to build GPU acceleration initially on debian, but ran in version dependency nightmares... newer apps wont compile against older mesa versions etc etc etc. I gave up and went with yocto as its not as "fussy" about version dependencies and is easier to overcome

Xorg is going to be very "challenging", and i've not started on it yet, as wayland is easier go get running with GPU.

[tantamount]

GPU firmware loading fails on armbian...

Apply this kernel patch

Code:

schaecsn@pc:~/risc/linux# git diff drivers/gpu/drm/img/img-rogue/Kconfig
diff --git a/drivers/gpu/drm/img/img-rogue/Kconfig b/drivers/gpu/drm/img/img-rogue/Kconfig
index 5b793bb9da0e..6f84a2643e02 100644
--- a/drivers/gpu/drm/img/img-rogue/Kconfig
+++ b/drivers/gpu/drm/img/img-rogue/Kconfig
@@ -1,5 +1,5 @@
config DRM_IMG_ROGUE
-      bool "DRM support for PowerVR GPU"
+      tristate "DRM support for PowerVR GPU"
        select DRM_IMG
        default n
        help

I wonder why there are multiple names for the same GPU. So far they are:
- IMG Rogue
- IMG RXE-4-32
- PowerVR, which makes sense because the driver has PVR everywhere.
- And now, RGX.

This is also the first I've heard that firmware blobs are needed. Isn't the TI team producing a fully open source driver?

Speaking of which, Andrew from TI pointed me to the latest source code here:
https://git.ti.com/cgit/graphics/ti-img-rogue-driver/
Branch = linuxws/kirkstone/k6.1/23.1.6404501

Here's what Xorg looks like now before adding any blobs:
https://www.youtube.com/watch?v=Le2g9Kx-pjI

I also tried running fbtest, to see whether the fbdev that's provided by the GPU is slow and/or buggy:
https://youtu.be/ZA3jXKk9j7U

Lastly, I don't know what compiler the TI team is building the driver with, but GCC 12 is giving errors and failing:
riscv64-unknown-linux-gnu-gcc: error: unrecognized argument in option '-mstack-protector-guard=sysreg'
riscv64-unknown-linux-gnu-gcc: note: valid arguments to '-mstack-protector-guard=' are: global tls
riscv64-unknown-linux-gnu-gcc: error: unrecognized command-line option '-mgeneral-regs-only'

BTW I asked Geert U, who wrote fbtest, what he thinks of the Xorg graphics problems and he thinks there's a quality of service problem between CPU and GPU.

UPDATE:

The firmware blobs made no difference. Xorg still has the slowness and strange drawing behavior.
There is also no mention of RGX anything from dmesg, at least on Armbian.
I do think that avoiding proprietary code is the best idea, if possible.

---

This is where you are going to have lots of "fun" - GPU support requires tons of patches to various userland apps, including mesa, wayland, apps etc to correctly use the GPU. The challenge is the patches starfive distribute are for older versions of userspace, namely mesa, that don't apply to current mainline (same issue for VPU as well). I tried to build GPU acceleration initially on debian, but ran in version dependency nightmares... newer apps wont compile against older mesa versions etc etc etc. I gave up and went with yocto as its not as "fussy" about version dependencies and is easier to overcome

Xorg is going to be very "challenging", and i've not started on it yet, as wayland is easier go get running with GPU.

Would you be able to take a look at the latest TI code (link above) to see whether you can incorporate it?
I got compiler errors when trying, I think because my gcc is 12 and they need something earlier.
It's also not clear to me what subdirectory of "build" is appropriate for the JH7110.

I don't know a lot about Xwayland/weston.
I did compile it as a test, but I saw a strange bug where when I type a letter, it's repeated ~10 times.
UPDATE:
I just ran weston by itself, which let me create a terminal.
Here's the repeated characters bug:
https://youtu.be/X13Zr6rxA2Y

Because of these complications I was hoping to get an old xfree86 or something running that only uses /dev/fb0, because fbtest ran more or less fine.
So far no luck though.

[Fishwaldo]

That is only the kernel driver (in this case, the kernel is only really providing a communication channel between hardware and userspace) and doesn’t include the GPU firmware blob. Also, as I understand the TI platform uses a different model from Imagination than what the JH7110 uses. So their firmware blob would probably be different.

The “heavy” lifting for the GPU is done in userspace and that’s what isn’t fully open sourced, and what source is available is based on old versions of things like Mesa etc.

Imagination Tech (the GPU vendor) are currently writing new kernel and Vulcan drivers but they have not started work on the model in JH7110. You can view their work here: https://gitlab.freedesktop.org/users/fra...s/projects

When they add support for BXE-4-32 (that’s the model we have) then we can switch. AFAIK, there is no ETA on that yet. (Their mesa driver has been mainlined, but the new kernel driver has not yet. They attempted mainline the kernel driver last year but were asked to change their approach and I believe they are still refactoring. I’m guessing once they get it mainlined they will start on other GPU models.

---

By the way, basically anything that uses frame buffer is not accelerated the same way wayland/xorg are. Framebuffer is basically just a copy of the video pixels in ram. So you wouldn’t see any speed up over normal software rendering.

[tantamount]

When they add support for BXE-4-32 (that’s the model we have) then we can switch.

I see, Frank Binns is writing the PowerVR driver that supports Rogue and he works for Imagination Tech, which was acquired by some Chinese entities. I wonder then how TI is involved.

At this point I'd be happy with just the framebuffer, which is fast enough for me, and an X server that really uses it. It seems the Xorg server is doing something odd and trying to use DRM instead.

Comparing Xorg and fbtest and Wayland, it is mainly Xorg that has the strange drawing effects like you see in the video.
fbtest has the least problems I'd say and it is quite fast.

But Wayland in your pinix-based image also has the problem of cursor trails, as you can see here: https://youtube.com/shorts/zyxnfSB9yss?feature=share

I just found this: https://developer.imaginationtech.com/op...pu-driver/

[Fishwaldo]

TI just did the same things as Starfive - Drop the Kernel driver into github.

The trails is just a theme issue - turn off kvantum or use the breeze theme. not a GPU issue.

[tantamount]

TI just did the same things as Starfive - Drop the Kernel driver into github.

The trails is just a theme issue - turn off kvantum or use the breeze theme. not a GPU issue.

TI seems to be writing a proper GPU driver though. Looking at Binn's code his seems much simpler.

Armbian seems a better path forward than Pinix, because Armbian and Ubuntu might be updating packages.

Update:
I installed wayland and plasma on Armbian, but as-is without any acceleration it was extremely slow. I couldn't even log in. I've seen Apple ]['s with faster graphics.

Unrelated note:
The Waveshare board appears to have the same specs as the Star64, same GPU: https://www.waveshare.com/wiki/VisionFive2
But I tried two of their disk images and neither booted.

[Fishwaldo]

As mentioned, userland apps require patches to use GPU acceleration. No distro currently has those patches, so it’s all going to be using software rendering and thus slow.

The patches available are for old software versions. Some can be ported forward, but the most important patches are for a version of Mesa. It’s not very simple to forward port those patches as Mesa underwent a major restructuring of their source after the patches were released.

Until the GPU drivers are mainlined, we are stuck using certain versions of software. If your expecting Rasperry PI like desktop experience on riscv, your about a year or two to early

[tantamount]

Until the GPU drivers are mainlined, we are stuck using certain versions of software. If your expecting Rasperry PI like desktop experience on riscv, your about a year or two to early

The fact that direct framebuffer access programs run very fast but X Windows using fbdev is abnormally slow is not explained by anything you said.

[Fishwaldo]

Framebuffer apps work like:
Draw this pixel with this color at this location and send it directly to the display. For Window, or a entire display, you have to do that for every single pixel in your application. The GPU is not involved at all. For simple apps, with this can be fast, no doubt. When you want to start using graphical effects (like Bluring, or shadows or ???) then you have to do that all in your application (again, it would be using the CPU, not the GPU).

Xorg/Wayland Apps:
Draw a window of dimension X at position Y, with color Z and any Shadow/transparency/blur/graphical effect (they don't send individual pixels). Xorg/Wayland then takes that, and translates those "window" commands into graphical commands (openGL, GLESv2/v3) and sends to Mesa - Mesa translates the openGL/GLES data into instructions to send to the GPU, and the GPU actually draws the individual pixels directly to the display with the graphical effects. If mesa does not support your GPU (as is the case with mainline mesa and the Imagination GPU on Star64), then mesa does that all in software (called software rendering)

A better example would be moving a window:
Framebuffer Apps: Recalculate the pixel data for where the window was and where its going to, and send to the display. Some apps would be smart, and only do that for the pixels that are changed. Others will recalculate the entire display. It has to do that every time the window moves 1 pixel in any direction for the framerate of your monitor etc (so 60 times a second if you have a 60Hz monitor).

Xorg/Wayland: Move this window to this location - Xorg translates to OpenGL/GLESv2/v3 and sends to mesa, mesa sends the move command to the GPU and the GPU recalculates all the changed pixels and sends directly to the display. (not using the CPU at all).

How about transparency:
Framebuffer app: make a window 50% transparent - App has to look at the background image, and do the maths to make the forground image transparent and send the resultant pixel data to the display

Xorg/Wayland - make this window 50% -> xorg sends the window to mesa, mesa translates it to the GPU, and the GPU says "gotcha" and does the maths without using the CPU and sends the results to the display.

So why do we need mesa patches? - because every GPU has a different "instruction set" - think of arm versus x86 versus riscv. Mesa does the translation of OpenGL/GLES etc commands to the instruction set that the GPU understands.

and just in case your not sure - a framebuffer does not use the GPU at all. Its writing data directly to the display (HDMI or whatever port).

To finally address your statement that framebuffer is fast, but xwindows is slow - Yep. XWindows is doing a lot of work in CPU translating windows commands to pixel data instead of handing off to a supported GPU to do the actual drawing. And even a very minimal X windows desktop is using a lot of features a normal GPU would provide but has to do it all in software.

---

if you want a practical proof of the GPU "working" do this:
Load my desktop image (or kernel on armbian etc) and execute in a terminal window
"cat /sys/kernel/debug/pvr/status" and then do move some windows or play a video:
"Every 2.0s: cat /sys/kernel/debug/pvr/status                                                                                                                                                          star64: Fri Jun  9 04:49:23 2023

Driver Status:  OK

Device ID: 0:128
Firmware Status: OK
Server Errors:  0
HWR Event Count: 0
CRR Event Count: 0
SLR Event Count: 0
WGP Error Count: 0
TRP Error Count: 0
FWF Event Count: 0
APM Event Count: 243
GPU Utilisation: 93%
"

Now do the same with your Framebuffer app, and not that the GPU utilization does not go above 0%.