Yocto for chip bring-up. MOS4 for the application surface.

Layer boundary

Yocto builds. MOS4 runs.

flowchart TB
  subgraph App["MOS4 — application runtime layer"]
    M1[Micro services · supervisor · per-service OTA · observability]
  end
  subgraph Img["Linux image (Yocto-produced)"]
    L1[Kernel · userland · systemd]
  end
  subgraph Y["Yocto build system"]
    Y1[bitbake · poky · meta-* layers · BSPs]
  end
  Y1 -->|produces| L1
  L1 -->|runs| M1

mos-distro reads a bundle.toml manifest and a Cargo workspace, then generates a self-contained bundle — monolith binary, config, data files — installed onto the Yocto-produced image. It does not replace bitbake, poky, or meta layers.¹

Base images

Yocto, Debian, and buildroot — all supported.

cargo distro generates bundles that install onto Yocto-produced, Debian-based, and buildroot-based images. MOS4 does not replace the existing image build pipeline. Yocto is the most common production path; Debian and buildroot are confirmed alternatives.²

FAQ

The questions we hear most.

• Does MOS4 replace Yocto, bitbake, or meta layers?

  No. MOS4 is the application runtime layer that runs on the image Yocto produced. Yocto produces the kernel and userland; MOS4 adds the service supervisor, typed IPC, OTA, observability, and vehicle-domain micro services above that base. The two are complementary.

• Is there a meta-mos layer?

  Yes — Munic maintains a meta layer that pulls MOS4 micro services in at the correct Yocto layer, compatible with existing BSP and distro layers. Access is gated under an evaluation agreement. <a href="/contact?topic=yocto-eval">Talk to engineering</a>.

• Does MOS4 replace systemd?

  No. systemd boots the platform; MOS4 runs as a systemd unit (installed at /mnt/user/start.sh, picked up at runlevel 5) and supervises application micro services above it. The two coexist.

• Can I update micro services without reflashing the image?

  Yes — mos-update runs per micro service delta OTA: download, SHA-256 verify, Ed25519 validate, delta apply, A/B partition commit, automatic rollback via bootcount. Yocto-style full-image updates remain available for kernel and base-image changes.

• What build environments are supported for cross-compilation?

  Yocto, Debian-based, and buildroot-based images are all supported. On macOS, OrbStack handles modem-class cross-compilation; other targets require a Linux build host or OrbStack. The OE SDK sysroot at /opt/oecore-cortexa7/ remains required for ARM soft-float cross-compilation on modem-class hardware.

• How do I evaluate MOS4 on Yocto hardware before committing to meta-mos?

  <a href="/contact?topic=yocto-eval">Talk to engineering</a>. The quickest on-target path is evaluated per programme.

Footnotes

Comparison sources.

1. Yocto Project terminology — bitbake, poky, and meta layers are the documented build-system primitives. mos-distro reads bundle.toml + a Cargo workspace at the application layer. Source: yoctoproject.org; MOS4 from /platform/architecture.
2. Base-image coverage verified against the mos-distro CI matrix: Yocto-produced ARM images, Debian-based images, and buildroot-based images each run an installed MOS4 bundle in the per-commit pipeline.
3. Modem-class reference profile boot timing (1.6 s first-app-ready, 28.4 MB steady-state RSS) measured on the modem-class reference board. Methodology: cold boot to first successful EventBus service call.