🥇Buildroot — Teil 1. Allgemeine Informationen, Erstellung eines minimalen Systems, Konfiguration über das Menü

Einführung

In dieser Artikelreihe möchte ich das Buildroot-Betriebssystem und meine Erfahrungen mit dessen Anpassung beleuchten. Hier wird es praktische Erfahrungen in der Erstellung eines kleinen Betriebssystems mit grafischer Benutzeroberfläche und minimaler Funktionalität geben.

Zunächst einmal sollte man das Build-System und das Betriebssystem nicht verwechseln. Buildroot kann ein System aus einem Satz von Paketen erstellen, die ihm angeboten werden. Buildroot basiert auf Makefiles und bietet daher immense Anpassungsmöglichkeiten. Ein Paket durch eine andere Version zu ersetzen, ein eigenes Paket hinzuzufügen, die Build-Regeln eines Pakets zu ändern und das Dateisystem nach der Installation aller Pakete anzupassen? All das kann Buildroot.

In Russland wird Buildroot verwendet, aber meines Erachtens gibt es wenig russischsprachige Informationen für Anfänger.

Das Ziel dieser Arbeit ist es, ein Distribution mit Live-Start, einem IceWM-Interface und einem Browser zu erstellen. Die Zielplattform ist VirtualBox.

Warum ein eigenes Distribution erstellen? Oft benötigt man eine eingeschränkte Funktionalität bei begrenzten Ressourcen. Noch häufiger in der Automatisierung muss man Firmware erstellen. Ein Allzweck-Betriebssystem anzupassen, indem man überflüssige Pakete entfernt und es in eine Firmware umwandelt, ist ein deutlich mühsamerer Weg, als eine neue Distribution zu erstellen. Auch die Verwendung von Gentoo hat ihre Einschränkungen.

Buildroot ist ein sehr leistungsfähiges System, aber es wird nichts für Sie tun. Es kann nur Möglichkeiten bieten und den Build-Prozess automatisieren.

Alternative Build-Systeme (Yocto, Open Build System und andere) werden nicht betrachtet und nicht verglichen.

Wo man es bekommen kann und wie man anfängt

Projekt-Website — buildroot.org. Hier kann man die aktuelle Version herunterladen und das Handbuch lesen. Dort kann man sich auch an die Gemeinschaft wenden, es gibt einen Bugtracker, Mailinglisten und einen IRC-Kanal.

Buildroot arbeitet mit Defconfig-Dateien für die Zielplattform. Defconfig ist eine Konfigurationsdatei, die nur Optionen speichert, die keine Standardwerte haben. Sie legt fest, was und wie gebaut wird. Dabei können die Konfigurationen von Busybox, Linux-Kernel, uClibc, Bootloadern wie u-boot und barebox separat angepasst werden, aber alle sind an die Zielplattform gebunden.
Nach dem Entpacken des heruntergeladenen Archivs oder dem Klonen aus Git haben wir ein sofort einsatzbereites Buildroot. Über die Struktur der Verzeichnisse kann man im Handbuch lesen, ich werde über die wichtigsten sprechen:

board — Katalog mit dateispezifischen Dateien für jedes Board. Dazu können Erstellungs-Skripte für Systemabbilder (iso, sdcart, cpio usw.), Overlay-Verzeichnisse, Kernel-Konfigurationen und mehr gehören.
configs — das eigentliche defconfig des Boards. Defconfig ist eine unvollständige Konfiguration des Boards. Darin werden nur Parameter gespeichert, die von den Standardwerten abweichen.
dl — Verzeichnis mit heruntergeladenen Quellcodes/Dateien zum Erstellen.
output/target — das erstellte Dateisystem des erhaltenen OS. Daraus werden später Abbilder für den Boot- und Installationsprozess erstellt.
output/host — Host-Utilities für den Build.
output/build — gebaute Pakete.

