Yocto oder Buildroot: das richtige Build-System für Embedded Linux

Kurz gesagt: Buildroot und das Yocto Project bauen beide ein maßgeschneidertes Linux aus dem Quelltext – sie beantworten aber unterschiedliche Fragen. Buildroot ist auf Einfachheit und Tempo optimiert: ein Kconfig-Baum, make, ein schlankes Image, das man an einem Nachmittag durchdringt. Yocto ist auf Flexibilität und Skalierung optimiert: Layer, Rezepte, Paketverwaltung auf dem Gerät, ein passendes SDK und Wiederverwendung über eine ganze Produktlinie. Die richtige Wahl ergibt sich aus Produktlebensdauer, Team, Update-Strategie und Compliance-Pflichten – nicht daraus, welches Werkzeug „besser“ ist.

Was beide Build-Systeme leisten

Beide Werkzeuge lösen dasselbe Kernproblem: Sie machen aus Bootloader, Kernel, C-Bibliothek und einer handverlesenen Menge an User-Space-Paketen ein bootfähiges, zugeschnittenes Image, cross-kompiliert für ein konkretes Board. Keines ist eine Distribution zum Installieren. Beide sind Frameworks, die eine Distribution aus dem Quelltext bauen, sodass nur die Komponenten im Root-Dateisystem landen, die Sie ausdrücklich anfordern. Genau das unterscheidet sie davon, eine General-Purpose-Distribution oder ein Vendor-Image auf ein Gerät zu spielen – ein Ansatz, den wir auf unserer Seite zu Embedded Linux ausführlich gegenüberstellen.

Sie unterscheiden sich in der Philosophie. Buildroot betrachtet das Image als Ergebnis einer einzigen, in sich geschlossenen Konfiguration. Yocto betrachtet das Image als ein Produkt eines geschichteten, kombinierbaren Metadaten-Systems, das viele Geräte speisen kann. Diesen Unterschied zu verstehen ist nützlicher als jede Feature-Liste, denn er erklärt sämtliche Abwägungen, die daraus folgen.

Der Buildroot-Ansatz

Buildroot ist bewusst klein gehalten. Die Konfiguration läuft über Kconfig – dieselbe menuconfig-Oberfläche, die auch der Linux-Kernel nutzt – und der Build wird von schlichtem GNU make getrieben. Sie wählen Architektur, Toolchain, Kernel und die benötigten Pakete; Buildroot lädt sie herunter, cross-kompiliert sie und fügt sie zu einem Root-Dateisystem zusammen. Das gesamte Denkmodell passt in einen Kopf, und ein Einsteiger erzeugt binnen eines Tages ein bootfähiges Image.

Diese Einfachheit hat Folgen. Standardmäßig gibt es auf dem Zielsystem keine Paketverwaltung: Das Image ist ein festes, meist schreibgeschütztes Artefakt, das als Ganzes aktualisiert wird statt Paket für Paket. Die Konfiguration liegt in einer einzelnen, flachen defconfig-Datei – gut lesbar, aber ohne Duplizierung schwer über mehrere Boards zu teilen. Und da Buildroot keinen Cache je Paket wie Yoctos Shared State besitzt, bedeutet eine geänderte Konfiguration oft einen sauberen, vollständigen Neubau. Wächst der Anpassungsbedarf doch, bietet Buildroot mit BR2_EXTERNAL externe Bäume, die eigene Pakete, Board-Konfigurationen und defconfigs außerhalb des Haupt-Baums halten – ein pragmatisches Ventil, aber weit entfernt von Yoctos Schichtenmodell. Für ein klar umrissenes Einzelgerät mit stabilem Funktionsumfang ist all das kein Nachteil – sondern der Sinn der Sache.

Der Yocto-Ansatz

Yocto dreht die Prioritäten um: Flexibilität und Wiederverwendung zuerst, Einfachheit danach. Die Build-Engine BitBake führt Rezepte (.bb-Dateien) aus, die beschreiben, wie jede Komponente bezogen, gepatcht, konfiguriert, übersetzt und paketiert wird. Rezepte sind in Layern gruppiert – eigenständige, versionierte Metadaten-Repositorys, die aufeinander gestapelt werden. Board-Support, Distributions-Politik und die eigenen Anwendungen liegen jeweils in einem eigenen Layer, sodass ein neues Produkt oft nur eine Neukombination vorhandener Layer bedeutet statt eines Neuanfangs.

Diese Struktur erschließt genau die Funktionen, die langlebige Produkte brauchen. Yocto kann Paket-Feeds für das Gerät bauen (rpm, ipk oder deb), ein passendes Cross-SDK für die Anwendungsteams erzeugen und eine SBOM im SPDX-Format samt Lizenz- und CVE-Werkzeugen mitliefern. Der Shared-State-Cache vermeidet den Neubau unveränderter Komponenten und bändigt so die sonst hohen Build-Zeiten. In der Praxis beginnt man selten bei null: Das BSP des SoC-Herstellers kommt als eigener Layer (etwa meta-freescale, meta-ti oder meta-st), Community-Layer wie meta-openembedded liefern Tausende weiterer Rezepte, und Ihr Produkt-Layer sitzt sauber obenauf. Der Preis ist eine steilere Lernkurve – für skalierende Produktlinien zahlt sie sich aus. Vertieft haben wir das in unserer Arbeit an Yocto-BSPs und in unserem Beitrag zu den Vorteilen von Yocto im industriellen Umfeld.

Ein konkreter Blick: defconfig gegen Layer-Gerüst

