uConsole OS directory

uConsole
, , ,
1

This post catalogs all the available operating systems available for the uConsole. The uConsole is compatible with a very wide variety of cores, also known as compute modules, which differ in capability, hardware design, and occasionally even architecture, and so these operating systems are grouped by system module, as none support them all. For a guide to hardware, see the companion hardware directory

There are a lot of operating system images floating around the forum. You can help by contributing more if you find they aren’t in these lists. ClockworkPi uConsoles currently only work with Linux as their peripherals need custom kernel patches, so although these are all separate OSes, they do all share the kernel Linux, with the lone exception being EwokOS for the CM4 uConsole.

A given uConsole Linux distribution needs core support and a Linux kernel patch to support the screen, an LVDS panel connected through DSI. Newer consoles have a slightly different panel and need an OS updated to support it. It also needs a patch to support the battery controller.

ClockworkPi cores

ClockworkPi’s first-party cores include the A-04 and A-06, each 64-bit ARM, and the R-01, which is 64-bit RISC-V. They all use the Raspberry Pi Compute Module form factor, which is the DDR2 SO-DIMM form factor.

The uConsole was originally offered with one of three cores; the A-04 (cancelled prior to shipping), the A-06, or the Raspberry Pi CM4. There are no operating systems compatible with the A-04 on the uConsole.

core operating system kernel version format URLs
R-01 Ubuntu 22.04 unknown unknown thread
R-01 ClockworkOS 5.4.61 .img GitHub, direct download, Google Drive
A-06 Armbian 22.02 5.15.25 source thread reply, GitHub
A-06 ClockworkOS 5.15.119 .img GitHub, direct download, Google Drive
A-06 Arch 5.16.2 source, .img GitHub
A-06 Arch 6.2 source, .img thread, GitHub
A-06 Arch 6.2 source, .img thread reply, GitHub, Google Drive
A-06 Manjaro 6.2.7 .img thread reply, Dropbox
A-06 Arch 6.5.9-0 source, .img, .pkg.xz GitHub
A-06 NixOS 6.6 guide NixOS wiki

Raspberry Pi Compute Modules

Raspberry Pi invented the Compute Module (title cased, as it’s the name of the brand) form factor to be able to embed Raspberry Pi SoCs in places where a full SBC would be inappropriate. Theoretically the Raspberry Pi Compute Module 1 (32-bit ARM) may work in the uConsole but the earliest supported Compute Module in the uConsole is the Compute Module 3, as the CM3+ was sold with the earlier DevTerm (which uses the same ClockworkPi mainboard), and the only Raspberry Pi Compute Module sold with the uConsole is the Compute Module 4.

After the release of the uConsole, Raspberry Pi came out with the Compute Module 5, which remains the latest and most performant Raspberry Pi module.

@Rex’s assembled uConsole operating systems are widely recommended here as he has spent a lot of time making them work well with all the available uConsole hardware and mods. For his files, see his MEGA, Google Drive, or, updated less frequently, Drime. Rex builds and provides these operating systems for free, but if they’re useful to you, consider buying him a coffee.

Compute Module(s) operating system kernel version format URLs
CM4 Kali unknown .img, guide thread reply, wiki page
CM4, CM5 NixOS unknown .img thread reply, GitHub
CM4 Raspberry Pi OS unknown .img thread, Google Drive
CM4 ClockworkOS 5.10.17 .img GitHub, direct download, Google Drive
CM4 Debian 12 5.10.17 .img thread, GitHub
CM4 Raspberry Pi OS 5.10.110 guide Joseph’s Projects
CM3, CM4, CM4S Debian 12 6.1.21 .img thread
CM4 Pop_OS 6.6.35 proof of concept thread reply
CM4 Void 6.6.51 .img thread, GitHub
CM3, CM4, CM5 Debian 12 6.6.78 .img thread, formerly provided by Rex
CM3, CM4, CM5 Manjaro 6.12.27 .img thread, provided by Rex, but only on Drime
CM4 postmarketOS 6.12.30 installer thread, wiki page
CM3, CM4, CM5 ParrotOS 6.12.45 .img thread, Google Drive
CM4, CM5 Arch 6.12.51 source, guide thread, forgejo
CM4 ClockworkOS 6.12.62-v8+ .img GitHub, direct download, Google Drive
CM4 Fedora Kinoite 44 6.12.62-v8+ .img thread, direct download
CM4 Fedora 44 6.12.62-v8+ .img thread, direct download
CM3, CM4, CM5 Debian 12 6.12.64 .img thread, GitHub
CM3, CM4, CM5 Debian 13 6.12.64 .img thread, GitHub
CM3, CM4, CM5 Ubuntu 24.04 6.12.64 .img thread, GitHub
CM3, CM4, CM5 Debian 12 6.12.67 .img thread, provided by Rex
CM3, CM4, CM5 Debian 13 6.12.67 .img thread, provided by Rex
CM4, CM5 DragonOS 6.12.67 .img thread, MEGA, provided by Rex
CM4, CM5 Kali 6.12.67 .img thread, provided by Rex
CM3, CM4, CM5 ParrotOS 6.12.67 .img thread, provided by Rex
CM3, CM4, CM5 RetroPie 6.12.67 .img thread, provided by Rex
CM3, CM4, CM5 TwisterOS 6.12.67 .img thread, provided by Rex
CM3, CM4, CM5 Ubuntu 24.04 6.12.67 .img thread, MEGA, provided by Rex
CM3, CM4, CM5 Debian 13 6.12.78 APT repository GitHub
CM3, CM4, CM4S Arch 6.16 source thread, thread, GitHub
CM4, CM5 Arch kernel 6.18.6 .pkg.tar.xz thread, GitHub
CM4 Debian 13 kernel 6.18.20 .deb thread, Google Drive
CM4, CM5 Arch kernel 7.0.9 .pkg.tar.xz thread, GitHub
CM4 NixOS unspecified source thread, forgejo, GitHub

