January 17, 2021, 08:50:56 pm


Have you visited the Allwinner Chipset wiki? - http://linux-sunxi.org/

Which Linux for Cubietruck (Cubieboard 3)?

Started by moon, November 04, 2018, 11:28:45 am

Previous topic - Next topic


I have Cubietruck with VGA monitor (not HDMI) and don't know which Linux to install that will have the Mali GPU working.  I tried a few and they didn't boot or didn't have the mali driver.
OpenSUSE: didn't boot, hangs when starting the kernel
Armbian Bionic: boots but doesn't have mali driver, just software framebuffer
Devuan Ascii: boots but VGA monitor shuts off! (can only use it over serial cable or ssh)
Devuan Jessie: boots after I replaced the supplied u-boot with newer one :) but only has software framebuffer (/dev/fb0, not /dev/dri/card0)
Any ideas what else to try?


what you are up against is the sunxi uboot work has not provided vga support.  none of the distros that use it can drive vga as a result.  and there is no plan to add it.

look for an hdmi-to-vga converter.

I have not been sucessful with these an Fedora/centos.


btw,  no mali drivers either for the most part.

gtk2 is ok, but gtk3 is a dog.

Fedra28 hdmi was decent.  Fedora29 is painful.

Cubietech needs to lend a hand in opening mali.


Thanks for the tips!  Oddly enough, yesterday I retraced my steps and found an Armbian desktop image I missed at the bottom of their Cubietruck download page (it was well hidden under all that peripherals stuff).  So I installed it because I had nothing to lose, and it actually worked!  Well at least after I changed the screen resolution to 1024x768 with armbian-config, because the default 1920x1080p60 mode was too much for my monitor.  Their tool has Fexedit and Display settings, so I changed both to 1024x768 and set VGA output in the FEX part.  And after rebooting, the screen was working fine.
Now of course this is an old release, Armbian Xenial with legacy kernel 3.4.113, so it's not ideal but it does work and they still have it listed as supported, so I'm going to try and make this work, because I've formatted my SD card enough times now. :)
The only problem I noticed is the GL stuff doesn't seem to be working.  I tried a game to test and see, but got these errors:
moon@cubietruck:~$ supertux2
MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: mali_drm_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: mali_drm
But the kernel drivers are actually loaded:
moon@cubietruck:~$ lsmod|grep mali
mali_drm                2611  1
drm                   214870  2 mali_drm
mali                  112186  0
ump                    61770  4 mali,disp_ump
And this userspace library is also installed:
ii  libmali-sunxi-r3p0:arm 1.0-1~armbian5.3 armhf            Mali userspace binary driver version r3p0
So I think that leaves only the Xorg driver as the possible problem?  In /var/log/Xorg.0.log there are these entries:
[    21.655] (II) FBTURBO(0): [DRI2]   DRI driver: lima
[    21.655] (II) FBTURBO(0): [DRI2]   VDPAU driver: sunxi
[    21.655] (II) FBTURBO(0): using DRI2 integration for Mali GPU (UMP buffers)
[    21.655] (II) FBTURBO(0): Mali binary drivers can only accelerate EGL/GLES
[    21.656] (II) FBTURBO(0): so AIGLX/GLX is expected to fail or fallback to software
[    21.656] (==) RandR enabled
[    21.772] (II) SELinux: Disabled on system
[    21.787] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/lima_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/lima_dri.so: cannot open shared object file: No such file or directory)
[    21.787] (EE) AIGLX: reverting to software rendering
And sure enough, there's nothing that resembles mali or lima in /usr/lib/arm-linux-gnueabihf/dri or /usr/lib/xorg/modules.  Well that's as far as I got for tonight anyway.


Found the solution here:

I added this line to my .profile
export LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf/glshim

moon@cubietruck:~$ supertux2
LIBGL: Initialising gl4es
LIBGL: v0.9.2 built on Jan 24 2018 21:07:09
LIBGL:loaded: libGLESv1_CM.so
LIBGL:loaded: libEGL.so

Now that supertux2 game runs fine, when  before it was ridiculously slow!  8)
So that means the OpenGL ES stuff is working, despite those errors in the Xorg logfile.  Not all software uses GLES, but for those that do it sure makes a big difference!  Apparently you can compile RetroArch to use it, so that will be something fun to try.