I am currently running the 22.04 image from the user crossplatformdev, but it uses a non standard kernel and is stuck at 22.04.
My goal is to use the stock kernel, thus keeping upgrade-ability and reducing the complexity.
I then tried to use the “stock” Ubuntu 24.04.1 desktop image you can download/write via Raspberry Pi Imager.
This booted and I could see the output on the external screen via HDMI.
I then checked the device tree files in /boot/firmware/overlays and added the clockworkpi-uconsole.dtbo and referenced it in the config.txt, which looks like this:
I appended cmdline.txt with cfg80211.ieee80211_regdom=DE (or whatever your country is).
All of this got me working keyboard, trackball and WiFi and of course display output via HDMI on quasi stock Ubuntu 24.04.
What is still not working is mainly the built-in screen and the 4G module, but the last one may be usable after installing the script from crossplattformdev called make_gpio_package.sh, which includes GPIO settings for the 4G module. I did not test sound output yet, but I assume that this is also not yet working but will be after installing the aforementioned script.
Please let me know, if you have any information how to get the screen running without compiling a custom (non-easily-upgradable) kernel.
This would be great.
You need the driver for the panel (screen). You will also need to edit the PMU driver to get some other things working right (apx20x).
The uConsole will never have easy up-gradable kernel. The best you can do is setup a script to build and package the kernel and upload it to your own repo for updating. I’ve done that for Debian Bookworm and have been providing kernel updates for around 8 months now.
“If you build they will come.” I’m sure there is a bunch of people that would want to use Ubuntu if it could get updates. Building the kernel on the uConsole itself takes 2 hours but is much quicker on some real hardware. You can host the package repo on github for free.
I really wish Clockwork use more standard parts so we wouldn’t have to deal with this. It is what it is though and some work needs to be done to get a distro working on it.
I’m wondering how far we could go down the DKMS path; With that, we keep the source files for uC drivers, and a generic kernel (without the screen, PMU drivers etc.) can be used to boot up the system and mount root, then dynamically load the drivers.
For kernel updates, these modules will be automatically recompiled.
The challenge (of course) is that the kernel driver API is not that stable, and if a new version breaks the compatibility, kernel update will fail.
At least the relevant PMU functions seem to be available in stock, as I had a correct battery status reading after boot without adding anything other than the mentioned things.
What other things are there, which are missing?
It seems that only the display is the main culprit for getting this done, really.
DKMS is nice idea, so that the screen behaves like the nVidia driver so to speak @Rex How did you integrate the driver into your kernel image?
As the kernel major version on Ubuntu LTS tends to be quite stable for the release lifetime, the DKMS downsides would only be apparent, if you would try a system upgrade to say 26.04 in the future. Then you would have to recompile the module(s). I would think, that this would be better than having to theoretically recompile the kernel when for example a security fix comes out inside the current release, which does not exist in the current kernel image and would be available upstream/in stock.
I have the Raspberry Pi linux kernel forked and the relevant Clockwork stuff added to it. That way I can merge the changes made by RPi, clone, build, publish.
May I enquire how you did that exactly?
Ideally I would like to reproduce your steps with the corresponding Ubuntu Raspi-Kernel.
For example, where did you get the relevant Clockwork stuff from?
I took the patches from @yatli 6.1.y fork and applied them to my fork of 6.6.y. I had to do a little bit of the patching by hand but not much. I’ve had to change the timing on the panel driver for the uConsole to get it to work with both the CM4 and 5, and I’ve reworked the overlays since.
