Ubuntu 24.04 on Tachyon - Early Access & Open Development

Tachyon
1

Hello Tachyon Community,

This is a thread to announce the initial build of 24.04 for Tachyon! This is taking a long time to get out as I noted in the 1.0.170 release note, but we really don’t want to hold things back until they’re “perfect” so starting now, we’re moving our Ubuntu 24.04 development conversation into the open. No more internal slack threads!

This means you’ll see posts from our engineers (and from me) here in the forum as we share milestones and the messy bits: what works, what’s broken, and how we’re fixing it. Think of it as a running lab notebook you can join.

Background

Ubuntu 24.04 was ported for the QCS6490 by Qualcomm / Canonical under a commercial relationship to make a certified image for the processor - it went GA around 1 month ago and there are official images for the Qualcomm developer boards now available (RB3 Gen 2). It supports the Qualcomm varies SDKs (info coming soon on how to use the Camera and Robotic stacks) as well as their Docker based containers (compatible with Particle's platform managed container engine).

So what is this build then? Well, that porting effort was for the QCS6490 variant of the 6490 platform - Tachyon is using the QCM variant (M == “modem”? I don’t actually know how the product name works, other than we have the chip with the 5G modem inside it!) and so this image needs adapting to get it to work for our device. I asked that we take a precautionary approach here to get this build out, as misbehaving on the cellular network is pretty bad for many folk (especially our business!). Accordingly, we have taken an initial and gentle pass to releasing 24.04 - it's based on the 20.04 system image and replaces files inside it (vs building a complete system image). It preserves the RF calibration, the cellular regulatory info etc.. as is shaped such that we can get everything working in the open before we rip up the disk structure to be a little more standard.

What works today

  • Networking: Wi-Fi + Bluetooth, USB Ethernet
  • USB: Core connectivity is stable
  • Boot: Open U-Boot + near-mainline Linux kernel
  • Userland: Full Ubuntu 24.04 LTS (apt, systemd, dev tools)

What’s not ready yet

  • 5G modem & GNSS
  • GPIO / 40-pin header / Activity LED (looks to just be the device tree that needs configuring)
  • USB-C host mode (defaults to device mode via adbd.service and doesn't auto switch)
  • Display output (DP Alt-Mode / DSI drivers + DT updates - needs the USB switch code to work)

Right now, this is essentially a headless build and despite all the bluster on "make sure we don't break the cellular stack", alas its missing the cellular piece at the moment (sadly, my favorite feature) and it will require work that only we can do to get this out.

How to build it

We’ve published docs to rebuild from scratch (Mac, Linux, or WSL2). In ~10 minutes you can make a flash-able ZIP file that boots into 24.04 and is based on (almost all) open source repos on our github site.

See the docs here: Overview | Particle Developer

Spoiler for those impatient - we uploaded the output from a build I ran here:

https://linux-dist.particle.io/prerelease/tachyon-ubuntu-24.04-RoW-desktop-formfactor_dvt-9.9.999.zip

How to install

Using the Particle CLI, you can go through device setup again and flash the 24.04 ZIP file using the following command:

particle tachyon setup --version=/Users/nicklambourne/Downloads/tachyon-ubuntu-24.04-RoW-desktop-formfactor_dvt-9.9.999.zip

( Update the path of course :slight_smile: )

What’s first?

When the device boots, its console is available on either UART or over ADB on the USB port.

If you’re actively contributing to 24.04, we’ll send you a Tachyon debug adapter free - please email kent.mok@particle.io and include a picture of a cat and/or garlic bread.

What’s next?

Coming very soon to this thread are the following items:

  • Our reference complete DTS file that is used on 20.04. This is where most of the work is to get all the peripherals running is - translating this file into the 24.04 DTS. Scott will update us with this file tomorrow!
  • Display support - Andrey is working on bringing up with Rasberry Pi Display Touch 2 as an example so you all can help port over the other Rasberry Pi displays. The code appears very similar which is super helpful.

How you can help

  • Test: Flash it, connect, run workloads, file issues
  • Contribute: PRs welcome (build scripts, kernel, overlays)
  • DTB experts: GPIO, LEDs, SPI, camera all need attention
  • Share: Post findings & logs so others benefit

Links

We know developing in the open carries risk, but it also carries energy. The team will show up and would love some feedback!

Cheers folks,

The Tachyon Team

8 Likes
2

Well.. i am a bit back and forth between calling this a step forward and ditching my tachyon now altogether. It is, after all, the “Better than nothing Beta” i had hoped for while obviously havent tested it yet i dreaded it could be.

But considering active development i would like know if there is any progress/thought on booting “external” drives, be it USB (please no) or PCIe (please yes) so chances are less likely to brick something or wear our internal memory. If that is not a possibility at the moment.. is there a good way of doing A/B switching of OSs on the internal memory for testing?

3

Hi @Nachtwind, thanks for jumping in early to test 24.04! You’ve landed in exactly the right place, and it sounds like you’ve got some very specific problems you’re looking to solve. If you don’t mind indulging us, I’d love to hear more about what you’re trying to achieve as that feedback is incredibly valuable and helps us prioritise.

On storage: the internal memory is UFS, which is a managed SCSI-style interface. Compared to eMMC and the raw NAND/NOR systems you might have run into on older boards, UFS is dramatically more resilient - the controller has built-in redundancy and error management, and it’s essentially the same tech phones rely on today. Filesystems can of course still be corrupted if you try hard enough, but we’ve been intentionally stress-testing and haven’t seen any issues so far. It’s a far cry from SD cards, which really can be “hard bricked” quite easily.

The images we ship are already partitioned into A/B out of the box and the bootloader is capable of switching. Right now, our flashing tools don’t yet let you explicitly target A vs. B, but in theory you can run a script over the zip file and manually cut out the A or the B images). We already do very large volumes of OTA updates across the fleet (in the many millions per year), so adding that support isn’t conceptually difficult, it’s more a question of timing and priorities, so, very curious to know more about your concerns around bricking or wear, and what workflows you want (USB/PCIe boot, A/B testing, etc.). The more detail, the better we can make sure we’re solving real problems.

As for the boot side, the code we provided can already use PCIe as a rootfs if you update the command line - it's available from within Ubuntu and you need to populate the right rootfs param in the right location (I think it would be in the grub config file that tells the kernel which fs to use). The chipset can't boot from PCIe directly (as the ROM only supports internal flash for the initial boot sequence), but you can boot via UFS boot loaders and then jump to run the rootfs off PCIe - I would argue that the boot loaders are a better place anyway as you can choose to mount over the network there etc.... If you need help here, we can add to the list to get documented or if you figure it out, please let us know!

Thanks again for being one of the first to dig in.

Cheers,

Nick

4

my concearns on memory wear are rather a relict of using quite a lot of industrial grade equipment that used to have less than consumer grade harddisks running mostly windows and not having turned off most of the stuff that wears down emmc (etc) quite fast.

I dont want to start talking about SD cards. That was one of the major reasons i began hoping/working on replacing my fleet of Jetsons with Tachyons if it ever lives up to its promises.

So.. if i get you right there is a good chance i wont brick my Tachyon while testing the 24 build (or developing (on) it) since i can always reflash using the particle cli?

Anyway.. i think i will give the UFS boot loader a try in the coming days and try to get my PCIe m.2 to boot.. once i have that running i will try to be of some help getting stuff running.. Cheers.

5

Hi @mrlambchop,
It looks like a stable Tachyon Ubuntu 24.04 release with cellular support is several months away, quite likely a 2026 Q1 release. It’s ok, we’re on the same journey with the same goals and have ample patience. I think most of us will chip in and assist where we can.

For those of us with only a single Tachyon, it would be helpful if we can purchase another Tachyon for testing and development of Ubuntu 24.04 and maintain the existing Tachyon as a stable Ubuntu 20.04 reference, without switching between the two Ubuntu versions.

As a request, can Particle look into offering a Tachyon at a discount for this purpose? It’ll assist with the “… developing in the open” efforts and testing contributions from the community.

Cheers!

1 Like
6

So…. uh… is it just me or are the docker images the composer tries to pull private?

~/Projekte/tachyon-composer main
❯ docker login
Authenticating with existing credentials... [Username: xxxxxxxxxxx]

i Info → To login with a different account, run 'docker logout' followed by 'docker login'


Login Succeeded

~/Projekte/tachyon-composer main
❯ make build_24.04 \
        INPUT_BASE_20_04_VERSION=1.0.170 \
        INPUT_REGION=NA \
        INPUT_UBOOT_VERSION=1.0.4 \
        INPUT_BASE_24_04_VERSION=14-276cd6b \
        INPUT_OVERLAY_STACK=ubuntu-headless-24.04 \
        INPUT_ENV_VARS="PKG_particle_linux=0.20.1-1,PKG_particle_tachyon_desktop_setup=2.7.0,PKG_particle_tachyon_ril=0.4.5-1,PKG_particle_tachyon_syscon=1.0.19-1,PIN_PRIORITY=900"
Tachyon System Image Composer v0.1.3
==> Fetching tachyon-overlays into /tmp/work/input/tachyon-overlays inside Docker
Unable to find image 'tachyon-system-image-builder:1.3' locally
docker: Error response from daemon: pull access denied for tachyon-system-image-builder, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

Run 'docker run --help' for more information
make: *** [Makefile:342: .tmp/input/tachyon-overlays/.installed] Fehler 125
7

Could you grab this repo GitHub - particle-iot/tachyon-overlays as well and try again?

8

That didnt change a thing.

I think that the docker error is the basis and the missing overlays just an outcome.

9

I forgot that I also needed to rm -rf .tmp before running the make command again.

10

Here we go.

Thanks :slight_smile:

Using Beckhoff Twincat3 all the time should have told me i could have tried a clean build and remove .tmp :wink:

~/Projekte/tachyon-composer main*
❯ make clean
Cleaning temporary files...
Cleanup completed.

~/Projekte/tachyon-composer main*
❯ rm -rf .tmp

~/Projekte/tachyon-composer main*
❯ make build_24.04 \
        INPUT_BASE_20_04_VERSION=1.0.170 \
        INPUT_REGION=NA \
        INPUT_UBOOT_VERSION=1.0.4 \
        INPUT_BASE_24_04_VERSION=14-276cd6b \
        INPUT_OVERLAY_STACK=ubuntu-headless-24.04 \
        INPUT_ENV_VARS="PKG_particle_linux=0.20.1-1,PKG_particle_tachyon_desktop_setup=2.7.0,PKG_particle_tachyon_ril=0.4.5-1,PKG_particle_tachyon_syscon=1.0.19-1,PIN_PRIORITY=900"
Tachyon System Image Composer v0.1.3
==> Checking if Docker image tachyon-system-image-builder:1.3 exists locally...
==> Trying to pull tachyon-system-image-builder:1.3
==> Building Docker image tachyon-system-image-builder:1.3
[+] Building 64.8s (16/16) FINISHED                                                                 docker:default
 => [internal] load build definition from Dockerfile                                                          0.0s
 => => transferring dockerfile: 2.03kB                                                                        0.0s
 => resolve image config for docker-image://docker.io/docker/dockerfile:1.7                                   1.5s
 => [auth] docker/dockerfile:pull token for registry-1.docker.io          
. . . . . .
1 Like
11

@mrlambchop thank you for the team’s hard work and appreciate the dev approach you guys take.

can Andrey give us a quick overview of how complete / tested /driver/gpu/drm is? Looking to test a non RPi MIPI DSI panel. And are we expecting the full DTS and working GPIO are coming within days / weeks? Without that I can’t send a reset sequence to switch on the panel before sending init command. And is there any DSI panel that has been tested so far with 24.04?

12

As Nick outlined above the immediate focus has been on the headless build, but the graphics are at the top of the priority list and should become available in the next weeks starting with DSI display support and Adreno GPU hardware acceleration with USB DP coming next.

Same as with a recent 20.04 release that added DSI support (Tachyon Ubuntu 20.04 Release 1.0.170) we are focusing on Raspberry Pi Touch Display 2 support and Waveshare Raspberry Pi displays (with Goodix touchscreen controller).

13

Just wondering here…

Today i started to set up my Stuff for building 24.04 and began building the image.

My current setup looks like this:

Created a new user on the tachyon, added a m.2 drive to PCIe fully wiped the disk and created an ext4 drive to start the build as documented on said drive (to give the internal memory some rest).
Basically it went smooth so far.. what bothers me and i am not sure if this is right: Does the “inflating” part really take like … more than 7 hours?

7 hours in and i am at ~5GB image…

What strikes me most is that the tachyon is mostly running on idle here…. but well.. i will keep it running a bit longer i guess :wink:

grafik
grafik955×702 62.6 KB

grafik
grafik900×155 17 KB

14

Alright… i restarted the whole thing on the internal memory and it went through in less than an hour.. but it looks to me that in the last step there is some problem within the scripts?

==> Creating temp GPT image: /var/tmp/tachyon_overlay/partitioned-327.img (size=4305453056; p1=4294967296) ==> Setting up loop device (4K alignment) ... LOOPDEV: /dev/loop1 ==> Partitioning GPT (single Linux fs 'system_a') ... Creating new GPT entries in memory. GPT data structures destroyed! You may now partition the disk using fdisk or other utilities. Creating new GPT entries in memory. Setting name! partNum is 0 The operation has completed successfully. partx: /dev/loop1: error adding partition 1 make: *** [Makefile:315: apply] Error 1

So besides this error ending my hope to have 24.04 running tonight i think there is some error in the build scripts.. it looks like the partition is created but it doesnt wait for the kernel to catch up (numPartitions = 0) and therefore fails…

Or do i miss something here?

15

Hey zpm1066

I think that is a very fair request - I'll come back to you on Monday with a proposal.

Thanks

Nick.

16

Folks,

Posting on behalf of Scott who put this page together today:

It's the device tree in component form, used for the 20.04 build. I'm gonna guess it contains "a lot of juicy things".

I'll post shortly with an updated page on the 24.04 side showing where the DTS integration in and what to change.

Any questions on the DTS above, please shout!

Thanks

Nick.

1 Like
17

Hey Nachtwind

I just ran the build on my laptop and output the log below as well as the time it took. MacBook Pro (2 years old or so).

Some caveats: (a) I have a 2GBs fiber connection to my laptop... (b) this was not a cold build, so the assets remain in the .tmp folder and were not fully refreshed (c) the docker images were already build.

From experimenting, the reason that the build took the most time (before optimizing) was because it was run in Docker as were were using cross tools, so I put them into a container.

I had not tried it on Tachyon itself because it had not occurred to me to use a PCIe disk and I didn't want to blow away all the assets - its a good idea :slight_smile: I'll give it a go

With regards to the error, I've not seen that - can you share the full log and I'll take a look asap?

Build log: build log - Pastes.io

Thanks!

Nick.

18

Alright.. lets see what is happening here:

Building on my X86-64 using Arch:

Building directly on Tachyon (internal Memory):

In both cases i did a fresh start. Comepletely removed everything relatid to the project. Git clond the composer, adjusted the make command for RoW, removed .tmp as well as “make clean” and started make.

19

Hi @mrlambchop , appreciate you looking into the request.

An early Black Friday for the kickstarter purchasers will certainly be a momentum boost to getting a stable Ubuntu 24.04 out sooner. We’re in for the long game with Particle.

Cheers!

20

Running into a problem when trying to build the image. I have all the prereqs loaded and also git cloned all the repositories so I'm not sure why it's complaining. I did run the make command with sudo.

 => ERROR [4/7] RUN if ! getent group "0" >/dev/null; then groupadd -g "0" builder; fi &&     useradd -m -u "0" -g "0" builder &&     usermod -aG sudo buil  0.5s
------                                                                                                                                                            
 > [4/7] RUN if ! getent group "0" >/dev/null; then groupadd -g "0" builder; fi &&     useradd -m -u "0" -g "0" builder &&     usermod -aG sudo builder &&       echo "builder ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/builder &&     chmod 0440 /etc/sudoers.d/builder:
0.454 useradd: UID 0 is not unique
------
ERROR: failed to build: failed to solve: process "/bin/sh -c if ! getent group \"${GID}\" >/dev/null; then groupadd -g \"${GID}\" builder; fi &&     useradd -m -u \"${UID}\" -g \"${GID}\" builder &&     usermod -aG sudo builder &&       echo \"builder ALL=(ALL) NOPASSWD: ALL\" > /etc/sudoers.d/builder &&     chmod 0440 /etc/sudoers.d/builder" did not complete successfully: exit code: 4
PUSH_IMAGE not set, skipping push
==> Fetching tachyon-overlays into /tmp/work/input/tachyon-overlays inside Docker
docker: invalid spec: :/project: empty section between colons

Run 'docker run --help' for more information
Installed tachyon-overlays into /tmp/work/input/tachyon-overlays
==> Setting up tachyon-overlay-tool tool inside Docker
docker: invalid spec: :/project: empty section between colons

Run 'docker run --help' for more information
make: *** [Makefile:397: /tmp/work/tools/tachyon-overlay-tool/.installed] Error 125