Star64: GPU firmware loading on Armbian

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