CIW137 - Yocto
GNU/Linux.ch
00:00
BitBake-Parallelität und Build-Verhalten
Erläuterung, wie BitBake Kerne nutzt, Builds fortsetzt und abbricht, ohne alles neu starten zu müssen.
Play episode from 31:30
Transcript
Transcript
Episode notes
CIW - Folge 137 - 28.05.2025 - Yocto
- Wir begrüssen alle Distrobauer zur Folge 137 von "Captain it's Wednesday", dem Podcast über Freie Software und Freie Gesellschaft, aufgenommen am 27. Mai von Götz, Christian und Ralf Hersel. Heute sprechen wir darüber, wie man seine eigene Distribution für eingebettete Systeme baut.
Hausmitteilungen
- Wir bedanken uns für eure Spenden bei: Michael, Engelbert, Soeren, Andris, Folker, Ingmar, Volker, Edmund, Florian, Michel, Stefan, Torsten, Katrina, Rolf, Marco und allen unbekannten Spender:innen, die uns über Liberapay und Twint unterstützt haben.
- Wir ziehen den Hut vor allen Spender:innen, die mit einem kleinen oder grossen Betrag unser Community-Projekt unterstützen. Wer wenig Geld hat, kann das Projekt jederzeit durch Mitarbeit in Form von Artikeln oder Mit-Podcasten unterstützen. Uns geht es nicht um das Geld, sondern um die Zusammenarbeit der Community.
Thema: Yocto
- Was ist das Yocto Project?
- Erzeuge dir deine eigene Distro basierend auf den Anforderungen deines Softwareprojekts für IoT mit Embedded Linux
- Steht unter der Schirmherrschaft der Linux Foundation
- Hat eine technische und administrative Leitstelle. In letzterem sind viele Chiphersteller versammelt.
- Releases alle 6 Monate (April und Oktober) und alle zwei Jahre eine LTS Version mit 4 Jahren Support.
- LTS: Scarthgap (5.0)
- Walnascar (5.2)
- Unterschiede zu anderen Buildsystemen (z. B. Buildroot)
- Buildroot ist eine Sammlung aus Bash Skripten
- Keine gute Trennung zwischen Userland Software und Board-Support-Package
- Kein Dependency-Management und Trennung der Buildsysteme
- Aufbau und Komponenten: BitBake, Poky, Layer-Konzept
- Jedes Programm wird in einem Recipe (Meta-Sprache für Bitbake, stark an Python angelehnt) beschrieben.
- Recipes werden in Layer gruppiert
- Großes Basislayer: OpenEmbedded hat tausende Recipes und viele SubLayer mit weiteren Compilern (Go, Rust, Clang, ...) oder Bildschirmumgebungen (Gnome, KDE, ...)
- Recipes aus anderen Layern können erweitert oder komplett überlagert werden
- Poky: Standardprojekt für die "eigene" Distro: Template und Grundlage für alles
- BitBake: Parst jedes Recipe und führt die darin enthaltenen Anweisungen aus
- BSP: Board Support Package: Enthält die Sourcen zu Kernelmodulen, speziellem Linux Kernel Sourcen, speziellen Compilern, plattformspezifische Bibliotheken, ...
- Tipps für den Einstieg: Erste eigene Builds, Layer auswählen und konfigurieren
- Sucht euch ein Projekt mit Vorlage, am besten eines, was aktiv gemanagt wird
- Lest die Dokumentation von Yocto (denn sie ist sehr gut)
- Arbeitet mit einer Hardware für die es ein BSP gibt:
- macht nicht den gleichen Fehler wie ich: Nehmt das BSP für x86 Rechner
- Realisiert kleine Projekte und haltet euch von den großen fern (e.g. OpenBMC)
- Mein erster Versuch: Nach dem Booten automatisch ins W-LAN einloggen
- Best Practices für Wartbarkeit und Skalierung
- Ändert nicht zu viel an den Layern die ihr verwendet.
- Ändert nur etwas am BSP/Kernel/Firmware, wenn ihr bei Versionsupgrades viele Anpassungen machen wollt.
- Baut euch eine Build-Pipeline und wartet diese mit jedem Versionsupgrade
- Typische Stolperfallen – und wie man sie vermeidet
- Nutzt keine der zusätzlichen Tools, die euch die Verwaltung vermeintlich erleichtern:
- Toaster: Kann alles was die CLI kann und wenn ihr dort den Überblick verliert, verliert ihr ihn auch da
- Auch wenn Bitbake zustandsorientiert baut, sobald ihr eine der *.conf Dateien ändert, löscht alles und baut neu
- Wollt nicht zu viel auf einmal: Die Lernkurve ist eine Wand
- Nutzt keine der zusätzlichen Tools, die euch die Verwaltung vermeintlich erleichtern:
- Tooling, Debugging und Erweiterungen
- OpenEmbedded Layer Index: Eine Website, in der man nach Recipes sucht und auch die verschiedenen Versionen miteinander vergleichen kann.
- Wann lohnt sich der Einsatz von Yocto (und wann nicht)?
- Yocto lohnt sich immer dann:
- Ihr einen sehr spezifischen Anwendungszweck habt.
- Ihr euch unabhängig von Distributionen machen wollt.
- Keine Überraschungen bei Updates haben wollt.
- Wenn ihr genau wissen wollt und kontrollieren möchtet, was in eurem OS drin ist.
- Yocto lohnt sich nicht:
- Ihr euer System flexibel anpassen wollt.
- Auf dem System Softwareentwicklung stattfindet.
- Yocto lohnt sich immer dann:
- Beispielprojekt SpotyPee
- Wollte meine alte Hi-Fi Anlage mit AUX-Eingang auch für Spotify verwenden.
- Sollte möglichst Energiearm laufen
- Sollte robust im Betrieb sein
- Erfahrungen in der Wartung und Weiterentwicklung:
- Rust für Librespot
- Neue Versionen einpflegen
- Dokumentation
Links
- OpenEmbedded Layer Index: https://layers.openembedded.org/layerindex/branch/master/layers/
- Yocto Dokumentation: https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html
- SpotyPee: https://github.com/MrTarantoga/SpotyPee
- Artikelserie
Outro
- Euer Feedback ist uns wichtig. Ihr könnt uns über Matrix, Mastodon oder per E-Mail erreichen. Die Adressen findet ihr auf unserer Webseite.
- GNU/Linux.ch ist ein Magazin, in dem die Community für die Community interessante Artikel erstellt und im Podcast darüber diskutiert. Helft mit, die Infos für die Community zu bereichern. Wie das geht, erfahrt ihr hier.
The AI-powered Podcast Player
Save insights by tapping your headphones, chat with episodes, discover the best highlights - and more!
