Buildroot — Teil 2. Erstellung der Konfiguration für Ihre Platine; Anwendung von external tree, rootfs-overlay, post-build Skripten

In diesem Abschnitt betrachte ich einige Anpassungsmöglichkeiten, die ich benötigt habe. Dies ist keine vollständige Liste der Funktionen, die Buildroot bietet, aber sie sind völlig funktionsfähig und erfordern keine Änderungen an den Dateien von Buildroot.

Verwendung des EXTERNAL-Mechanismus zur Anpassung

Im vorherigen Artikel Es wurde ein einfaches Beispiel für das Hinzufügen meiner Konfiguration betrachtet, indem das defconfig der Platine und die benötigten Dateien direkt in das Buildroot-Verzeichnis eingefügt werden.

Aber diese Methode ist nicht sehr benutzerfreundlich, insbesondere beim Aktualisieren von Buildroot. Zur Lösung dieses Problems gibt es einen Mechanismus external tree. Die Idee ist, dass in einem separaten Verzeichnis die Verzeichnisse board, configs, packages und andere gespeichert werden können (zum Beispiel verwende ich ein Verzeichnis patches, um Patches auf Pakete anzuwenden, mehr dazu in einem separaten Abschnitt) und Buildroot wird sie automatisch zu den vorhandenen in seinem Verzeichnis hinzufügen.

Anmerkung: Es können mehrere external trees gleichzeitig angewendet werden, ein Beispiel ist im Buildroot-Handbuch zu finden.

Erstellen wir ein Verzeichnis my_tree, das sich neben dem Buildroot-Verzeichnis befindet, und verschieben wir dort unsere Konfiguration. Am Ende sollten wir die folgende Verzeichnisstruktur erhalten:

[alexey@alexey-pc my_tree]$ tree
.
├── board
│   └── my_x86_board
│       ├── bef_cr_fs_img.sh
│       ├── linux.config
│       ├── rootfs_overlay
│       └── users.txt
├── Config.in
├── configs
│   └── my_x86_board_defconfig
├── external.desc
├── external.mk
├── package
└── patches

6 Verzeichnisse, 7 Dateien

Wie zu sehen ist, wiederholt die Struktur im Großen und Ganzen die Struktur von Buildroot.

Verzeichnis board enthält Dateien, die spezifisch für jede Platine in unserem Fall sind:

• bef_cr_fs_img.sh — ein Skript, das nach dem Erstellen der Ziel-Dateisysteme, aber vor dem Packen in Images ausgeführt wird. Später werden wir es verwenden.
• linux.config — Kernel-Konfiguration
• rootfs_overlay — Verzeichnis zum Überlagern des Ziel-Dateisystems
• users.txt — Datei mit der Beschreibung der zu erstellenden Benutzer

Verzeichnis configs enthält die defconfig unserer Platinen. Wir haben nur einen.

Package — das Verzeichnis mit unseren Paketen. Zunächst enthält Buildroot Beschreibungen und Regeln für das Erstellen einer begrenzten Anzahl von Paketen. Später fügen wir hier den Fenstermanager icewm und den Grafik-Anmelde-Manager Slim hinzu.
Patches — ermöglicht es, meine Patches für verschiedene Pakete bequem zu speichern. Mehr dazu in einem separaten Abschnitt später.
Jetzt müssen wir die Beschreibungsdateien unseres external-tree hinzufügen. Dafür sind 3 Dateien verantwortlich: external.desc, Config.in, external.mk.

external.desc enthält tatsächlich die Beschreibung:

[alexey@alexey-pc my_tree]$ cat external.desc 
name: my_tree
desc: Mein einfaches external-tree für den Artikel

Die erste Zeile ist der Titel. Im Folgenden wird buildroot eine Variable erstellt $(BR2_EXTERNAL_MY_TREE_PATH), die beim Konfigurieren des Builds verwendet werden muss. Zum Beispiel kann der Pfad zur Benutzerdaten-Datei wie folgt festgelegt werden:

$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt

Die zweite Zeile ist eine kurze, verständliche Beschreibung.

Config.in, external.mk – Dateien zur Beschreibung der hinzugefügten Pakete. Wenn keine eigenen Pakete hinzugefügt werden, können diese Dateien leer bleiben. So werden wir es zunächst handhaben.
Jetzt ist unser external-tree bereit, das die defconfig unserer Platine und die benötigten Dateien enthält. Lassen Sie uns ins Verzeichnis buildroot wechseln und angeben, dass wir das external-tree verwenden:

