Ubuntu Concept goes CIX P1

tobhe · May 14, 2026, 8:21pm

Following the strong reception of our Ubuntu concept image for Qualcomm platform, we’re excited to introduce you to the next step towards providing the community with Ubuntu access on cutting-edge hardware. In addition to our Qualcomm work, the team has created an Ubuntu concept image for CIX Technology P1. This new image is based on the latest 26.04 Ubuntu LTS release, and comes with all the great benefits of Resolute Racoon.

As with our earlier work, this concept image is intentionally positioned as a developer-focused preview. It’s built for those who want to get hands-on with emerging platform support, validate use cases, and contribute feedback, while accepting the trade-offs that come with a new platform. We’re hoping this helps us iterate faster by shortening the feedback loop, so we can test and improve new features faster than our usual Ubuntu release cycle.

The image comes with a Linux 7.0 kernel, based on the CIX open source release from github. In terms of drivers, we will stick entirely to open source options with an upstream-first approach.

Our goal is to rely entirely on Advanced Configuration and Power Interface (ACPI) for this platform, and avoid device trees where we can. As a result, we will carry a small set of patches on top of the mainline Linux tree, but the long term goal is to upstream all required changes.

Disclaimer:
The provided image and all included software is experimental and not suited for production use. The image comes without warranty or official support and is provided on a best effort basis.

Getting Started

Download the ISO from here.

Then follow the regular Ubuntu desktop installation process, which you can find in our documentation.

Platforms we tested with

MetaComputing AI PC Framework Laptop
Minisform MS-R1
Orange Pi 6 Plus
Radxa Orion O6
Radxa Orion O6N

Contributing

All packages installed in the concept image are available from our Ubuntu Concept - CIX PPA.
The source code for our packages can be found on Launchpad under the ~ubuntu-concept git repositories.

You can report bugs via launchpad – please include [CIX] in the bug title, and mention the affected hardware in your description.

Thanks

We would like to thank CIX Technologies for their technical support. We’d also like to thank Radxa, Minisforum, and Metacomputing for supplying us with test hardware.

Changelog

Show details

2026-05-19

sha1 6b1dd2f702b5408d05076f720df24cf5b1dd7187

Fixed an issue with the armchina-npu driver that made boot unstable on MS-R1

2026-05-17.1

sha1 1de9a482a4a478e0143459af877e5ee739797ecc

Added linlon_dp and trilin_dpsub to initrd for live ISO to fix black screen after grub

2026-05-17

sha1 4c7f65dcce50209aeb1418945166a7983b8fcff7

Added acpi=on to kernel command line to fix an issue on MS-R1

venn · May 15, 2026, 10:35pm

It’s really neat seeing a single *.iso image boot and install across all these different CIX boards. Fantastic work. I’ll be following the progress with my O6 and OP6.

aiwintermute · May 16, 2026, 3:58pm

First!

*with the picture of the system

ARM and racoons everywhere! Thanks for the hard work, I’m daily driving Snapdragon T14S with Ubuntu Concept and now going to try doing the same with Onion O6

heymeco · May 17, 2026, 7:45am

Since it has been validated on all systems can someone please also add which bios versions were used per system?

glathe · May 20, 2026, 8:15am

Yay, incentive to actually assemble my O6 mini-ITX build has strongly increased

zuccon · May 27, 2026, 1:03am

Anyone know if the image incorporates this fix to increase addressable VA bits to 48 here: https://gitlab.freedesktop.org/mesa/mesa/-/commit/c954aaa842f7a9936aee5dffeba689b743cfa2cc

I’ve been playing around with Llama+Vulkan and, if I constrain the batch-size, I can get it to execute a 0.5B Q4_KM:

./build/bin/llama-bench -m ../llm/qwen2.5-0.5b-instruct-q4_k_m.gguf \
  -r 1 -p 64 -n 16 -ngl 99 \
  -b 64 -ub 64