There are some CM4 ClockworkPi OS releases in this Google Drive folder, including one newer (v3.0) than the latest known release (v2.1).

There is one single non-Linux OS for the uConsole, EwokOS, for which there is a thread and a GitHub repository. It’s implied that EwokOS targets the CM4.

Orange Pi compute modules

Orange Pi offers compute modules in the same form factor with up to 32GB RAM. Recently some folks have managed to get this working in the ClockworkPi adapter, though it requires some hard modification to the mainboard.

compute module(s) operating system kernel version format URLs
Orange Pi CM5 Gentoo unspecified patchset thread, gitflic, GitHub

Radxa compute modules

Radxa is another company that releases Raspberry Pi form factor compute modules, and their CM5 is somewhat popular despite barely unsupported and unstable because it comes with up to 32GB RAM, twice what the Raspberry Pi CM5 supports, and has a faster processor, NPU, and optional GPU. Full use of a Radxa CM5 requires HackerGadgets’ adapter board in place of ClockworkPi’s.

compute module(s) operating system kernel version format URLs
Radxa CM5 Debian 11 unknown guide thread, GitHub
Radxa CM5 Arch 6.1.84 guide thread, GitHub
Radxa CM5 Debian 12 6.1.84 .img thread, MEGA, Google Drive
Radxa CM5 Debian 12 6.1.115 proof of concept thread
Radxa CM5 Debian kernel 7.1 proof of concept thread

tl;dr

Raspberry Pi modules tend to have the best software support. Using a module from neither Raspberry Pi or ClockworkPi is veering off the beaten path. Using a non-Debian OS requires much configuration and futzing. Rex’s operating system images are the best supported.

18 Likes
Will he CM4S work in uConsole?
Experimental content repository for Raspberry Imager
uConsole core and adapter board directory
Is there a starter guide?
uConsole hardware directory
Request for an update for RadxaCM5-uConsole Images
2

Not to pick on a possible typo in a draft but the R-01 is 64 bits.

1 Like
3

Thank you for the correction, I would not have noticed that one. I’ll edit the post.

1 Like
4

Ha, that sort of thing happens, you know, I think not a lot of people love the R-01, I love it.

(This is an extremely good post, thank you.)

a06_vs_r01
a06_vs_r01736Ă—721 72.9 KB

1 Like
5

One small addition: The Raspberry Pi OS can also use CM5

2 Likes
6

Which Raspberry Pi OS? The official ClockworkPi releases? Does that apply to all versions?

1 Like
7

I’m gonna take some time to write about my own experience with Arch. This does not reflect the uConsole experience. This is about a specific OS, and its issues aren’t uConsole-specific.

I’ve been using Arch Linux ARM for about two years now on my uConsole. Many things have worked (having a more recent kernel is awesome) but many things haven’t. makepkg(1) isn’t part of the base distro and pacman(8) despite having the right repositories could never find it, so in order to install it I had to download the package from the repo HTTP website and use pacman to install the tarball; then I could use the AUR. But after about a year, makepkg(1) started getting much more fussy about installing packages. It refused to install any package that didn’t explicitly list aarch64 as a supported architecture, so if I wanted to update anything from the AUR I had to pull the package from git(1), modify the PKGBUILD, and build it. Arch Linux ARM clearly plays second fiddle to Arch Linux in that half the stuff from the AUR, whether or not it listed aarch64 as supported, just would not build.

My Arch Linux ARM install is currently broken. This is what it looks like:

:: Searching AUR for updates...
:: There are 2 providers available for cargo:
:: Repository extra
    1) rust 2) rustup 