[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
#
# Konfiguration geschrieben nach /home/alexey/dev/article/ramdisk/buildroot/.config
#
[alexey@alexey-pc buildroot]$ make menuconfig

Im ersten Befehl verwenden wir das Argument BR2_EXTERNAL=../my_tree/, das die Verwendung des external-tree angibt. Es ist möglich, mehrere external-trees gleichzeitig zu verwenden. Dazu genügt es, dies einmal zu tun, nach dem ein output/.br-external.mk Datei erstellt wird, die Informationen über das verwendete external-tree speichert:

[alexey@alexey-pc buildroot]$ cat output/.br-external.mk 
#
# Automatisch generierte Datei; NICHT EDITIEREN.
#

BR2_EXTERNAL ?= /home/alexey/dev/article/ramdisk/my_small_linux/my_tree
BR2_EXTERNAL_NAMES = 
BR2_EXTERNAL_DIRS = 
BR2_EXTERNAL_MKS = 

BR2_EXTERNAL_NAMES += my_tree
BR2_EXTERNAL_DIRS += /home/alexey/dev/article/ramdisk/my_small_linux/my_tree
BR2_EXTERNAL_MKS += /home/alexey/dev/article/ramdisk/my_small_linux/my_tree/external.mk
export BR2_EXTERNAL_my_tree_PATH = /home/alexey/dev/article/ramdisk/my_small_linux/my_tree
export BR2_EXTERNAL_my_tree_DESC = Mein einfaches external-tree für den Artikel

Wichtig! In dieser Datei werden die Pfade absolut sein!

Im Menü ist der Punkt Externe Optionen hinzugekommen:

In diesem Untermenü werden unsere Pakete aus unserem external-tree enthalten sein. Dieser Abschnitt ist momentan leer.

Jetzt ist es wichtiger für uns, die benötigten Pfade auf die Nutzung des external-tree zu ändern.

Beachten Sie, dass im Abschnitt Build-Optionen → Speicherort zur Speicherung der buildroot-Konfiguration der absolute Pfad zur gespeicherten defconfig angezeigt wird. Er wird zum Zeitpunkt der Angabe der Verwendung des external_tree gebildet.

Auch im Abschnitt Systemkonfiguration werden wir die Pfade anpassen. Für die Tabelle mit den erstellten Benutzern:

$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt

Im Abschnitt Kernel ändern wir den Pfad zur Kernel-Konfiguration:

$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/linux.config

Jetzt werden bei der Erstellung unsere Dateien aus unserem external-tree verwendet. Beim Verschieben in ein anderes Verzeichnis oder beim Aktualisieren von buildroot haben wir mindestens keine Probleme.

Hinzufügen des root fs overlays:

Dieser Mechanismus ermöglicht es, Dateien im Ziel-Dateisystem einfach hinzuzufügen oder zu ersetzen.
Wenn eine Datei im root fs overlay vorhanden ist, aber nicht im Ziel, wird sie hinzugefügt.
Wenn die Datei im Root-FS-Overlay und im Ziel vorhanden ist, wird sie ersetzt.
Zunächst bestimmen wir den Pfad zum Root-FS-Overlay-Verzeichnis. Dies erfolgt im Abschnitt Systemkonfiguration → Verzeichnisse für Root-Dateisystem-Overlay:

$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/

Nun erstellen wir zwei Dateien.

[alexey@alexey-pc my_small_linux]$ cat my_tree/board/my_x86_board/rootfs_overlay/etc/hosts 
127.0.0.1   localhost
127.0.1.1   my_small_linux
8.8.8.8     google-public-dns-a.google.com.
[alexey@alexey-pc my_small_linux]$ cat my_tree/board/my_x86_board/rootfs_overlay/new_file.txt 
Dies ist eine neue Datei aus dem Overlay.

Die erste Datei (my_tree/board/my_x86_board/rootfs_overlay/etc/hosts) wird die Datei /etc/hosts im Zielsystem ersetzen. Die zweite Datei (cat my_tree/board/my_x86_board/rootfs_overlay/new_file.txt) wird hinzugefügt.

Wir bauen zusammen und überprüfen:

Ausführen von Anpassungsskripten in verschiedenen Phasen des Systemaufbaus

Oft ist es notwendig, bestimmte Aktionen innerhalb des Ziel-Dateisystems auszuführen, bevor es in Images verpackt wird.

Dies kann im Abschnitt Systemkonfiguration erfolgen:

Die ersten beiden Skripte werden nach dem Aufbau des Ziel-Dateisystems, aber vor der Verpackung in Images ausgeführt. Der Unterschied besteht darin, dass das Fakeroot-Skript im Kontext von Fakeroot ausgeführt wird, das heißt, es wird simuliert, dass es vom Benutzer root ausgeführt wird.

Das letzte Skript wird nach der Erstellung der System-Images ausgeführt. In diesem Skript können zusätzliche Aktionen ausgeführt werden, wie zum Beispiel das Kopieren erforderlicher Dateien auf einen NFS-Server oder das Erstellen eines Images Ihrer Gerätesoftware.

Als Beispiel werde ich ein Skript erstellen, das die Version und das Erstellungsdatum in /etc/ schreibt.
Zuerst gebe ich den Pfad zu dieser Datei in meinem externen Baum an:

Und jetzt das Skript selbst:

[alexey@alexey-pc buildroot]$ cat ../my_tree/board/my_x86_board/bef_cr_fs_img.sh 
#! /bin/sh
echo "my small linux 1.0 pre alpha" > output/target/etc/mysmalllinux-release
date >> output/target/etc/mysmalllinux-release

Nach dem Erstellen kann man diese Datei im System sehen.

In der Praxis kann das Skript umfangreich werden. Daher habe ich in einem realen Projekt einen fortgeschritteneren Ansatz gewählt:

1. Ich habe ein Verzeichnis (my_tree/board_my_x86_board/inside_fakeroot_scripts) erstellt, in dem die auszuführenden Skripte mit fortlaufenden Nummern liegen. Zum Beispiel, 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh
2. Ich schrieb ein Skript (my_tree/board_my_x86_board/run_inside_fakeroot.sh), das dieses Verzeichnis durchläuft und die darin enthaltenen Skripte der Reihe nach ausführt.
3. Ich habe dieses Skript in den Einstellungen des Boards im Abschnitt Systemkonfiguration → Benutzerdefinierte Skripte zur Ausführung im Fakeroot-Umfeld angegeben ($(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/run_inside_fakeroot.sh)

Quelle: habr.com