WARNING: panvk is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 1 Vulkan devices:
ggml_vulkan: 0 = Mali-G720 MC10 (panvk) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 16 | shared memory: 32768 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | ngl | n_batch | n_ubatch |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | ------: | -------: | --------------: | -------------------: |
| qwen2 1B Q4_K - Medium         | 462.96 MiB |   630.17 M | Vulkan     |  99 |      64 |       64 |            pp64 |         33.13 ± 0.00 |
| qwen2 1B Q4_K - Medium         | 462.96 MiB |   630.17 M | Vulkan     |  99 |      64 |       64 |            tg16 |          4.40 ± 0.00 |

build: b4c0549a4 (9352)

… but, if I don’t constrain this, I get an OOM error:

./build/bin/llama-bench -m ../llm/qwen2.5-0.5b-instruct-q4_k_m.gguf
WARNING: panvk is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 1 Vulkan devices:
ggml_vulkan: 0 = Mali-G720 MC10 (panvk) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 16 | shared memory: 32768 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | ngl |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | --------------: | -------------------: |
[New LWP 30820]
[New LWP 30819]

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.ubuntu.com>
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/aarch64-linux-gnu/libthread_db.so.1".
__syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/aarch64/syscall_cancel.S:50
⚠ warning: 50  ../sysdeps/unix/sysv/linux/aarch64/syscall_cancel.S: No such file or directory
#0  __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/aarch64/syscall_cancel.S:50
50      in ../sysdeps/unix/sysv/linux/aarch64/syscall_cancel.S
#1  0x0000ff4c34c48480 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=0, nr=nr@entry=260) at ./nptl/cancellation.c:49
⚠ warning: 49  ./nptl/cancellation.c: No such file or directory
#2  0x0000ff4c34c484d0 [PAC] in __syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=0, nr=nr@entry=260) at ./nptl/cancellation.c:75
75      in ./nptl/cancellation.c
#3  0x0000ff4c34ca28e4 [PAC] in __GI___wait4 (pid=<optimized out>, stat_loc=<optimized out>, options=<optimized out>, usage=<optimized out>) at ../sysdeps/unix/sysv/linux/wait4.c:30
⚠ warning: 30  ../sysdeps/unix/sysv/linux/wait4.c: No such file or directory
#4  0x0000ff4c34406398 [PAC] in ggml_print_backtrace () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libggml-base.so.0
#5  0x0000ff4c34418f0c in ggml_uncaught_exception() () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libggml-base.so.0
#6  0x0000ff4c34e81ab0 in ?? () from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
#7  0x0000ff4c34e773e4 [PAC] in std::terminate() () from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
#8  0x0000ff4c34e81e44 [PAC] in __cxa_throw () from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
#9  0x0000ff4c30ac6d10 [PAC] in ggml_vk_ctx_end(std::shared_ptr<vk_context_struct>&) () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libggml-vulkan.so.0
#10 0x0000ff4c30bdc2e8 in ggml_vk_build_graph(ggml_backend_vk_context*, ggml_cgraph*, int, ggml_tensor*, int, bool, bool, bool) [clone .isra.0] () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libggml-vulkan.so.0
#11 0x0000ff4c30bdd1a8 in ggml_backend_vk_graph_compute(ggml_backend*, ggml_cgraph*) () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libggml-vulkan.so.0
#12 0x0000ff4c34422c1c in ggml_backend_sched_graph_compute_async () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libggml-base.so.0
#13 0x0000ff4c3459b0c0 in llama_context::graph_compute(ggml_cgraph*, bool) () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libllama.so.0
#14 0x0000ff4c3459e434 in llama_context::process_ubatch(llama_ubatch const&, llm_graph_type, llama_memory_context_i*, ggml_status&) () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libllama.so.0
#15 0x0000ff4c345a50b0 in llama_context::decode(llama_batch const&) () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libllama.so.0
#16 0x0000ff4c345a6b7c in llama_decode () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libllama.so.0
#17 0x0000ff4c35093d30 in test_prompt(llama_context*, int, int, int) () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libllama-bench-impl.so
#18 0x0000ff4c350a2068 in llama_bench(int, char**) () from /home/orion/Projects/llama.cpp-vulkan/build/bin/libllama-bench-impl.so
#19 0x0000ff4c34be2f1c in __libc_start_call_main (main=main@entry=0xbd9e55c21180 <main>, argc=argc@entry=3, argv=argv@entry=0xffffefb5cea8) at ../sysdeps/nptl/libc_start_call_main.h:59
⚠ warning: 59  ../sysdeps/nptl/libc_start_call_main.h: No such file or directory
#20 0x0000ff4c34be305c [PAC] in __libc_start_main_impl (main=0xbd9e55c21180 <main>, argc=3, argv=0xffffefb5cea8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:360
⚠ warning: 360 ../csu/libc-start.c: No such file or directory
#21 0x0000bd9e55c211f0 [PAC] in _start ()
[Inferior 1 (process 30818) detached]
terminate called after throwing an instance of 'vk::OutOfDeviceMemoryError'
  what():  vk::CommandBuffer::end: ErrorOutOfDeviceMemory