Enter a number (default=1): 
==> 
:: There are 2 providers available for cargo:
:: Repository extra
    1) rust 2) rustup 

Enter a number (default=1): 
==> 
:: There are 3 providers available for lib32-gcc-libs:
:: Repository AUR
    1) lib32-gcc-libs-git 2) lib32-gcc-libs-snapshot 3) lib32-gccrs-libs-git 

Enter a number (default=1): 
==> 
:: There are 3 providers available for lib32-glibc:
:: Repository AUR
    1) lib32-glibc-eac 2) lib32-glibc-git 3) lib32-glibc-git-native-pgo 

Enter a number (default=1): 
==> 
 -> aur dep warn:lib32-gcc-libs-gitlib32-glibc-eac circular dependencies not allowed
 -> aur dep warn:lib32-gcc-libs-gitlib32-gcc-libs-git self-referential dependencies not allowed
 -> aur dep warn:lib32-gcc-libs-gitlib32-glibc-eac circular dependencies not allowed
[ad infinitum]

I believe this is my punishment for not upgrading for two whole weeks, but it may simply be that I did not make the correct sacrifices to the correct deities. More likely, nobody tested the combination of packages I had, and now the dependency resolver has eaten its own tail. In my 7 or 8 years of running Arch on various things (as well as other systems) circular dependencies are the only consistent thing about using this OS. I can’t update anymore, by the way, so please don’t hack me.

Arch Linux also depends on SystemD, which many people love and many people dislike. I am not a big fan because it’s slow and incredibly, nails-on-chalkboard, obnoxious. It often does inexplicable things like draining half my battery while “shutting down” (I assume it is waiting for explicit, written permission from the SystemD maintainers) and stores its configuration files in about a hundred different directories vomited all over the /usr and /etc hierarchies like it was written by someone with short and long term memory loss during a stimulant binge. There is a joke operating system called ARMtix with HTTP (no SSL) repositories begging to be MitMed that attempts to replace Arch’s SystemD dependency with any of a handful of packaged initialization systems, but of course since about 5 service files are actually maintained for each init you must account for the time you will spend researching man pages and writing POSIX shell in order to use any packaged daemons.

Of course, the people who love SystemD know how to use it and do so with gusto; it is extremely feature-rich, so much so that there are often rumors that before it expands to include an e-mail client it will also be vendoring the kernel as Linux is required to use SystemD anyway. It’s not so hard to learn. Each one of SystemD’s thousand directories is documented, somewhere. SystemD is included in, at this point, most Linux distributions, so at this point avoiding it is like avoiding cars with automatic transmissions, except if automatic transmissions guzzled gas while taking 5 hours to shut off. I really don’t like SystemD.

I’m sure Arch has other bugs and things that annoy me but I’ve either gotten used to them or encountered them so infrequently that I forgot them. I think two years is the longest I’ve seen the distro last in installation. Maybe I could manually repair the packaging errors but I’d rather get out while I still can. I’ve been eyeballing Void and other image-ready distros on here.

2 Likes
8

Please add my kernel to list. Patched OuinOuin74's arch kernel

1 Like
9

While I do violently love this post… this should be in a Wiki no?
Is there a wiki for uConsole or rather ClockworkPI’s ecosystem?

10

Technically yes, but it’s not really active or easy to contribute to afaik

1 Like
11

Oh yea, found it now. A wiki where you need to use GIT to modify it.

They should have changed it to MediaWiki or alike which allows you to make an account
and then edit pages directly.

12

Traditionally, for all the Clockwork devices (from GameShell on) the forum has been the only place to really find useful and up to date information. (There’s useful stuff on Discord too, but the most useful stuff from there usually makes its way to the forum in one form or another.) But it always involves searching and wading through tons of posts to try to find the most recent info, and also find the exceptions and caveats (and fixes) that others have posted. Ocassionally someone will come along and put together useful documentation, and perhaps even continue to maintain it for a while, but the only way to really find that stuff is to get lucky searching the forums, and then there’s always the chance that it’s gone stale and doesn’t include newer information that was discovered/created later.

Communication and documentation around Clockwork products is kind of a mess, and only really driven by and maintained by enthusiasts. At one point (many years ago!) they had an official community manager sort of person on the forums, and more engagement with the community in general, but documentation and helpful HowTo stuff has always been pretty minimal. :frowning:

1 Like
13

Radxa CM5 seems to have the latest kernel 7.1. We are looking forward to James_Kent’s sharing.

1 Like
14

I couldn’t find the wiki when I looked. I’m glad someone shared it. I’d contribute but it would be a serious undertaking to write an entire uConsole section and I don’t have a whole lot of time lately, so maybe some other time.

1 Like
15

My Kernel build is 7.0.9, not 6.18

1 Like