Dieser Post ist Teil der Serie über mein privates BeagleBone-Black-Projekt. Der Yocto-Tutorial zeigt unter "Weiterführende Themen" bereits, wie man mit bitbake-layers create-layer ein eigenes Layer anlegt, eine eigene Recipe schreibt und den Kernel per .bbappend samt Device-Tree-Anpassung erweitert. Das reicht für ein Bastelprojekt völlig aus — sobald aber ein echtes Produkt mit mehreren Hardware-Revisionen, mehreren Software-Varianten und einem Team dahinter steht, stößt der Ein-Layer-Ansatz an Grenzen. Dieser Post zeigt die Themen, die dabei typischerweise dazukommen.

Warum ein einzelnes Layer nicht reicht

Ein einzelnes meta-mybbb-Layer vermischt drei Dinge, die eigentlich unabhängig voneinander variieren:

  • Hardware-spezifisches — Pinmux, Device-Tree-Anpassungen, welche Kernel-Treiber gebraucht werden (ändert sich pro Board-Revision)

  • Distributions-Policy — welche Init-Manager, welche C-Bibliothek, welche Sicherheits-Härtung (ändert sich pro Produktlinie, nicht pro Board)

  • Anwendungslogik — die eigentliche Applikation und ihre Abhängigkeiten (ändert sich am häufigsten, unabhängig von Hardware und Distribution)

Die etablierte Yocto-Konvention trennt das in drei Layer-Typen:

Layer-TypInhalt

meta-<produkt>-bsp

Board-Support: Machine-Definitionen, Kernel-`.bbappend`s, Device-Tree

meta-<produkt>-distro

Distro-Policy-Datei (DISTRO_FEATURES, Init-Manager-Wahl, C-Bibliothek)

meta-<produkt>

Anwendungs-Recipes, Image-Definitionen

Diese Dreiteilung lohnt sich nicht für jedes Projekt — für ein einzelnes Board mit einer Firmware-Variante ist das Einzel-Layer aus dem Haupt-Yocto-Tutorial oft die pragmatischere Wahl. Die Trennung zahlt sich aus, sobald mindestens zwei der drei Dimensionen (Hardware, Distro, Anwendung) unabhängig voneinander variieren.

Layer-Prioritäten und -Abhängigkeiten im Detail

conf/layer.conf jedes Layers definiert mehr als nur den Layer-Namen:

BBPATH .= ":${LAYERDIR}"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
            ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "mybbb-bsp"
BBFILE_PATTERN_mybbb-bsp = "^${LAYERDIR}/"
BBFILE_PRIORITY_mybbb-bsp = "8"

LAYERDEPENDS_mybbb-bsp = "core ti-bsp"
LAYERSERIES_COMPAT_mybbb-bsp = "scarthgap"
ParameterBedeutung

BBFILE_PRIORITY

Entscheidet, welches Layer bei kollidierenden .bbappend`s auf dieselbe Recipe "gewinnt" — höhere Zahl = höhere Priorität. Eigene Layer sollten eine höhere Priorität als `meta-ti/meta-beagleboard haben, damit eigene Anpassungen nicht von Upstream-Änderungen überschrieben werden

LAYERDEPENDS

Welche anderen Layer vorhanden sein müssen — bitbake-layers add-layer bricht ab, wenn eine Abhängigkeit fehlt

LAYERSERIES_COMPAT

Für welche Yocto-Release-Codenamen (hier scarthgap) das Layer getestet ist — verhindert stille Inkompatibilitäten bei einem Release-Upgrade

Ein häufiger Fehler: Zwei eigene Layer (z. B. meta-mybbb-bsp und meta-mybbb) mit identischer BBFILE_PRIORITY. Bitbake behandelt die Reihenfolge dann als undefiniert — ein .bbappend, das mal greift und mal nicht, ist ein klassisches Symptom davon. Priorität immer explizit und eindeutig pro Layer vergeben.

PACKAGECONFIG: Recipe-Features an-/abschalten ohne Fork

Viele komplexere Recipes (z. B. für Bibliotheken mit optionalen Abhängigkeiten) definieren PACKAGECONFIG-Flags, über die sich einzelne Build-Features gezielt an- oder abschalten lassen, ohne die Recipe selbst zu verändern:

# in einem eigenen .bbappend, z. B. für eine Bibliothek mit optionalem
# SSL-Support
PACKAGECONFIG:append = " ssl"
PACKAGECONFIG[ssl] = "--with-ssl,--without-ssl,openssl"

Die drei Kommaseparierten Werte in PACKAGECONFIG[<feature>] bedeuten: Konfigurationsflag wenn aktiviert, Konfigurationsflag wenn deaktiviert, zusätzliche Build-Abhängigkeit wenn aktiviert.

PACKAGECONFIG-Flags herauszufinden, die eine Recipe unterstützt, geht am zuverlässigsten über bitbake-layers show-recipes <name> gefolgt von einem Blick in die .bb-Datei selbst — nicht jede Recipe dokumentiert ihre Flags an einer zentralen Stelle.

bblayers.conf: Reihenfolge-Fallstricke

bblayers.conf listet alle aktiven Layer in BBLAYERS. Zwei Punkte, die in der Praxis regelmäßig für Verwirrung sorgen:

  • Die Reihenfolge in BBLAYERS selbst hat keinen Einfluss auf Recipe-Priorität — das steuert ausschließlich BBFILE_PRIORITY in layer.conf (siehe oben). Viele Entwickler versuchen zuerst, Probleme über die Reihenfolge in bblayers.conf zu lösen — das führt nirgendwohin

  • Ein Layer, das in bblayers.conf steht, aber dessen LAYERDEPENDS nicht erfüllt sind, lässt den Bitbake-Start mit einer klaren Fehlermeldung abbrechen — im Gegensatz zu stillen Priority-Konflikten ein eher harmloser Fehlerfall

Rebuild-Zeiten im Griff behalten

Yocto-Builds sind lang — welcher Clean-Befehl wie viel verwirft, entscheidet über Minuten oder Stunden:

BefehlWirkung

bitbake -c clean <recipe>

Löscht nur die Arbeitsverzeichnisse dieser Recipe, shared state bleibt erhalten — schnellster Rebuild

bitbake -c cleansstate <recipe>

Löscht zusätzlich die Shared-State-Cache-Einträge dieser Recipe — nötig, wenn sich am Task-Hash nichts ändert, aber z. B. eine lokale Patch-Datei außerhalb des Hash-Systems verändert wurde

bitbake -c cleanall <recipe>

Löscht zusätzlich heruntergeladene Quellen — nur nötig, wenn der Source-Download selbst korrupt war

cleansstate bzw. cleanall auf einer zentralen Recipe wie virtual/kernel oder core-image-minimal anzuwenden, reißt einen Großteil des Shared-State-Caches für alles, was davon abhängt, wieder ein — der nächste Build dauert dann wieder wie beim allerersten Mal. Gezielt auf die tatsächlich betroffene Recipe anwenden, nicht pauschal auf das Image.

Zusammenfassung

AspektKernaussage

Mehrschichtige BSP-Struktur

Lohnt sich, sobald Hardware, Distro-Policy und Anwendung unabhängig voneinander variieren — sonst reicht ein Layer

Layer-Priorität

Steuert .bbappend-Konflikte, nicht die Reihenfolge in bblayers.conf — explizit und eindeutig vergeben

PACKAGECONFIG

Erlaubt Feature-Umschaltung ohne Recipe-Fork

Rebuild-Zeit

clean vor cleansstate vor cleanall — je gezielter, desto schneller der nächste Build