Aborted                    (core dumped) ./build/bin/llama-bench -m ../llm/qwen2.5-0.5b-instruct-q4_k_m.gguf

I thought that fix would’ve landed in Mesa V26+, but I might be mistaken. Here’s my Mesa packages on this image if relevant:

``
orion@orion-Radxa-Orion-O6:~/Projects/llama.cpp-vulkan$ apt list --installed 2>/dev/null | grep mesa
libegl-mesa0/resolute,now 26.0.3-1ubuntu1 arm64 [installed,automatic]
libgl1-mesa-dri/resolute,now 26.0.3-1ubuntu1 arm64 [installed,automatic]
libglx-mesa0/resolute,now 26.0.3-1ubuntu1 arm64 [installed,automatic]
mesa-libgallium/resolute,now 26.0.3-1ubuntu1 arm64 [installed,automatic]
mesa-vulkan-drivers/resolute,now 26.0.3-1ubuntu1 arm64 [installed,automatic]
``

ownia · May 27, 2026, 2:52am

Is there a way to switch to DDK on Ubuntu?

zuccon · May 27, 2026, 8:25am

I’ve created an issue here:

https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15551

In short, it seems like the Mali G720 has two heaps:

A Private Heap (limited to 32bit - ~4GB)
A (general?) heap (limited to 48bit - ~very large number)

At the moment, it seems like everything is being allocated to the Private Heap (4GB/32bit). Hence, when trying to run Llama.cpp+Vulkan, we run into OOM very quickly.

tobhe · June 10, 2026, 11:56am

I am following your progress on the upstream bug. Once we have a proper fix I’d be happy to ship it in our ppa. I also managed to reproduce the issue on my machine.

tobhe · June 10, 2026, 1:32pm

EDIT: My bad, it was falling back to CPU. It doesn’t fix the issue.

Installing mesa 26.0.8-1ubuntu0.1 from proposed fixes the issue for me, with that I get:

./llama-bench --model qwen2.5-0.5b-instruct-q4_k_m.gguf 
| model                          |       size |     params | backend    | ngl |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | --------------: | -------------------: |
| qwen2 1B Q4_K - Medium         | 462.96 MiB |   630.17 M | Vulkan     |  -1 |           pp512 |        180.57 ± 0.82 |
| qwen2 1B Q4_K - Medium         | 462.96 MiB |   630.17 M | Vulkan     |  -1 |           tg128 |         60.72 ± 0.61 |

djonibrave · June 12, 2026, 8:09pm

Minisforum MS-R1 sound not working ( front jack 3.5mm ). The problem can be partially solved by reassigning the pins.

zuccon · June 12, 2026, 10:43pm

I’m sorry, but I might not have a fix for quite some time.

While the proposal I have in there allows it to work (by allowing internal allocations to use the 48bit address space), it doesn’t really address the core issue (why it wants to allocate so much internal memory in the first place).

I’m still trying to debug exactly why this is (prime suspect right now is that it’s to do with workgroups not being properly implemented on Valhall arch, causing fresh TLS allocations), but probably won’t be able to return to it for a few weeks.