In diesem Abschnitt werde ich einige der Anpassungsfunktionen betrachten, die ich benötigte. Dies ist keine vollständige Liste der Angebote von buildroot, aber sie funktionieren recht gut und erfordern keinen Eingriff in die Dateien von buildroot.
Verwenden des EXTERNAL-Mechanismus zur Anpassung
Im vorherigen Artikel haben wir ein einfaches Beispiel für das Hinzufügen Ihrer Konfiguration betrachtet, indem Sie die defconfig der Karte und die erforderlichen Dateien direkt zum Buildroot-Verzeichnis hinzugefügt haben.
Diese Methode ist jedoch nicht sehr praktisch, insbesondere beim Aktualisieren von Buildroot. Um dieses Problem zu lösen, gibt es einen externen Baummechanismus. Das Wesentliche ist, dass Sie Board, Konfigurationen, Pakete und andere Verzeichnisse in einem separaten Verzeichnis speichern können (ich verwende beispielsweise das Patches-Verzeichnis, um Patches auf Pakete anzuwenden, mehr in einem separaten Abschnitt), und Buildroot fügt sie denen in seinem eigenen Verzeichnis hinzu.
Hinweis: Sie können mehrere externe Bäume gleichzeitig anwenden. Ein Beispiel finden Sie im Buildroot-Handbuch
Erstellen Sie das Verzeichnis my_tree neben dem Verzeichnis buildroot und übertragen Sie unsere Konfiguration dorthin. Die Ausgabe sollte die folgende Dateistruktur haben:
[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 directories, 7 files
Wie Sie sehen können, folgt die Struktur im Allgemeinen der Struktur von Buildroot.
Das Board- Verzeichnis enthält in unserem Fall für jedes Board spezifische Dateien:
- bef_cr_fs_img.sh - Ein Skript, das nach dem Erstellen des Zieldateisystems, aber vor dem Packen in Bilder ausgeführt wird. In Zukunft werden wir es verwenden
- linux.config - Kernelkonfiguration
- rootfs_overlay - Verzeichnis, das über das Zieldateisystem gelegt werden soll
- users.txt - Datei mit einer Beschreibung der erstellten Benutzer
Das Configs- Verzeichnis enthält die Defconfigs unserer Boards. Wir haben nur einen.
Paket - ein Katalog mit unseren Paketen. Buildroot enthält zunächst Beschreibungen und Regeln zum Erstellen einer begrenzten Anzahl von Paketen. Später werden wir hier icewm window manager und Slim logon manager hinzufügen.
Patches - Ermöglicht das bequeme Speichern Ihrer Patches für verschiedene Pakete. Weitere Details finden Sie in einem separaten Abschnitt weiter unten.
Jetzt müssen wir die Beschreibungsdateien unseres externen Baums hinzufügen. Dafür sind 3 Dateien verantwortlich: external.desc, Config.in, external.mk.
external.desc enthält die aktuelle Beschreibung:
[alexey@alexey-pc my_tree]$ cat external.desc name: my_tree desc: My simple external-tree for article
Die erste Zeile ist der Name. Buildroot erstellt in Zukunft die Variable $ (BR2_EXTERNAL_MY_TREE_PATH) , die bei der Konfiguration der Assembly verwendet werden muss. Beispielsweise kann der Pfad zur Datei mit Benutzern folgendermaßen festgelegt werden:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
Die zweite Zeile ist eine kurze, für Menschen lesbare Beschreibung.
Config.in, external.mk - Dateien zur Beschreibung der hinzugefügten Pakete. Wenn Sie Ihre Pakete nicht hinzufügen, können diese Dateien leer bleiben. Bisher werden wir das tun.
Jetzt haben wir unseren externen Baum bereit, der die defconfig unseres Boards und die benötigten Dateien enthält. Wir gehen in das Buildroot-Verzeichnis und geben die Verwendung des externen Baums an:
[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
Im ersten Befehl verwenden wir das Argument BR2_EXTERNAL = .. / my_tree / , das die Verwendung eines externen Baums angibt. Sie können mehrere externe Bäume gleichzeitig für die Verwendung angeben. Es reicht aus, dies einmal zu tun . Anschließend wird eine Ausgabe / .br-external.mk-Datei erstellt, in der gespeichert wird Informationen zum verwendeten externen Baum:
[alexey@alexey-pc buildroot]$ cat output/.br-external.mk
Wichtig! In dieser Datei sind die Pfade absolut!
Der Menüpunkt Externe Optionen wurde angezeigt:
Dieses Untermenü enthält unsere Pakete aus unserem externen Baum. Jetzt ist dieser Abschnitt leer.
Jetzt ist es für uns wichtiger, die notwendigen Pfade für die Verwendung eines externen Baums neu zu schreiben.
Beachten Sie, dass im Abschnitt Build-Optionen → Speicherort zum Speichern der Buildroot-Konfiguration ein absoluter Pfad zur gespeicherten Defconfig vorhanden ist. Es wird zum Zeitpunkt der Angabe der Verwendung von extgernal_tree gebildet.
Korrigieren Sie auch im Abschnitt Systemkonfiguration die Pfade. Für eine Tabelle mit vom Benutzer erstelltem:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
Ändern Sie im Abschnitt Kernel den Pfad zur Kernelkonfiguration:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/linux.config
Jetzt verwendet die Assembly unsere Dateien aus unserem externen Baum. Bei der Übertragung in ein anderes Verzeichnis und beim Aktualisieren von Buildroot treten nur minimale Probleme auf.
Hinzufügen von Root-Fs-Overlay:
Dieser Mechanismus erleichtert das Hinzufügen / Ersetzen von Dateien im Zieldateisystem.
Befindet sich die Datei im Root-Fs-Overlay, jedoch nicht im Ziel, wird sie hinzugefügt
Befindet sich die Datei im Root-Fs-Overlay und im Ziel, wird sie ersetzt.
Stellen Sie zunächst den Pfad auf root fs overlay dir ein. Dies erfolgt im Abschnitt Systemkonfiguration → Overlay-Verzeichnisse des Root-Dateisystems:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/
Jetzt 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 This is new file from overlay
Die erste Datei (my_tree / board / my_x86_board / rootfs_overlay / etc / hosts) ersetzt die Datei / etc / hosts auf dem fertigen System. Eine zweite Datei (cat my_tree / board / my_x86_board / rootfs_overlay / new_file.txt) wird hinzugefügt.
Wir sammeln und prüfen:
Ausführung von Anpassungsskripten in verschiedenen Phasen der Systemassemblierung
Oft müssen Sie einige Aktionen im Zieldateisystem ausführen, bevor es in Bilder gepackt wird.
Dies kann im Abschnitt Systemkonfiguration erfolgen:
Die ersten beiden Skripte werden ausgeführt, nachdem das Zieldateisystem erstellt wurde, aber bevor es in Bilder gepackt wird. Der Unterschied besteht darin, dass das Fakeroot-Skript im Kontext des Fakeroot ausgeführt wird und die Arbeit des Root-Benutzers simuliert.
Das letzte Skript wird nach dem Erstellen der Systemabbilder ausgeführt. Sie können darin zusätzliche Aktionen ausführen, z. B. die erforderlichen Dateien auf einen NFS-Server kopieren oder ein Image Ihrer Gerätefirmware erstellen.
Als Beispiel werde ich ein Skript erstellen, das die Version und das Erstellungsdatum in / etc / schreibt.
Zuerst werde ich den Pfad zu dieser Datei in meinem externen Baum angeben:
Und jetzt das Drehbuch selbst:
[alexey@alexey-pc buildroot]$ cat ../my_tree/board/my_x86_board/bef_cr_fs_img.sh
Nach dem Zusammenbau können Sie diese Datei im System sehen.
In der Praxis kann ein Skript groß werden. Daher bin ich in einem echten Projekt weiter fortgeschritten:
- Erstellt ein Verzeichnis (my_tree / board_my_x86_board / inside_fakeroot_scripts), in dem Skripte zur Ausführung mit Seriennummern liegen. Zum Beispiel 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh
- Ich habe ein Skript geschrieben (my_tree / board_my_x86_board / run_inside_fakeroot.sh), das dieses Verzeichnis durchläuft und die darin enthaltenen Skripte nacheinander ausführt
- Dieses Skript wird in den Karteneinstellungen in der Systemkonfiguration -> Benutzerdefinierte Skripts angezeigt, die in der Fakeroot-Umgebung ausgeführt werden sollen ($ (BR2_EXTERNAL_my_tree_PATH) /board/my_x86_board/run_inside_fakeroot.sh).