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.

tobhe · July 7, 2026, 11:53pm

Hi all, I published a larger kernel update today that should fix the suspend issues we saw with the previous kernel. It should also fix compatibility with CIXtechs proprietary Mali drivers available from their website.

web0net · July 8, 2026, 11:41am

Hi, tobhe!
Maybe you have something like a test suite to check how system works?

aiwintermute · July 13, 2026, 8:13am

I use my Orion O6 as a PC for running an agent, so it works 24/7. I noticed that after a few days, the system becomes unresponsive.

This is what I get at the end of journalctl -b -1 -p 3 -k output:

Jul 13 08:08:56 orion-o6 kernel: rcu: rcu_preempt kthread timer wakeup didn't happen for 60025 jiffies! g15105949 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
Jul 13 08:08:56 orion-o6 kernel: rcu:         Possible timer handling issue on cpu=7 timer-softirq=2702539
Jul 13 08:11:06 orion-o6 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Jul 13 08:11:06 orion-o6 kernel: rcu:         11-...!: (0 ticks this GP) idle=46b0/0/0x0 softirq=1275785/1275785 fqs=2 (false positive?)
Jul 13 08:11:06 orion-o6 kernel: rcu:         (detected by 1, t=60018 jiffies, g=15106145, q=383545 ncpus=12)
Jul 13 08:11:06 orion-o6 kernel: rcu: rcu_preempt kthread timer wakeup didn't happen for 60025 jiffies! g15106145 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
Jul 13 08:11:06 orion-o6 kernel: rcu:         Possible timer handling issue on cpu=7 timer-softirq=2702539
Jul 13 08:11:06 orion-o6 kernel: rcu:         Possible timer handling issue on cpu=7 timer-softirq=2702539
Jul 13 08:11:06 orion-o6 kernel: rcu: rcu_preempt kthread starved for 60045 jiffies! g15106145 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=7
Jul 13 08:11:06 orion-o6 kernel: rcu:         Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
Jul 13 08:11:06 orion-o6 kernel: rcu: RCU grace-period kthread stack dump:
Jul 13 08:11:06 orion-o6 kernel: rcu: Stack dump where RCU GP kthread last ran:
Jul 13 09:25:32 orion-o6 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Jul 13 09:25:32 orion-o6 kernel: rcu:         4-...!: (0 ticks this GP) idle=c5d8/0/0x0 softirq=4634382/4634382 fqs=2 (false positive?)
Jul 13 09:25:32 orion-o6 kernel: rcu:         (detected by 1, t=60018 jiffies, g=15132853, q=399907 ncpus=12)
Jul 13 09:25:32 orion-o6 kernel: rcu: rcu_preempt kthread timer wakeup didn't happen for 60025 jiffies! g15132853 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
Jul 13 09:25:32 orion-o6 kernel: rcu:         Possible timer handling issue on cpu=7 timer-softirq=2702539
Jul 13 09:26:32 orion-o6 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Jul 13 09:26:32 orion-o6 kernel: rcu:         4-...!: (0 ticks this GP) idle=c770/0/0x0 softirq=4634384/4634384 fqs=2 (false positive?)
Jul 13 09:26:32 orion-o6 kernel: rcu:         (detected by 1, t=60018 jiffies, g=15132861, q=402930 ncpus=12)
Jul 13 09:26:32 orion-o6 kernel: rcu: rcu_preempt kthread timer wakeup didn't happen for 60025 jiffies! g15132861 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
Jul 13 09:26:32 orion-o6 kernel: rcu:         Possible timer handling issue on cpu=7 timer-softirq=2702539
Jul 13 09:27:32 orion-o6 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Jul 13 09:27:32 orion-o6 kernel: rcu:         4-...!: (0 ticks this GP) idle=c820/0/0x0 softirq=4634386/4634386 fqs=2 (false positive?)
Jul 13 09:27:32 orion-o6 kernel: rcu:         (detected by 6, t=60018 jiffies, g=15132869, q=397991 ncpus=12)
Jul 13 09:27:32 orion-o6 kernel: rcu: rcu_preempt kthread timer wakeup didn't happen for 60025 jiffies! g15132869 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
Jul 13 09:27:32 orion-o6 kernel: rcu:         Possible timer handling issue on cpu=7 timer-softirq=2702539
Jul 13 09:30:03 orion-o6 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Jul 13 09:30:03 orion-o6 kernel: rcu:         3-...!: (0 ticks this GP) idle=da88/0/0x0 softirq=4781290/4781290 fqs=2 (false positive?)
Jul 13 09:30:03 orion-o6 kernel: rcu:         (detected by 6, t=60018 jiffies, g=15133013, q=395816 ncpus=12)
Jul 13 09:30:03 orion-o6 kernel: rcu: rcu_preempt kthread timer wakeup didn't happen for 60025 jiffies! g15133013 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
Jul 13 09:30:03 orion-o6 kernel: rcu:         Possible timer handling issue on cpu=7 timer-softirq=2702539
Jul 13 09:30:03 orion-o6 kernel: rcu: rcu_preempt kthread starved for 60045 jiffies! g15133013 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=7
Jul 13 09:30:03 orion-o6 kernel: rcu:         Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
Jul 13 09:30:03 orion-o6 kernel: rcu: RCU grace-period kthread stack dump:
Jul 13 09:30:03 orion-o6 kernel: rcu: Stack dump where RCU GP kthread last ran:

Any ideas on what causing this? “OOM is now expected behavior” probably is the cause of the crash?

aiwintermute · July 13, 2026, 8:38am

@tobhe also wanted to let you know that after latest updates (today), USB-C Dispaly output stopped working properly.

After reboot, the screen does not detect any signal from USB-C. There is signal on HDMI - and it appears the board detects both displays!

Any additional info I can provide to help you debug this?

FYI, I’ll be monitoring for signs of more OOM crashes after the update.

tobhe · July 14, 2026, 1:01pm

Thanks for the report! Does it work if you unplug the cable and plug it back in? I think I tested it and it did work on my MS-R1 but I might not have tested with USB-C plugged in from the start.

beling · July 27, 2026, 3:14pm

Thanks for your work from Germany.

Hopefully your next kernel revision is not too far away and will resolve the display problem.

Can you please supply kernel version 7.1 and maybe for testing 7.2.rc ?

Thanks in advance

GinKage · July 28, 2026, 7:56am

Actually, the display problem should be solved with some latest patches from Cix, though it may also need the 2026q2 firmware. But yeah, I’d also like to see the upgrade (possibly, when 7.2 is released).

aiwintermute · August 3, 2026, 7:29pm

@tobhe sorry for the delayed reply. good news is that after last update the spontaneous crashes are no more!

For USB-C display: I normally use the same cable for power and display (the screen provides the power). So, naturally unplugging cable and plugging it back just restarts the board…

However I did try just now to provide power to one USB and have display USB-C connected. No image at first, but after reconnection the image appears. Hopefully this will be fixed as well in new releases.

Is there anywhere we can see current progress and latest news?