Am deutlichsten wird der Kontrast in den Artefakten, die jedes Werkzeug von Ihnen verlangt. Buildroot dreht sich um eine einzige, flache Konfigurationsdatei:

# configs/mydevice_defconfig — eine in sich geschlossene Buildroot-Konfiguration
BR2_aarch64=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_DEFCONFIG="myboard"
BR2_TARGET_ROOTFS_EXT4=y
BR2_PACKAGE_DROPBEAR=y

Yocto verteilt dieselbe Absicht auf einen Layer aus strukturierten Metadaten – ein Verzeichnis aus Rezepten statt einer einzelnen Datei:

meta-mydevice/
├── conf/layer.conf
├── recipes-core/images/mydevice-image.bb
└── recipes-apps/hello/
    ├── hello_1.0.bb
    └── files/hello.c

# recipes-apps/hello/hello_1.0.bb — ein minimales Yocto-Rezept
SUMMARY = "Minimale Beispielanwendung"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://hello.c"

do_compile() {
    ${CC} ${CFLAGS} ${LDFLAGS} hello.c -o hello
}

do_install() {
    install -d ${D}${bindir}
    install -m 0755 hello ${D}${bindir}
}

Keines ist per se besser. Die defconfig ist schneller geschrieben und gelesen; der Layer ist ausführlicher, dafür kombinierbar, versionierbar und über Produkte hinweg wiederverwendbar.

Direkter Vergleich

Kriterium	Buildroot	Yocto Project
Lernkurve	Niedrig – Kconfig + make	Hoch – BitBake, Layer, Rezepte
Erstes bootfähiges Image	Stunden	Tage
Build-Tempo / Neubauten	Schnell, aber oft Vollbau	Schwerer Erstbau, schnell via sstate
Flexibilität	Gut innerhalb eines Images	Sehr hoch, geschichtet und kombinierbar
Paketverwaltung auf dem Gerät	Standardmäßig keine	Optional (rpm/ipk/deb)
Lizenz- & SBOM-Werkzeuge	Grundlegend (make legal-info)	Integriert (SPDX, cve-check)
Langzeitpflege	Quartalsreleases, jährliches LTS, mehr selbst zu tragen	Mehrjährige LTS-Zweige mit rückportierten Fixes
Passt zur Teamgröße	Kleine Teams, Einzelprodukt	Größere Teams, Produktlinien
Wiederverwendung über Produkte	Begrenzt (defconfig kopieren)	Nativ (Layer neu kombinieren)

Wie Sie entscheiden

Vier Fragen klären die meisten Fälle. Produktlebensdauer: Ein Gerät, das über viele Jahre gepflegt wird, mit wiederkehrenden Sicherheitsupdates und Nachweispflichten, neigt zu Yocto; eine Einheit mit fester Funktion und kurzer, stabiler Lebensdauer ist mit Buildroot gut bedient. Team-Situation: Ein kleines Team, das ein Gerät ausliefert, profitiert von Buildroots geringem Overhead, während mehrere Teams, die Board-Support und Anwendungen über Produkte hinweg teilen, Yoctos Layer brauchen. Update-Strategie: Wer A/B-Image-Updates mit Werkzeugen wie RAUC oder Mender ausrollt, ist mit beiden gut aufgestellt, doch Paket-Feeds auf dem Gerät und gestufte Rollouts sprechen für Yocto. Lizenzierung und Compliance: Pflichten wie der EU Cyber Resilience Act drängen zu Yoctos integrierter SBOM- und CVE-Werkzeugkette. (Das ist eine allgemeine technische Einordnung und keine Rechtsberatung – klären Sie die für Ihr Produkt geltenden Anforderungen und etwaige Fristen mit fachkundiger Beratung.) Ziehen diese Fragen in verschiedene Richtungen, gibt der Punkt den Ausschlag, der Ihr Risiko dominiert – und ein Blick von außen verkürzt diese Entscheidung oft.

Klein anfangen, in Yocto hineinwachsen

Die beiden Systeme schließen sich nicht aus, und die Wahl ist nicht unumkehrbar. Buildroot eignet sich hervorragend, um ein neues Board schnell in Betrieb zu nehmen und die Hardware zu validieren, bevor die Produktarchitektur feststeht. Die Kernel-Konfiguration, der Device Tree und die Bootloader-Arbeit, die dabei entstehen, gehen direkt in ein späteres Yocto-Setup über – nur die Paketierungs-Metadaten werden als Layer und Rezepte neu aufgebaut. Viele Teams gehen genau diesen Weg: erst ein Prototyp auf Buildroot, dann die Migration zu Yocto, sobald aus einem Produkt eine Produktlinie wird. Wer diesen Übergang plant, bevor die Codebasis wächst, hält ihn günstig. Beide Build-Systeme behandeln wir in unseren Schulungen, und unser Portfolio zeigt, wo jeweils die richtige Wahl lag.

Fazit

Buildroot und Yocto sind weniger Konkurrenten als Antworten auf verschiedene Fragen. Buildroot belohnt Sie mit Tempo und Einfachheit, solange der Umfang überschaubar bleibt; Yocto belohnt Sie mit Flexibilität, Wiederverwendung und Compliance-Werkzeugen, wenn das Produkt skalieren und lange halten muss. Richten Sie das Werkzeug an Produktlebensdauer, Team und Pflichten aus, dann wird die Entscheidung klar statt ideologisch. Wenn Sie eine zweite Meinung zum passenden Build-System für Ihr Gerät möchten, nehmen Sie Kontakt mit uns auf.