Die Konfiguration des Builds erfolgt über KConfig. Dieses System wird auch zum Bauen des Linux-Kernels verwendet. Eine Liste der am häufigsten verwendeten Befehle (im Verzeichnis buildroot auszuführen):

make menuconfig — Aufruf der Build-Einstellungen. Auch über eine grafische Oberfläche möglich (make nconfig, make xconfig, make gconfig).
make linux-menuconfig — Aufruf der Kernel-Konfiguration.
make clean — Bereinigung der Build-Ergebnisse (alles, was sich im output befindet).
make — das System erstellen. Dabei erfolgt keine Neuerstellung bereits gebaute Prozesse.
make defconfig_name — die Konfiguration auf das bestimmte defconfig umschalten.
make list-defconfigs — Liste der defconfigs anzeigen.
make source — nur die Installationsdateien herunterladen, ohne zu bauen.
make help — Liste der verfügbaren Befehle ausgeben.

Wichtige Hinweise und nützliche Tipps.

Buildroot baut bereits gebaute Pakete nicht neu! Daher kann eine Situation entstehen, in der ein vollständiger Neubau erforderlich ist.

Ein einzelnes Paket kann mit dem Befehl neu gebaut werden. make packagename-rebuild. Zum Beispiel kann der Linux-Kernel neu gebaut werden:

make linux-rebuild.

Buildroot speichert den Status jedes Paketes durch die Erstellung von .stamp-Dateien im Verzeichnis output/build/$packagename:

Daher können root-fs und Abbildungen ohne Neubau der Pakete neu gebaut werden:

rm output/build/host-gcc-final-*/.stamp_host_installed; rm -rf output/target; find output/ -name ".stamp_target_installed" | xargs rm -rf; make.

Nützliche Variablen.

In Buildroot gibt es eine Reihe von Variablen für eine bequeme Konfiguration.

$TOPDIR — das Wurzelverzeichnis von Buildroot.
$BASEDIR — Verzeichnis OUTPUT.
$HOST_DIR, $STAGING_DIR, $TARGET_DIR — Verzeichnisse für das Erstellen von host fs, staging fs, target fs.
$BUILD_DIR — Verzeichnis mit entpackten und gebauten Paketen.

Visualisierung

In Buildroot besteht die Möglichkeit der Visualisierung. Es können Abhängigkeitsdiagramme, Zeitpläne für den Build und Diagramme der Paketgrößen im Endsystem erstellt werden. Die Ergebnisse liegen in Form von PDF-Dateien (es gibt die Auswahl zwischen svn, png) im Verzeichnis output/graph vor.

Beispiele für Visualisierungsbefehle:

graph-depends erstellen Abhängigkeitsbaum erstellen
make -graph-depends Abhängigkeitsbaum eines bestimmten Pakets erstellen
BR2_GRAPH_OUT=png make graph-build Erstellen Sie ein Diagramm der Build-Zeit mit PNG-Ausgabe
make graph-size Paketgrößen-Diagramm erstellen

Nützliche Skripte

Im buildroot-Verzeichnis gibt es ein Unterverzeichnis utils mit nützlichen Skripten. Zum Beispiel gibt es dort ein Skript, das die Korrektheit der Paketbeschreibungen überprüft. Dies kann nützlich sein, wenn man eigene Pakete hinzufügt (ich werde das später tun). Im utils/readme.txt gibt es eine Beschreibung dieser Skripte.

Wir werden ein Standard-Distribution erstellen

Es ist wichtig zu erinnern, dass alle Operationen im Namen eines normalen Benutzers, nicht als root, durchgeführt werden.
Alle Befehle werden im Wurzelverzeichnis von buildroot ausgeführt. Im Lieferumfang von buildroot gibt es bereits eine Reihe von Konfigurationen für viele gängige Boards und Virtualisierungen.

Sehen wir uns die Liste der Konfigurationen an:

Wir wechseln zu der Konfiguration qemu_x86_64_defconfig

make qemu_x86_64_defconfig

Und starten den Build

make

Der Build war erfolgreich, sehen wir uns die Ergebnisse an:

