W tej sekcji omawiam część możliwości dostosowania, które były mi potrzebne. To nie jest pełna lista tego, co oferuje buildroot, ale są to całkiem funkcjonalne rozwiązania, które nie wymagają ingerencji w pliki samego buildroot.
Zastosowanie mechanizmu EXTERNAL do dostosowywania
Rozważano prosty przykład dodania własnej konfiguracji, poprzez dodanie defconfig’a płyty oraz potrzebnych plików bezpośrednio do katalogu Buildroot.
Jednak ta metoda nie jest zbyt wygodna, szczególnie przy aktualizacji buildroot. Aby rozwiązać ten problem, istnieje mechanizm external tree. Jego istota polega na tym, że w osobnym katalogu można przechowywać katalogi board, configs, packages i inne (na przykład, ja używam katalogu patches do nakładania poprawek na pakiety, więcej w osobnej sekcji) i buildroot będzie automatycznie dodawać je do tych, które już znajdują się w jego katalogu.
Uwaga: można nakładać od razu kilka external tree, jest przykład w dokumentacji buildroot
Utwórzmy katalog my_tree, znajdujący się obok katalogu buildroot i przenieśmy tam naszą konfigurację. Na wyjściu powinniśmy uzyskać następującą strukturę plików:
[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 katalogów, 7 plikówJak widać, ogólna struktura powtarza strukturę buildroot.
Katalog board zawiera pliki specyficzne dla każdej płyty w naszym przypadku:
- bef_cr_fs_img.sh — skrypt, który będzie wykonywany po zbudowaniu targetowej systemu plików, ale przed spakowaniem go w obrazy. W przyszłości będziemy go używać
- linux.config — konfiguracja jądra
- rootfs_overlay — katalog do nakładania na targetową systemu plików
- users.txt — plik z opisem tworzonych użytkowników
Katalog konfiguracje zawiera defconfig’i naszych płyt. Mamy ich tylko jeden.
Pakiet — katalog z naszymi pakietami. Początkowo buildroot zawiera opisy i zasady budowy ograniczonej liczby pakietów. Później dodamy tutaj menedżer okien icewm i menedżer graficznego logowania Slim.
Poprawki — umożliwia wygodne przechowywanie własnych poprawek dla różnych pakietów. Więcej w osobnej sekcji dalej.
Teraz trzeba dodać pliki opisujące nasze external-tree. Za to odpowiadają 3 pliki: external.desc, Config.in, external.mk.
external.desc zawiera samo opisanie:
[alexey@alexey-pc my_tree]$ cat external.desc
name: my_tree
desc: Mój prosty external-tree do artykułuPierwsza linia to nazwa. Następnie buildroot tworzy zmienną $(BR2_EXTERNAL_MY_TREE_PATH), którą należy wykorzystać podczas konfigurowania kompilacji. Na przykład, ścieżkę do pliku z użytkownikami można określić następująco:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txtDruga linia to krótkie, zrozumiałe dla człowieka opisanie.
Config.in, external.mk — pliki do opisywania dodawanych pakietów. Jeśli nie dodajemy swoich pakietów, te pliki mogą pozostać puste. Jak na razie tak zrobimy.
Teraz mamy gotowe nasze external-tree, zawierające defconfig naszej płyty i potrzebne mu pliki. Przejdźmy do katalogu buildroot i wskażmy, by używał external-tree:
[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
#
# konfiguracja zapisana w /home/alexey/dev/article/ramdisk/buildroot/.config
#
[alexey@alexey-pc buildroot]$ make menuconfigW pierwszej komendzie używamy argumentu BR2_EXTERNAL=../my_tree/, który wskazuje na użycie external tree. Można jednocześnie określić kilka external-tree do użycia. W takim przypadku wystarczy zrobić to raz, po czym zostanie utworzony plik output/.br-external.mk, przechowujący informacje o używanym external-tree:
[alexey@alexey-pc buildroot]$ cat output/.br-external.mk
#
# Plik generowany automatycznie; NIE EDYTUJ.
#
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 = Mój prosty external-tree do artykułuUwaga! W tym pliku ścieżki będą absolutne!
W menu pojawił się punkt Opcje zewnętrzne:
W tym podmenu będą zawarte nasze pakiety z naszego external-tree. Obecnie ta sekcja jest pusta.
Teraz ważniejsze jest przepisanie potrzebnych ścieżek na użycie external-tree.
Zauważcie, że w sekcji Opcje kompilacji → Miejsce zapisu konfiguracji buildroot, będzie absolutna ścieżka do zapisanego defconfigu. Formuje się ona w momencie wskazania użycia external_tree.
Również w sekcji Konfiguracja systemu poprawimy ścieżki. Do tabeli z tworzonymi użytkownikami:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txtW sekcji Kernela zmienimy ścieżkę do konfiguracji jądra:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/linux.configTeraz podczas kompilacji będą używane nasze pliki z naszego external-tree. Przy przenoszeniu do innego katalogu, aktualizacji buildroot będziemy mieli minimalne problemy.
Dodanie root fs overlay:
Ten mechanizm umożliwia łatwe dodawanie/zastępowanie plików w systemie plików docelowego.
Jeśli plik znajduje się w root fs overlay, ale nie ma go w docelowym, zostanie dodany.
Jeśli plik znajduje się w warstwie root fs overlay i w target, zostanie on zastąpiony.
Najpierw ustalimy ścieżkę do katalogu overlay systemu plików root. Robi się to w sekcji Konfiguracja systemu → Katalogi overlay systemu plików root:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/Teraz stworzymy dwa pliki.
[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
To jest nowy plik z overlay.Pierwszy plik (my_tree/board/my_x86_board/rootfs_overlay/etc/hosts) zastąpi plik /etc/hosts w gotowym systemie. Drugi plik (cat my_tree/board/my_x86_board/rootfs_overlay/new_file.txt) zostanie dodany.
Zbieramy i sprawdzamy:
Wykonywanie skryptów dostosowujących na różnych etapach budowy systemu
Często potrzebne jest wykonanie niektórych działań wewnątrz docelowego systemu plików zanim zostanie on zapakowany w obrazy.
Można to zrobić w sekcji Konfiguracja systemu:
Pierwsze dwa skrypty wykonywane są po budowie docelowego systemu plików, ale przed spakowaniem go w obrazy. Różnica polega na tym, że skrypt fakeroot wykonywany jest w kontekście fakeroot, czyli imituje pracę z konta użytkownika root.
Ostatni skrypt uruchamiany jest już po stworzeniu obrazów systemu. Można w nim wykonać dodatkowe czynności, na przykład skopiować potrzebne pliki na serwer nfs lub utworzyć obraz swojego oprogramowania układowego urządzenia.
Na przykład utworzę skrypt, który zapisze wersję i datę budowy w /etc/
Najpierw wskażę ścieżkę do tego pliku w moim drzewie zewnętrznym:
A teraz sam skrypt:
[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-releasePo budowie można zobaczyć ten plik w systemie.
W praktyce skrypt może być większy. Dlatego w prawdziwym projekcie poszedłem bardziej zaawansowaną drogą:
- Utworzyłem katalog (my_tree/board_my_x86_board/inside_fakeroot_scripts), w którym znajdują się skrypty do wykonania, z numerami porządkowymi. Na przykład 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh
- Napisałem skrypt (my_tree/board_my_x86_board/run_inside_fakeroot.sh), który przechodzi przez ten katalog i kolejno wykonuje znajdujące się w nim skrypty.
- Wskazałem ten skrypt w ustawieniach płyty w sekcji Konfiguracja systemu → Skrypty dostosowane do uruchomienia w środowisku fakeroot ($(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/run_inside_fakeroot.sh)
Źródło: habr.com
