Si et dediques als embeguts oa l'IoT, tard o d'hora et creues amb Yocto Project. És la base sobre la qual milers d'equips construeixen la seva pròpia distribució Linux, ajustada al mil·límetre per al maquinari i els seus requisits. No és una distro més, sinó un conjunt d'eines, metadades i processos que porten la personalització i la reproductibilitat a un altre nivell.
En aquesta guia entendres, sense embuts, què és i què no és Yocto, per què està tan estès, com es compon (OpenEmbedded, BitBake i Poky), en què consisteix el Model de Capes, quines eines orbiten al voltant (Toaster, CROPS, eSDK…), com es construeix realment una imatge, quines opcions d'actualització hi ha, què ofereix en seguretat i com es governa i versiona el projecte. A més, veuràs conceptes i exemples pràctics (reTerminal/Raspberry Pi) que t'ajudaran a aterrar-lo al teu dia a dia.
Què és el Projecte Yocto
Yocto Project és una iniciativa col·laborativa afavorida per la Linux Foundation que proporciona les peces per crear distribucions Linux personalitzades per a dispositius embeguts i de IoT, independentment de l'arquitectura de maquinari. Va néixer el 2010 i va alliberar el primer llançament el 2011 amb l'impuls d'unes dues desenes d'organitzacions i una estreta col·laboració amb OpenEmbedded.
La seva raó de ser és millorar el cicle de vida del programari embegut: ofereix eines interoperables, metadades i fluxos de treball perquè muntar un sistema sigui ràpid, repetible i completament personalitzable. La combinació Yocto + OpenEmbedded + BitBake permet descriure com obtenir, configurar, compilar, empaquetar i acoblar el sistema amb precisió quirúrgica.
El 2018, ARM i Intel van compartir esforços dins de Yocto per facilitar l'intercanvi de codi en embeguts, reforçant la neutralitat de la plataforma i el seu suport multiarquitectura. Avui, el projecte es fa servir en dispositius que van de plaques modestes a productes industrials complexos.
Yocto no et amaga: és agnòstic de proveïdors i formats de paquet, de manera que pots apostar per deb, rpm o ipk i seguir un model de build determinista. A més d'imatges per al dispositiu, podeu generar toolchains i SDKs a mida per al desenvolupament d'aplicacions i depuració.
Per què fer servir Yocto en embeguts
La gran carta és la personalització. Amb Yocto crees un sistema operatiu amb el que és just: elimines el que no necessites, reduïx superfície d'atac i pes, i ajustes rendiment i consum. No depens de decisions d¿una distro generalista.
Una altra raó de pes és la reproductibilitat. Tot (capes, receptes, configuracions) es pot versionar en repositoris, cosa que permet construir la mateixa imatge en diferents entorns i moments. Això encaixa amb CI/CD i aporta traçabilitat per a QA i compliance.
També en destaca la flexibilitat: suporta arquitectures com Arm, x86/x86-64, MIPS o PowerPC, i facilita reciclar la teva distribució entre famílies de productes o pivotar quan canvies de placa o SoC.
La comunitat i el suport industrial garanteixen actualitzacions i pegats de seguretat de manera sostinguda. Hi ha branques amb suport estès (LTS) que simplifiquen la vida de producte i manteniment a camp.
El peatge? Requereix màquina potent i corba daprenentatge. Per a projectes molt petits o amb terminis ultracurts, pot resultar excessiu en comparació amb alternatives lleugeres, però a mitjà termini compensa quan levolució i el manteniment importen.
Components clau: OpenEmbedded, BitBake i Poky
El cor del build és BitBake: un motor que interpreta receptes i variables de configuració, resol dependències i executa tasques en ordre (descarregar, desempaquetar, configurar, compilar, instal·lar, empaquetar, acoblar imatges). Pensa en BitBake com un orquestrador estil “make” però dissenyat per al món dels embeguts.
OpenEmbedded (OE) aporta la base de metadades i classes (OpenEmbedded-Core o oe-core), un conjunt curat de receptes i utilitats provat de forma contínua que serveix de fonament per a centenars de capes i projectes.
Poky és la distribució de referència de Yocto: integra el sistema de build d'OE, un ampli set de receptes i una configuració vàlida de llibre per arrencar. No és una distro de producte, sinó un punt de partida didàctic i funcional que valida l'ecosistema.
Model de Capes: col·laboració i personalització alhora
El Layer Model és la pedra angular. Una capa és un dipòsit amb receptes, configuracions i classes relacionades. Les capes s'apilen i es poden sobreescriure jeràrquicament, el que permet heretar allò comú i aplicar canvis sense trencar el base.
Aquest enfocament promou separar lògicament el que fas: una capa BSP del fabricant, una altra de GUI, una altra de middleware, una altra de la teva aplicació, una altra de la distro… Evitar ficar-ho tot en una sola capa et facilita la vida a l'hora d'actualitzar, mantenir i reutilitzar components entre projectes.
Les capes BSP són crítiques: contenen device trees, configuracions del kernel, drivers i ajustaments de màquina per a targets concrets (per exemple, famílies Raspberry Pi). Gràcies a elles, sumar o canviar maquinari no implica reescriure-ho tot, només afegir o adaptar la capa adequada.
Flux de treball de construcció
El procés típic és molt clar, tot i que intens. Primer defineixes arquitectura, polítiques, pegats i paràmetres (per exemple a local.conf y bblayers.conf). BitBake obté les fonts (tarballs, git…), aplica pegats, configura i compila segons les classes (autotools, cmake, etc.).
El resultat intermedi s'instal·la a un staging temporal i s'empaqueta en el format triat (deb, rpm, ipk). Amb aquests paquets es compon el rootfs i es generen les imatges finals que flashejaràs o desplegaràs al dispositiu.
Durant tot el camí s'executen sanity checks, regressions i QA; a més, pots arrencar i validar imatges a QEMU. Això redueix el cicle prova–error en maquinari real, sobretot en etapes primerenques.
Eines i subprojectes al voltant de Yocto
L'ecosistema porta utilitats que faciliten la vida. CROPS és un framework de contenidors que dóna entorns de build coherents a Linux, Windows i macOS; ideal per a equips mixtos o per encapsular dependències. Toaster és una interfície web per configurar i llançar compilacions i veure mètriques i artefactes.
L'eSDK (Extensible SDK) permet a desenvolupadors d'aplicació afegir llibreries i canvis i realimentar-los a la imatge de manera còmoda. També hi ha suport Multi-Config per construir múltiples arquitectures amb una sola ordre i “binary builds” per incloure binaris quan no hi ha fonts.
El sistema pot generar un manifest de llicències i referències al codi utilitzat, clau per compliance en entorns regulats o amb obligacions de copyleft.
Altres projectes sota el paraigua inclouen utilitats com pseudo, cross-prelink, la suite Matchbox per a entorns gràfics lleugers, i més. Antigament va existir una integració amb Eclipse que es va retirar a partir de la versió 2.7 en quedar obsoleta davant de noves eines.
Gestió de paquets i estratègies d'actualització
Actualitzar dispositius de camp és vital i Yocto ofereix diversos camins. Pots optar per actualitzar la imatge completa (consistència total del sistema), distribuir canvis a nivell de paquets per estalviar ample de banda, emprar models atòmics amb reversió (com OSTree) o recórrer a deltes per minimitzar transferències.
No hi ha bala de plata: imatge completa serveix per a “grans salts”, paquets per a canvis granulars, atòmic per a entorns crítics amb rollback i deltes per a xarxes estretes. L'avantatge és que tries l'estratègia que encaixa amb el teu producte i la teva operació.
Proves, emulació i documentació
Iocte cuida la qualitat. Incorpora sanity i regression tests, suport d'arrencada i proves a QEMU i possibilitat d'integrar test suites. Això estreta el cicle de validació i redueix sorpreses en maquinari.
La documentació és un pilar del projecte. Cada versió publica guies actualitzades i es conserven docs de versions vigents i arxivades, una cosa molt necessària perquè el comportament pot canviar entre llançaments.
Governança i llançaments
La direcció tècnica recau en l'arquitecte del projecte (Richard Purdie) i una jerarquia de mantenidors per component, en un model similar al del nucli Linux. A la pota administrativa hi ha un Consell Assessor amb representants de membres (fabricants de silici, vendors comercials basats en Yocto, usuaris corporatius i consultors), a més de grups de treball per a finances, infra, promoció i comunitat.
El calendari de releases és semestral (abril i octubre), amb versions puntuals per a les tres darreres branques. Això marca un ritme predictible que les empreses poden planificar per actualitzar capes i productes.
Versions i noms en clau
Històricament, Yocto ha publicat llançaments identificats per número i sobrenom. A continuació, una selecció representativa de versions i dates:
| versió | Nom en clau | Data |
|---|---|---|
| 3.3 | Hardknott | 04/2021 |
| 3.2 | Gatesgarth | 11/2020 |
| 3.1 | Dunfell | 04/2020 |
| 3.0 | Zeus | 10/2019 |
| 2.7 | Guerrero | 04/2019 |
| 2.6 | Batega | 11/2018 |
| 2.5 | Summe | 04/2018 |
| 2.4 | Rocko | 10/2017 |
| 2.3 | Pyro | 04/2017 |
| 2.2 | Morty | 10/2016 |
| 2.1 | Krogoth | 04/2016 |
| 2.0 | Jethro | 10/2015 |
| 1.8 | Fido | 04/2015 |
| 1.7 | Marejat | 10/2014 |
| 1.6 | Margarita | 04/2014 |
| 1.5 | ra | 10/2013 |
| 1.4 | Dylan | 04/2013 |
| 1.3 | Dylan | 10/2012 |
| 1.2 | Denzil | 04/2012 |
| 1.1 | Edison | 10/2011 |
| 1.0 | Bernardo | 2011 |
| 0.9 | Els líquens | 2010 |
A més de les imatges genèriques, el projecte manté una implementació de referència anomenada Poky que integra el build system OE i un conjunt ampli de receptes organitzades en capes, útil com a plantilla funcional per a un sistema embegut.
Programa de Marca: participants i compatibilitat
El Programa de Marca de Yocto permet a organitzacions i productes associar la seva feina al projecte amb dos segells: “Participant del Projecte Yocto” per a entitats que usen i donen suport Yocto públicament, i “Compatible amb el Projecte Yocto” per a productes, BSPs i capes compatibles amb OE pertanyents a organitzacions membres.
Glossari essencial
- Fitxers de configuració (conf): defineixen variables globals, opcions de l'usuari i ajustaments de maquinari; guien què es compila i què entra a la imatge per a una plataforma concreta.
- Receptes (.bb): descriuen origen del codi, pegats, dependències i opcions de build per generar paquets i, amb ells, la imatge final.
- Capes (layers): col·leccions de receptes i metadades relacionades; permeten aïllar personalitzacions i suportar múltiples arquitectures de manera neta.
- metadades: abasten receptes, configuracions, classes i dades que controlen què es construeix i com, incloent referències de versions i pegats.
- bitbake: motor d'execució que analitza receptes i configura l'ordre de tasques; similar a “make”, però orientat a paquets i imatges.
- paquets: artefactes generats (deb, rpm, ipk) que s'utilitzen per muntar el rootfs i imatges del sistema.
- eSDK: un SDK extensible perquè els desenvolupadors d'aplicació integrin canvis i biblioteques i els provin en maquinari destí.
- Imatge: forma binària del sistema operatiu Linux a flashejar o desplegar al dispositiu objectiu.
Casos d'ús, IoT i elecció del sistema
El mercat embegut viu un creixement constant: més dispositius personalitzats, més varietat de plaques i SoCs i, per tant, més necessitat de sistemes OS a mida. Linux s'ha consolidat com a estàndard de facto i Yocto encaixa com a guant per construir-lo “a la teva manera”.
Davant d'una distribució binària generalista com Debian/Ubuntu, Yocto aporta control absolut sobre el que s'instal·la, versions i pegats, amb reproductibilitat i traçabilitat. Per a productes que exigeixen footprint acotat, seguretat i manteniment a llarg termini, és una decisió pragmàtica.
Empreses combinen Yocto amb arquitectures modernes d'operació a camp (OTA, particions segures, rollback), integrant pipelins de CI/CD, tests automàtics i desplegaments graduals. Fins i tot hi ha solucions que es recolzen a Yocto per ampliar capacitats a la vora (per exemple, plataformes centrades en analítica, IA i connectivitat cloud compatible amb Yocto).
Seguretat i bones pràctiques
La seguretat és prioritària. El projecte està alineat amb CII Best Practices i promou builds reproduïbles (en proves s'ha arribat a ~99,8% en core-image-minimal). Controlar dependències, entorns i toolchains redueix la “contaminació” del build.
En el pla del runtime, podeu habilitar SELinux per a control d'accés detallat, IMA per a mesurament d'integritat en temps d'execució i cadenes d'arrencada segures que verifiquen bootloader, kernel i initramfs. El xifratge de sistemes de fitxers i la gestió de claus completen la protecció en repòs.
De la teoria a la pràctica: construir una imatge
El camí més bàsic és clonar Poky, inicialitzar l'entorn, seleccionar la màquina (per exemple, un target QEMU o una Raspberry Pi), afegir les capes BSP necessàries i llançar BitBake contra una imatge de referència. La primera compilació triga, però després els incrementals volen.
Per a maquinari com Raspberry Pi/reTerminal, el flux típic inclou clonar capes com meta-raspberrypi, meta-oe, meta-python o una capa del proveïdor del dispositiu, ajustar el nucli, importar capes i variables i construir una imatge específica (per exemple, una “rpi-test-image”).
Toaster permet fer el mateix per GUI: crear un projecte, triar release, màquina (raspberrypi4-64, raspberrypi5…), importar capes, ajustar variables (per exemple, backends gràfics) i llançar el build des del navegador. En acabar, descarregues els artefactes (per exemple, un .wic.bz2) i flaixes.
BitBake ofereix ordres útils per llistar capes i receptes, explorar dependències, obrir un devshell per a un paquet, inspeccionar tasques o netejar l'entorn per recompilar. Això accelera el diagnòstic quan alguna cosa falla.
Workflow detallat (resum operatiu)
- Defineix arquitectura, polítiques, pegats i configuració.
- Descarrega fonts des dels orígens declarats.
- Desempaqueta, aplica pegats i executa configure/compile segons correspongui.
- Instal·la en staging i empaqueta.
- Executa QA i checks.
- Publica feeds de paquets.
- Genera la imatge final.
Aquest esquema s'adapta amb classes i capes segons els teus components: potser voldreu un backend gràfic concret, mòduls de kernel propis, o un init diferent. La gràcia de Yocto és que tot això s'expressa com a metadades versionables.
Consells d'adopció en equips
Per a perfils vinguts dentorns Windows, invertir en fonaments de Unix/Linux ajuda moltíssim. Treballar amb una distro Linux a l'estació de treball, entendre Bash i Python i familiaritzar-te amb toolchains creuades accelera la corba.
Si no tens experiència, comença amb Poky i QEMU per validar el flux end-to-end. Després afegeix la capa BSP del maquinari real i la teva pròpia capa per a l'aplicació. Automatitza builds amb contenidors (CROPS) i CI/CD des del principi.
Capacitats d'actualització i operació al camp
Quan el producte surt de fàbrica, necessiteu una estratègia d'updates. Amb Yocto pots optar per repositoris de paquets, imatges completes signades, esquemes atòmics amb rollback o deltes. Trieu en funció de la mida de l'actualització, l'amplada de banda i el risc que vols assumir.
Integrar inventari de llicències i codi font associat és un altre de bàsic per a compliment. Yocto genera manifests de llicències i pot enllaçar al codi dels components, facilitant auditories i obligacions de redistribució.
