Dear Armbian community, I'd like to share my experience with the latest Armbian Trixie running on Cubietruck with a full desktop environment. It wasn't a flawless experience this morning tbh. I was expecting a perfectly working image just like on a cubieboard2. Instead, whenever SDDM was to appear, the screen went blank. kmscube showed nothing and dmesg was full of lima ... gpmmu page fault at 0x... of type read, gp task error...

 

The same software works on a cubieboard2 (A20, 1 GiB), and the same cubietruck hardware runs the Mali just fine with the legacy 3.4 kernel (Armbian 559 if I remember correctly) and the Mali blob (glmark2_es2 is alive and rocking the GPU).

 

I don't know if it's a known bug and a patch lives elsewhere, I couldn't find anything but rumors, that HDMI out is not working on cubietrucks. Well, it is working now and since I've successfully tamed cubietruck to start it's Mali, I'd like to share my findings with the community.

 

I've tracked it down to the following culprit, hopefully my understanding of the principles is right, please feel free to correct me if I'm wrong. On A10/A20 the Mali-400 is an MBUS master (like the display engine, CSI and video engine). It sees DRAM at bus address 0x00000000, not at the CPU physical address 0x40000000. Mainline handles this for the other MBUS masters in drivers/soc/sunxi/sunxi_mbus.c (a DMA offset of PHYS_OFFSET is attached to the listed devices), but the Mali compatibles are missing from that list, so lima gives the GPU CPU physical addresses. That means:

- 1 GB boards: the DRAM controller decodes 30 address bits. 0x4xxxxxxx wraps around to the right place, so everything works by accident.
- 2 GB boards (Cubietruck): 31 bits are decoded. Every GPU access lands "just" 1 GiB away 😉 from the intended data. Page tables looked fine in memory, yet the GPU MMU faults. Command streams looked fine, yet the GPU reported invalid commands.

 

I've attached the fix which is currently running on my cubietruck. Two lines in drivers/soc/sunxi/sunxi_mbus.c: add "allwinner,sun4i-a10-mali" and "allwinner,sun7i-a20-mali" to sunxi_mbus_devices[], so the Mali gets the same MBUS DMA offset as the display engine, CSI and video engine. No lima, Mesa or device-tree change is needed.

 

 

The patched kernel has only been tested on my cubietruck so far (because my cubie2 runs on a stock Armbian just fine - the reason is obvious from the explanation above).

 

 

Disclaimer: my bug hunt and fix have been greatly supported by LLM tools (AI assistant Claude), no cubietrucks have been harmed during the sessions.

armbian-userpatch-0005-soc-sunxi-mbus-add-the-A10-A20-Mali-GPU.patch

Edited October 17Oct 17 by drracer

You have rediscovered a three year old patch: https://forum.armbian.com/topic/48105-curietruck-has-only-console-through-hdmi/#comment-208269

Sad to see no-one who knows how has added it to mainline yet.

OK, thanks for letting me know. Are you aware of any other existing patches for the cubietruck? Like the H264 HW codec, bluetooth, VGA, dual-monitor support 😉 ?

I have not fiddled with my cubietrucks for some time. VGA was working 10 years ago but I haven't tried it lately. Bluetooth required non-free firmware: https://github.com/phelum/CT_Bluetooth don't think I ever got it working though.

H264 decode certainly works, I used one as a media box for years. I seem to remember encode working but it was not worth using. Never tried dual monitors.

On 10/17/2026 at 2:26 PM, drracer said:

my bug hunt and fix have been greatly supported by LLM tools (AI assistant Claude), no cubietrucks have been harmed during the sessions.

 

Now ask your assistant to submit a PR at https://github.com/armbian/build/pulls

 

We're already overwhelmed with bug reports, fixes, PRs, and the ongoing work required to keep everything running. From my perspective, what's often missing is an understanding of just how much effort it takes to maintain reliable Linux support for such a wide range of inexpensive yet surprisingly complex hardware.

 

Suggestions and AI-generated solutions are welcome, but turning them into working, tested, and maintainable code is where the real work begins. Contributions are always appreciated!

Thank you for encouraging me to submit a PR (even-though AI-assisted), I really appreciate it. I'm fully aware that long term maintenance is much harder than just providing a working prototype. I now can test cubietruck/cubieboard2/cubieboard occasionally if needed (I now have spare HW to tame).

 

Since my first post on this forum, I now have a fully functional cubietruck running on the latest Armbian/Trixie including all its HW components. Of course it's not a single patch, but I'll do my best to open PRs and collaborate with reviewers so that others can benefit from it as well.

 

The good news is, most of the stuff already exists on upstream kernel, it's just a little broken on many places. My current state:

• LXQt on Xorg + OpenGL ES2 (Lima) - that worked out of the box once HDMI appeared, getting just 87 glmarks compared to 119 on kernel 3.4 (expected to be slower, no fbturbo driver on recent X, can be potentially solved by moving onto Wayland or running full-screen when Xorg is not getting in the way)
• HW mouse cursor through G2D
• Bluetooth, when it starts (now trying to find out where the inherent start-up unreliability is coming from, ideas welcome, it was on kernel 3.4 as well)
• Dual monitor output (HDMI+VGA) - actually u-boot picks VGA output correctly if no HDMI is attached
• HW H264 codec through unpatched ffmpeg and mpv (VDPAU) ... it's funny to watch a video split among the VGA and HDMI monitor (didn't try MPEG2 or VP9 yet).
• audio speakers (worked out of the box, didn't try SPDIF)
• SATA (worked out of the box)
• IR (worked out of the box)
• WiFi - didn't try connecting, but the chip seems to be alive

Some of it applies to cubieboard2 and probably also cubieboard (I haven't tested the A10 yet).