Yocto para el bring-up del chip. MOS4 para la superficie de aplicación.

Frontera de capa

Yocto construye. MOS4 ejecuta.

flowchart TB
  subgraph App["MOS4 — capa de runtime de aplicación"]
    M1[Micro servicios · supervisor · OTA por servicio · observabilidad]
  end
  subgraph Img["Imagen Linux (producida por Yocto)"]
    L1[Kernel · userland · systemd]
  end
  subgraph Y["Sistema de build Yocto"]
    Y1[bitbake · poky · capas meta-* · BSPs]
  end
  Y1 -->|produce| L1
  L1 -->|ejecuta| M1

mos-distro lee un manifiesto bundle.toml y un workspace Cargo, y genera un bundle autónomo — binario monolítico, configuración, archivos de datos — instalado sobre la imagen producida por Yocto. No reemplaza a bitbake, poky ni las capas meta.¹

Imágenes base

Yocto, Debian y buildroot — todos soportados.

cargo distro genera bundles que se instalan sobre imágenes producidas por Yocto, basadas en Debian y basadas en buildroot. MOS4 no reemplaza la pipeline de build de imagen existente. Yocto es la ruta de producción más habitual; Debian y buildroot son alternativas confirmadas.²

FAQ

Las preguntas que más oímos.

• ¿MOS4 reemplaza a Yocto, bitbake o las capas meta?

  No. MOS4 es la capa de runtime de aplicación que corre sobre la imagen que Yocto produjo. Yocto produce el kernel y el userland; MOS4 añade el supervisor de servicios, IPC tipado, OTA, observabilidad y micro services de dominio vehicular sobre esa base. Son complementarios.

• ¿Existe una capa meta-mos?

  Sí — Munic mantiene una meta-capa que integra los micro services MOS4 en la capa Yocto correcta, compatible con las capas BSP y de distro existentes. El acceso está sujeto a un acuerdo de evaluación. <a href="/es/contact?topic=yocto-eval">Hable con ingeniería</a>.

• ¿MOS4 reemplaza a systemd?

  No. systemd arranca la plataforma; MOS4 corre como una unidad systemd (instalada en /mnt/user/start.sh, activada en runlevel 5) y supervisa los micro services de aplicación por encima. Los dos coexisten.

• ¿Puedo actualizar micro services sin reflashear la imagen?

  Sí — mos-update ejecuta OTA delta por micro service: descarga, verificación SHA-256, validación Ed25519, aplicación delta, commit en partición A/B, rollback automático vía bootcount. Las actualizaciones de imagen completa al estilo Yocto siguen disponibles para cambios de kernel y de imagen base.

• ¿Qué entornos de build se soportan para compilación cruzada?

  Se soportan imágenes basadas en Yocto, Debian y buildroot. En macOS, OrbStack se encarga de la compilación cruzada clase módem; otros objetivos requieren un host Linux o OrbStack. El sysroot del OE SDK en /opt/oecore-cortexa7/ sigue siendo necesario para la compilación cruzada ARM soft-float en hardware clase módem.

• ¿Cómo evalúo MOS4 sobre hardware Yocto antes de comprometerme con meta-mos?

  <a href="/es/contact?topic=yocto-eval">Hable con ingeniería</a>. La ruta on-target más rápida se evalúa por programa.

Notas al pie

Fuentes de la comparación.

1. Terminología del Yocto Project — bitbake, poky y las capas meta son las primitivas documentadas del sistema de build. mos-distro lee bundle.toml + un workspace Cargo a nivel de capa de aplicación. Fuente: yoctoproject.org; MOS4 desde /es/platform/architecture.
2. Cobertura de imagen base verificada contra la matriz CI de mos-distro: imágenes ARM producidas por Yocto, imágenes basadas en Debian e imágenes basadas en buildroot ejecutan cada una un bundle MOS4 instalado en la pipeline por commit.
3. Temporización de arranque del perfil de referencia clase módem (1,6 s hasta primera aplicación lista, 28,4 MB de RSS estacionario) medida sobre la placa de referencia clase módem. Metodología: arranque en frío hasta la primera llamada de servicio EventBus exitosa.