Embedded Linux
Buildroot für eigene Boards.
Wir passen Buildroot an Ihre Hardware an, integrieren eigene Pakete und bauen daraus einen Prozess, der aus einem Befehl ein fertiges Image macht – heute und in fünf Jahren identisch.
Wenn das Board nicht von der Stange ist.
Auf einem Evaluationsboard läuft Linux in einer Stunde. Auf der eigenen Platine, mit anderem Speicher, anderem PMIC und drei Sensoren am I2C-Bus, sieht es anders aus: Der Bootloader findet das Device Tree nicht, der Treiber gibt es nicht als Paket, und der Build läuft auf dem Rechner des Kollegen durch, auf dem eigenen nicht.
Genau an dieser Stelle arbeiten wir. Nicht an der Frage, ob Linux auf dem Board läuft – sondern daran, dass aus dem lauffähigen Prototyp ein reproduzierbarer Bauprozess wird, den ein ganzes Team benutzen kann.
Buildroot oder Yocto?
| Buildroot | Yocto / OpenEmbedded | |
|---|---|---|
| Grundprinzip | Ein Konfigurationsbaum, ein Image | Layer-System, Rezepte, Paketfeeds |
| Einstieg | In Tagen produktiv, Kconfig wie beim Kernel | Wochen bis Monate Einarbeitung |
| Änderung am System | Meist voller Neubau, dafür vorhersehbar | Inkrementell, dafür komplexer im Zustand |
| Updates im Feld | Image-basiert, gut für A/B-Verfahren | Auch paketweise über eigene Feeds möglich |
| Passt bei | Einem Gerät oder einer Gerätefamilie, kleinem Team | Vielen Produktvarianten, großer Organisation |
| Typische Falle | Anpassungen landen im Buildroot-Baum statt daneben | Layer-Konflikte und Versions-Pinning |
Wir arbeiten schwerpunktmäßig mit Buildroot, weil es für die meisten Geräte schlanker und besser beherrschbar ist. Wo Yocto die bessere Wahl ist, sagen wir das – die Entscheidung fällt vor dem ersten Commit, nicht danach.
Woran wir konkret arbeiten.
Board-Bringup und BSP
Buildroot auf Ihre Platine bringen: Bootloader, Kernel-Konfiguration, Device Tree, Treiber für die Peripherie, die tatsächlich verbaut ist.
- U-Boot-Anpassung und Bootreihenfolge
- Device Tree und Overlays
- Kernel-Patches und Konfigurationsfragmente
- I2C, SPI, CAN, GPIO, Displays
Eigene Pakete integrieren
Ihre Anwendung gehört ins Image, nicht per SCP daraufkopiert. Wir schreiben saubere Buildroot-Pakete mit Abhängigkeiten, Optionen und Init-Integration.
- Config.in und .mk je Paket
- Eigene Anwendungen und Bibliotheken
- Dienste für BusyBox-Init oder systemd
- Konfiguration über rootfs-Overlay
Nahtloser Buildprozess
Ein Befehl, ein Image, jedes Mal dasselbe Ergebnis – auf jedem Rechner und auf dem Buildserver.
- Getrennter BR2_EXTERNAL-Baum
- defconfig je Gerätevariante
- Build im Container, CI-tauglich
- Lokaler Download-Spiegel
Anpassungen gehören neben Buildroot, nicht hinein.
Der häufigste Fehler in gewachsenen Projekten: Das Buildroot-Verzeichnis wurde ausgecheckt und dann darin geändert – ein Paket hier, ein Patch dort, eine Zeile im Makefile. Das funktioniert genau so lange, bis Buildroot aktualisiert werden soll. Dann steht jemand vor einem Merge, den niemand mehr auflösen will.
Wir legen Anpassungen deshalb konsequent in einen eigenen BR2_EXTERNAL-Baum: Ihre Pakete, Ihre Board-Verzeichnisse, Ihre defconfigs, Ihre Overlays – versioniert in Ihrem Repository, sauber getrennt vom Upstream. Ein Buildroot-Update wird damit zu einem Versionswechsel statt zu einem Projekt.
Dazu gehören post-build.sh und post-image.sh für alles, was nach dem eigentlichen Bau passieren muss, und eine genimage-Beschreibung, die aus den Einzelteilen das Partitionsabbild erzeugt – flashbar, ohne dass jemand von Hand etwas zusammensetzt.
Von git clone zum fertigen Image.
1. Bestandsaufnahme
Was läuft heute, wie wird gebaut, wo klemmt es? Häufig existiert bereits ein Image, aber niemand kann es zuverlässig neu erzeugen.
2. Struktur aufsetzen
BR2_EXTERNAL-Baum, Board-Verzeichnis, defconfig je Variante. Ab hier ist nachvollziehbar, woher jede Änderung kommt.
3. Pakete und Anwendung
Ihre Software wird zum Paket mit Abhängigkeiten und Startverhalten – statt zu einer Datei, die jemand nach dem Flashen kopiert.
4. Automatisieren
Build im Container, in der CI, mit gecachten Downloads. Ergebnis ist ein versioniertes Artefakt, kein Ordner auf einem Laptop.
Build läuft nur auf einem Rechner?
In fünf Jahren derselbe Stand.
In der Medizintechnik, im Maschinenbau und überall dort, wo Geräte zehn Jahre im Feld stehen, ist das die eigentliche Anforderung: Ein ausgelieferter Stand muss später identisch reproduzierbar sein – für einen Fehlernachweis, für ein Sicherheitsupdate, für eine Zulassung.
Dazu gehört mehr als ein Git-Tag:
- Feste Versionen für Buildroot, Kernel, Bootloader und jedes eigene Paket – keine schwebenden Branches.
- Eigener Download-Spiegel. Quellarchive verschwinden. Wer sie nicht selbst vorhält, kann einen alten Stand irgendwann nicht mehr bauen.
- Build in einer definierten Umgebung, im Container statt auf dem Entwicklerrechner mit seiner gewachsenen Toolchain.
- Reproduzierbare Ausgabe, damit zwei Durchläufe desselben Standes bitgleich sind – die Grundlage jedes Nachweises.
Updates im Feld, ohne Geräte einzusammeln.
Ein Gerät, das nur über einen Servicetechniker aktualisiert werden kann, wird nicht aktualisiert. Spätestens beim ersten sicherheitsrelevanten Fund ist das ein Problem.
Wir setzen deshalb auf image-basierte Updates mit zwei Systempartitionen: Das neue Image wird auf die inaktive Seite geschrieben, beim nächsten Start davon gebootet – und wenn es nicht sauber hochkommt, fällt das Gerät automatisch auf den alten Stand zurück. Werkzeuge wie RAUC oder SWUpdate lassen sich dabei sauber als Buildroot-Paket integrieren.
Dazu gehört ein schreibgeschütztes Wurzeldateisystem mit getrennter Datenpartition. Das verhindert die häufigste Ursache für Geräte, die nach Jahren nicht mehr starten: ein vollgelaufenes oder beschädigtes Dateisystem.
Lizenzen und Sicherheit nachweisbar machen.
Ein Linux-Image enthält hunderte Komponenten mit unterschiedlichen Lizenzen. Wer ein Gerät in Verkehr bringt, muss dazu Auskunft geben können – bei GPL-Anteilen einschließlich des entsprechenden Quellcodes.
Buildroot bringt dafür eine Auswertung mit, die Lizenzen und Quellarchive des konkreten Images zusammenstellt. Wir bauen diesen Schritt in den automatisierten Prozess ein, sodass zu jedem ausgelieferten Stand ein Lizenznachweis gehört – nicht als einmalige Fleißaufgabe, sondern als Nebenprodukt jedes Builds.
Dasselbe gilt für Schwachstellen: Eine regelmäßige Prüfung der enthaltenen Paketversionen zeigt, wo Handlungsbedarf besteht – bevor es ein Kunde oder ein Auditor tut.
Aus der Praxis.
Für die PHYSIOMED GROUP aus Schnaittach – Hersteller von Geräten für physikalische Therapie und medizinisches Training – haben wir maßgeblich an der Software eines Embedded-Linux-Geräts mitgearbeitet.
Im Vordergrund stand nicht Geschwindigkeit, sondern die Frage, ob ein Stand Jahre später noch identisch baubar ist – in einem sicherheitskritischen Umfeld die entscheidende Eigenschaft. Entstanden ist ein reproduzierbarer Build mit sauberer Trennung von Hardwarezugriff und Anwendungslogik.
Häufige Fragen zu Buildroot und Embedded Linux.
Wir haben schon ein laufendes Image, aber keiner weiß, wie es entstanden ist.
Das ist ein häufiger Ausgangspunkt. Wir rekonstruieren die Konfiguration, überführen sie in einen sauberen BR2_EXTERNAL-Baum und bauen daraus einen dokumentierten Prozess. Danach ist nachvollziehbar, was im Image steckt – und warum.
Welche Architekturen und SoCs unterstützen Sie?
Buildroot deckt ARM, ARM64, x86, RISC-V und weitere ab. Entscheidender als die Architektur ist, wie gut der Hersteller-Support für Kernel und Bootloader gepflegt ist – das sehen wir uns vor der Zusage an.
Buildroot oder Yocto – was empfehlen Sie?
Bei einem Gerät oder einer Gerätefamilie und einem überschaubaren Team in der Regel Buildroot: schneller verstanden, weniger bewegliche Teile. Bei vielen Produktvarianten mit geteilten Komponenten und großem Team spricht mehr für Yocto.
Wie lange dauert ein Board-Bringup?
Bei gut unterstütztem SoC und vorhandenem Referenzdesign oft ein bis drei Wochen bis zum lauffähigen Image. Exotische Peripherie ohne Mainline-Treiber kann deutlich länger dauern – das schätzen wir nach Sichtung des Schaltplans ein.
Können Sie auch unser Team einarbeiten?
Ja, und das ist oft der sinnvollste Weg. Wir setzen die Struktur auf, dokumentieren sie und arbeiten Ihre Entwickler ein – danach können Sie eigenständig weiterarbeiten.
Entwickeln Sie auch die Anwendung auf dem Gerät?
Ja. Hardwarenahe Entwicklung in C und C++ gehört zu unserem Kern – ebenso die Anbindung nach oben, etwa an eine App oder ein Backend.
Sie haben ein Board, einen Schaltplan und einen Termin? Dann lohnt sich ein frühes Gespräch.