Buildroot hat Images erstellt, die in Qemu ausgeführt werden können, um sicherzustellen, dass sie funktionieren.

qemu-system-x86_64 -kernel output/images/bzImage -hda output/images/rootfs.ext2 -append "root=/dev/sda rw" -s -S

Das Ergebnis — das in Qemu gestartete System:

Erstellen der Konfiguration für eigenes Board

Hinzufügen von Board-Dateien

Sehen wir uns die Liste der Konfigurationen an:

In der Liste sehen wir pc_x86_64_efi_defconfig. Wir werden unser Board erstellen, indem wir es von der Konfiguration kopieren:

cp configs/pc_x86_64_bios_defconfig configs/my_x86_board_defconfig

Wir erstellen sofort ein Verzeichnis für das Board, um unsere Skripte, rootfs-overlay und andere notwendige Dateien zu speichern:

mkdir board/my_x86_board

Wir wechseln zu diesem defconfig:

make my_x86_board_defconfig

Somit entspricht die Build-Konfiguration (die in .config im Wurzelverzeichnis von buildroot gespeichert ist) jetzt dem Zielgerät x86-64 legacy (bios) Boot.

Kopieren wir die Linux-Kernel-Konfiguration (wird später nützlich sein):

cp board/pc/linux.config board/my_x86_board/

Einstellungen für den Build über KConfig konfigurieren

Wir starten die Konfiguration:

, und vor Ihnen erscheint eine praktische Textschnittstelle mit der Anzeige der Parameterbeschreibungen.

Ein KConfig-Fenster wird geöffnet. Es besteht die Möglichkeit, mit einer grafischen Benutzeroberfläche zu konfigurieren (make nconfig, make xconfig, make gconfig):

Wir betreten den ersten Abschnitt Zieloptionen. Hier kann die Zielarchitektur ausgewählt werden, für die der Build erfolgen wird.

Build-Optionen — hier gibt es verschiedene Build-Einstellungen. Zielverzeichnisse für den Quellcode, Anzahl der Build-Threads, Mirrors für den Download von Quellcodes und andere Einstellungen können angegeben werden. Wir lassen die Standardeinstellungen.

Toolchain – hier wird das eigentliche Build-Toolset konfiguriert. Näheres dazu.

Toolchain-Typ – der verwendete Toolchain-Typ. Dies kann entweder die in Buildroot integrierte oder eine externe Toolchain sein (ein Verzeichnis mit bereits erstelltem oder eine URL zum Herunterladen kann angegeben werden). Für verschiedene Architekturen gibt es zusätzliche Optionen. Zum Beispiel kann für ARM einfach die Version der externen Toolchain Linaro ausgewählt werden.

C-Bibliothek – Auswahl der C-Bibliothek. Dies beeinflusst das gesamte System. Normalerweise wird glibc verwendet, die alle möglichen Funktionen unterstützt. Sie kann jedoch zu groß für ein eingebettetes System sein, weshalb oft uglibc oder musl gewählt werden. Wir wählen glibc (dies wird später für die Verwendung von systemd erforderlich sein).

Kernel-Header und benutzerdefinierte Kernel-Header-Serie – müssen mit der Version des Kernels übereinstimmen, die im zu erstellenden System verwendet wird. Für Kernel-Header kann ebenfalls der Pfad zum Tarball oder zum Git-Repository angegeben werden.

GCC-COMPILER VERSIONEN – Auswahl der Compiler-Version, die für den Build verwendet wird
C++-Unterstützung aktivieren – wir wählen die Unterstützung von C++-Bibliotheken im System für den Build. Das wird uns später nützlich sein.

Zusätzliche GCC-Optionen – es können zusätzliche Compiler-Optionen angegeben werden. Bisher benötigen wir das nicht.

Die Systemkonfiguration ermöglicht die Festlegung zukünftiger Parameter des erstellten Systems:

