In diesem Abschnitt bespreche ich einige Anpassungsmöglichkeiten, die ich benötigt habe. Dies ist nicht die vollständige Liste der Funktionen, die Buildroot bietet, aber sie sind definitiv funktional und erfordern kein Eingreifen in die Dateien von Buildroot selbst.
Verwendung des EXTERNAL-Mechanismus zur Anpassung
Es wurde ein einfaches Beispiel betrachtet, bei dem die eigene Konfiguration hinzugefügt wird, indem der defconfig der Platine und die benötigten Dateien direkt in das Buildroot-Verzeichnis eingefügt werden.
Diese Methode ist jedoch nicht sehr praktisch, insbesondere bei der Aktualisierung von Buildroot. Um dieses Problem zu lösen, gibt es einen Mechanismus external tree. Die Idee dabei ist, dass in einem separaten Verzeichnis die Verzeichnisse board, configs, packages und andere (zum Beispiel verwende ich ein Verzeichnis patches, um Patches auf Pakete anzuwenden, mehr dazu in einem separaten Abschnitt) gespeichert werden können, und Buildroot wird sie automatisch zu den vorhandenen in seinem Verzeichnis hinzufügen.
Hinweis: Es können mehrere external trees gleichzeitig hinzugefügt werden; ein Beispiel ist im Buildroot-Handbuch zu finden.
Wir erstellen das Verzeichnis my_tree, das sich neben dem buildroot-Verzeichnis befindet, und verschieben unsere Konfiguration dorthin. 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 DateienWie zu sehen ist, wiederholt die Struktur insgesamt die Struktur von buildroot.
Verzeichnis board enthält dateispezifische Dateien für jede Platine, in unserem Fall:
- bef_cr_fs_img.sh — ein Skript, das nach dem Erstellen der Ziel-Dateisysteme, aber vor dem Packen in Images ausgeführt wird. Wir werden es später verwenden.
- linux.config — die Kernelkonfiguration
- rootfs_overlay — ein Verzeichnis zum Überlagern über das Ziel-Dateisystem
- users.txt — eine Datei mit den Beschreibungen der zu erstellenden Benutzer.
Verzeichnis configs enthält die defconfig-Dateien unserer Platinen. Bei uns gibt es nur eine.
Package — ein Verzeichnis mit unseren Paketen. Ursprünglich enthält buildroot Beschreibungen und Regeln zum Erstellen einer begrenzten Anzahl von Paketen. Später fügen wir hier den Fenstermanager icewm und den grafischen Anmeldemanager Slim hinzu.
Patches — ermöglicht eine bequeme Speicherung Ihrer Patches für verschiedene Pakete. Weitere Informationen dazu finden Sie im nächsten Abschnitt.
Jetzt müssen wir die Beschreibung unseres external-tree hinzufügen. Dafür sind 3 Dateien verantwortlich: external.desc, Config.in, external.mk.
external.desc enthält die eigentliche Beschreibung:
[alexey@alexey-pc my_tree]$ cat external.desc
name: my_tree
desc: Mein einfaches external-tree für ArtikelDie erste Zeile ist der Name. Später wird buildroot eine Variable erstellen $(BR2_EXTERNAL_MY_TREE_PATH), die beim Konfigurieren des Builds verwendet werden muss. Zum Beispiel kann der Pfad zur Datei mit den Benutzern folgendermaßen angegeben werden:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txtDie zweite Zeile ist eine kurze, verständliche Beschreibung.
Config.in, external.mk — Dateien zur Beschreibung der hinzuzufügenden Pakete. Wenn keine eigenen Pakete hinzugefügt werden, können diese Dateien leer gelassen werden. Das werden wir vorerst so handhaben.
Jetzt ist unser external-tree bereit, das die defconfig unserer Platine und die benötigten Dateien enthält. Gehen wir in das buildroot-Verzeichnis und geben wir an, dass wir das external-tree verwenden möchten:
[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
#
# Konfiguration wurde in /home/alexey/dev/article/ramdisk/buildroot/.config geschrieben
#
[alexey@alexey-pc buildroot]$ make menuconfigIm ersten Befehl verwenden wir das Argument BR2_EXTERNAL=../my_tree/, der die Nutzung eines external tree angibt. Es ist möglich, mehrere external-trees gleichzeitig zu definieren. Dazu genügt es, dies einmal zu tun, woraufhin die Datei output/.br-external.mk erstellt wird, die Informationen über das verwendete external-tree speichert:
[alexey@alexey-pc buildroot]$ cat output/.br-external.mk
#
# Automatisch generierte Datei; NICHT BEARBEITEN.
#
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 ArtikelWichtig! In dieser Datei werden die Pfade absolut sein!
Im Menü ist der Punkt External options hinzugekommen:
In diesem Untermenü werden unsere Pakete aus unserem external-tree angezeigt. Momentan ist dieser Abschnitt leer.
Jetzt ist es wichtiger, die benötigten Pfade zur Nutzung des external-trees umzuschreiben.
Beachten Sie, dass im Bereich Build options → Location to save buildroot config, der absolute Pfad zur gespeicherten defconfig angezeigt wird. Er wird während der Angabe der Nutzung des external_tree gebildet.
Auch im Abschnitt System configuration werden wir die Pfade anpassen. Für die Tabelle mit den erstellten Benutzern:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txtIm Abschnitt Kernel ändern wir den Pfad zur Kernelkonfiguration:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/linux.configBei der Erstellung werden nun unsere Dateien aus unserem externen Baum verwendet. Bei der Übertragung in ein anderes Verzeichnis oder beim Aktualisieren von Buildroot erwarten uns minimale Probleme.
Hinzufügen eines Root-FS-Overlays:
Mit diesem Mechanismus können Dateien in das Ziel-Dateisystem einfach hinzugefügt oder ersetzt werden.
Wenn eine Datei im Root-FS-Overlay vorhanden ist, aber nicht im Ziel, wird sie hinzugefügt.
Wenn eine Datei sowohl im Root-FS-Overlay als auch im Ziel vorhanden ist, wird sie ersetzt.
Legen wir zuerst den Pfad zum Root-FS-Overlay-Verzeichnis fest. Dies geschieht im Bereich Systemkonfiguration → Verzeichnisse für Root-Dateisystem-Overlays:
$(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
Dies ist eine neue Datei aus dem Overlay.Die erste Datei (my_tree/board/my_x86_board/rootfs_overlay/etc/hosts) ersetzt die Datei /etc/hosts im fertigen System. Die zweite Datei (cat my_tree/board/my_x86_board/rootfs_overlay/new_file.txt) wird hinzugefügt.
Wir bauen und prüfen:
Ausführen von Anpassungsskripten in verschiedenen Phasen der Systemerstellung.
Es ist oft notwendig, bestimmte Aktionen innerhalb des Ziel-Dateisystems auszuführen, bevor es in Bilder verpackt wird.
Dies kann im Abschnitt Systemkonfiguration erfolgen:
Die ersten beiden Skripte werden nach dem Erstellen der Ziel-Dateisysteme, aber vor der Verpackung in Images ausgeführt. Der Unterschied besteht darin, dass das fakeroot-Skript im Kontext von fakeroot ausgeführt wird, was die Ausführung als Benutzer root simuliert.
Das letzte Skript wird bereits nach dem Erstellen der System-Images ausgeführt. Hier können zusätzliche Aktionen durchgeführt werden, beispielsweise um die benötigten Dateien auf einen NFS-Server zu kopieren oder ein Image Ihrer Gerätesoftware zu erstellen.
Als Beispiel werde ich ein Skript erstellen, das die Version und das Build-Datum in /etc/ schreibt.
Zuerst gebe ich den Pfad zu dieser Datei in meinem external-tree 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-releaseNach der Erstellung kann diese Datei im System gesehen werden.
In der Praxis kann das Skript umfangreich werden. Daher bin ich in einem realen Projekt einen fortgeschritteneren Weg gegangen:
- Ich habe ein Verzeichnis (my_tree/board_my_x86_board/inside_fakeroot_scripts) erstellt, in dem die Skripte zur Ausführung mit fortlaufenden Nummern liegen. Zum Beispiel 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh.
- Ich habe ein Skript (my_tree/board_my_x86_board/run_inside_fakeroot.sh) geschrieben, das dieses Verzeichnis durchläuft und nacheinander die darin vorhandenen Skripte ausführt.
- Dieses Skript habe ich in den Einstellungen des Boards im Abschnitt Systemkonfiguration -> Benutzerdefinierte Skripte, die im Fakeroot-Umfeld ausgeführt werden sollen ($(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/run_inside_fakeroot.sh) angegeben.
Quelle: habr.com
