Yocto pour le bring-up silicium. MOS4 pour la surface applicative.

Frontière de couche

Yocto construit. MOS4 exécute.

flowchart TB
  subgraph App["MOS4 — couche runtime applicatif"]
    M1[Micro services · superviseur · OTA par service · observabilité]
  end
  subgraph Img["Image Linux (produite par Yocto)"]
    L1[Noyau · userland · systemd]
  end
  subgraph Y["Système de build Yocto"]
    Y1[bitbake · poky · couches meta-* · BSP]
  end
  Y1 -->|produit| L1
  L1 -->|exécute| M1

mos-distro lit un manifeste bundle.toml et un workspace Cargo, puis génère un bundle autonome — binaire monolithique, configuration, fichiers de données — installé sur l’image produite par Yocto. Il ne remplace pas bitbake, poky ou les couches meta.¹

Images de base

Yocto, Debian et buildroot — tous supportés.

cargo distro génère des bundles qui s’installent sur des images produites par Yocto, basées sur Debian et basées sur buildroot. MOS4 ne remplace pas le pipeline de build d’image existant. Yocto est le chemin de production le plus courant ; Debian et buildroot sont des alternatives confirmées.²

FAQ

Les questions qu’on nous pose le plus.

• MOS4 remplace-t-il Yocto, bitbake ou les couches meta ?

  Non. MOS4 est la couche runtime applicatif qui s’exécute sur l’image produite par Yocto. Yocto produit le noyau et l’userland ; MOS4 ajoute au-dessus le superviseur de services, l’IPC typé, l’OTA, l’observabilité et les micro services métier véhicule. Les deux sont complémentaires.

• Existe-t-il une couche meta-mos ?

  Oui — Munic maintient une couche meta qui tire les micro services MOS4 à la bonne couche Yocto, compatible avec les couches BSP et distro existantes. L’accès est sous accord d’évaluation. <a href="/fr/contact?topic=yocto-eval">Parlez à l’ingénierie</a>.

• MOS4 remplace-t-il systemd ?

  Non. systemd démarre la plateforme ; MOS4 s’exécute comme une unité systemd (installée à /mnt/user/start.sh, prise au runlevel 5) et supervise les micro services applicatifs au-dessus. Les deux coexistent.

• Puis-je mettre à jour les micro services sans reflasher l’image ?

  Oui — mos-update exécute l’OTA delta par micro service : téléchargement, vérification SHA-256, validation Ed25519, application delta, commit partition A/B, rollback automatique via bootcount. Les mises à jour complètes d’image style Yocto restent disponibles pour les changements de noyau et d’image de base.

• Quels environnements de build sont supportés pour la cross-compilation ?

  Les images basées sur Yocto, Debian et buildroot sont toutes supportées. Sur macOS, OrbStack gère la cross-compilation de classe modem ; les autres cibles requièrent un hôte de build Linux ou OrbStack. Le sysroot OE SDK à /opt/oecore-cortexa7/ reste requis pour la cross-compilation ARM soft-float sur matériel de classe modem.

• Comment évaluer MOS4 sur du matériel Yocto avant de s’engager sur meta-mos ?

  <a href="/fr/contact?topic=yocto-eval">Parlez à l’ingénierie</a>. Le chemin on-target le plus rapide est évalué par programme.

Notes

Sources de la comparaison.

1. Terminologie Yocto Project — bitbake, poky et les couches meta sont les primitives documentées du système de build. mos-distro lit bundle.toml + un workspace Cargo au niveau de la couche applicative. Source : yoctoproject.org; MOS4 depuis /fr/platform/architecture.
2. Couverture d’images de base vérifiée par rapport à la matrice CI mos-distro : les images ARM produites par Yocto, les images basées Debian et les images basées buildroot exécutent chacune un bundle MOS4 installé dans le pipeline par commit.
3. Timing de boot du profil de référence de classe modem (1,6 s jusqu’au premier service applicatif prêt, 28,4 Mo de RSS en régime établi) mesuré sur la carte de référence de classe modem. Méthodologie : boot à froid jusqu’au premier appel de service EventBus réussi.