Die meisten Punkte sind aus dem Titel verständlich. Achten wir auf die folgenden Punkte:
Pfad zu den Benutzertabellen – Tabelle mit den zu erstellenden Benutzern (https://buildroot.org/downloads/manual/manual.html#makeuser-syntax).

Beispiel-Datei. Ein Benutzer 'user' wird mit dem Passwort 'admin' erstellt, automatisch gid/uid, /bin/sh als Shell, die Standardgruppe 'user', Mitglied der Gruppe 'root', Kommentar 'Foo user'

[alexey@alexey-pc buildroot ]$ cat board/my_x86_board/users.txt 
user -1 user -1 =admin /home/user /bin/sh root Foo user

Root-Dateisystem-Overlay-Verzeichnisse – Verzeichnis, das über das erstellte target-fs gelegt wird. Fügt neue Dateien hinzu und ersetzt vorhandene.

Benutzerdefinierte Skripte, die vor dem Erstellen von Dateisystemabbildern ausgeführt werden – Skripte, die direkt vor der Erstellung der Dateisystemabbilder ausgeführt werden. Das Skript lassen wir vorerst leer.

Gehen wir zum Abschnitt Kernel

Hier werden die Kernel-Einstellungen festgelegt. Der Kernel selbst wird über make linux-menuconfig konfiguriert.
Die Version des Kernels kann auf verschiedene Weise festgelegt werden: aus den verfügbaren auswählen, die Version manuell eingeben, ein Repository oder ein fertiges Tarball angeben.

Kernel-Konfiguration – Pfad zur Kernel-Konfigurationsdatei. Es kann die Standardkonfiguration für die gewählte Architektur oder defconfig aus Linux ausgewählt werden. In den Linux-Quellen gibt es ein Set von defconfig-Dateien für verschiedene Zielsysteme. Das benötigte kann gefunden werden, indem man direkt in die Quellen hier schaut. Zum Beispiel für das Board Beagle Bone Black kann man Konfiguration auswählen.

Der Abschnitt Zielpakete ermöglicht es, auszuwählen, welche Pakete in das zu erstellende System installiert werden sollen. Lassen wir vorerst alles unverändert. Später fügen wir unsere Pakete in diese Liste ein.
Dateisystemabbilder — eine Liste der Dateisystemabbilder, die erstellt werden sollen. Wir fügen ein ISO-Abbild hinzu.

Bootloader — Auswahl der zu erstellenden Bootloader. Wählen wir isolinix.

Systemd konfigurieren

Systemd wird zu einem der Säulen von Linux, gleichauf mit Kernel und glibc. Deshalb habe ich seine Konfiguration in einen eigenen Punkt ausgegliedert.

Es wird über make menuconfig konfiguriert, dann Zielpakete → Systemwerkzeuge → systemd. Hier kann angegeben werden, welche systemd-Dienste installiert und beim Systemstart gestartet werden sollen.

Speichern der Systemkonfiguration

Wir speichern diese Konfiguration über KConfig.

Danach speichern wir unser defconfig:

make savedefconfig

Konfiguration des Linux-Kernels

Die Konfiguration des Linux-Kernels erfolgt mit folgendem Befehl:

make linux-menuconfig

Fügen wir Unterstützung für die Grafikkarte von Virtualbox hinzu.

Fügen wir die Virtualbox-Gastintegrationsunterstützung hinzu.

Speichern und beenden. WICHTIG: Die Konfiguration wird in output/build/linux-$version/config gespeichert, aber nicht in board/my_x86_board/linux.config.

Deshalb muss die Konfiguration manuell an den Speicherort kopiert werden:

cp output/build/linux-4.19.25/.config board/my_x86_board/linux.config

Danach führen wir einen vollständigen Neubau des gesamten Systems durch. Da Buildroot die bereits erstellten Komponenten nicht neu baut, müssen die Pakete für den Neuaufbau manuell angegeben werden. Um Zeit und Nerven zu sparen, ist es einfacher, ein kleines System vollständig neu zusammenzustellen):