Buildroot - parte 2. Creazione della configurazione della scheda; utilizzando albero esterno, rootfs-overlay, script post-build

In questa sezione esamino alcune delle opzioni di personalizzazione di cui avevo bisogno. Questo non è un elenco completo di ciò che offre buildroot, ma sono abbastanza funzionali e non richiedono interventi nei file di buildroot stesso.

Utilizzando il meccanismo ESTERNO per la personalizzazione

In un precedente articolo Abbiamo esaminato un semplice esempio di aggiunta della propria configurazione aggiungendo il defconfig della scheda e i file necessari direttamente nella directory Buildroot.

Ma questo metodo non è molto conveniente, soprattutto quando si aggiorna buildroot. Esiste un meccanismo per risolvere questo problema albero esterno. La sua essenza è che puoi memorizzare board, configurazioni, pacchetti e altre directory in una directory separata (ad esempio, io utilizzo la directory patch per applicare patch ai pacchetti, maggiori dettagli in una sezione separata) e buildroot stesso li aggiungerà a quelli in la sua directory.

Nota: puoi sovrapporre più alberi esterni contemporaneamente, c'è un esempio nel manuale buildroot

Creiamo una directory my_tree, situata accanto alla directory buildroot e trasferiamo lì la nostra configurazione. L'output dovrebbe essere la seguente struttura di file:

[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

Come puoi vedere, in generale la struttura ripete la struttura di buildroot.

elenco tavola contiene file specifici per ciascuna scheda nel nostro caso:

  • bef_cr_fs_img.sh è uno script che verrà eseguito dopo aver creato il file system di destinazione, ma prima di impacchettarlo in immagini. Lo useremo in futuro
  • linux.config - configurazione del kernel
  • rootfs_overlay - directory da sovrapporre al file system di destinazione
  • users.txt: un file che descrive gli utenti da creare

elenco configs contiene defconfig delle nostre schede. Ne abbiamo solo uno.

CONFEZIONE - catalogo con i nostri pacchetti. Inizialmente buildroot contiene descrizioni e regole per la creazione di un numero limitato di pacchetti. Successivamente aggiungeremo qui il window manager icewm e il login manager grafico Slim.
Patch — consente di archiviare comodamente le patch per pacchetti diversi. Maggiori dettagli in una sezione separata di seguito.
Ora dobbiamo aggiungere i file di descrizione per il nostro albero esterno. Ci sono 3 file responsabili di questo: external.desc, Config.in, external.mk.

esterno.desc contiene la descrizione effettiva:

[alexey@alexey-pc my_tree]$ cat external.desc 
name: my_tree
desc: My simple external-tree for article

La prima riga è il titolo. In futuro buildroot creerà una variabile $(BR2_EXTERNAL_MY_TREE_PATH), che deve essere utilizzato durante la configurazione dell'assembly. Ad esempio, il percorso del file utente può essere impostato come segue:

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

La seconda riga è una breve descrizione leggibile dall'uomo.

Configurazione.in, external.mk — file per descrivere i pacchetti aggiunti. Se non aggiungi i tuoi pacchetti, questi file possono essere lasciati vuoti. Per ora, è quello che faremo.
Ora abbiamo pronto il nostro albero esterno, contenente il defconfig della nostra scheda e i file di cui ha bisogno. Andiamo alla directory buildroot e specifichiamo di utilizzare external-tree:

[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
#
# configuration written to /home/alexey/dev/article/ramdisk/buildroot/.config
#
[alexey@alexey-pc buildroot]$ make menuconfig

Nel primo comando usiamo l'argomento BR2_ESTERNO=../mio_albero/, che indica l'uso di un albero esterno. È possibile specificare più alberi esterni da utilizzare contemporaneamente. In questo caso, è necessario farlo solo una volta, dopodiché viene creato un file output/.br-external.mk che memorizza informazioni sull'albero esterno utilizzato:

[alexey@alexey-pc buildroot]$ cat output/.br-external.mk 
#
# Automatically generated file; DO NOT EDIT.
#

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 = My simple external-tree for article

Importante! I percorsi in questo file saranno assoluti!

Nel menu è apparsa una voce Opzioni esterne:

Buildroot - parte 2. Creazione della configurazione della scheda; utilizzando albero esterno, rootfs-overlay, script post-build

Questo sottomenu conterrà i nostri pacchetti dal nostro albero esterno. Questa sezione è attualmente vuota.

Ora è più importante per noi riscrivere i percorsi necessari per utilizzare external-tree.

Tieni presente che nella sezione Opzioni di compilazione → Posizione in cui salvare la configurazione buildroot, ci sarà un percorso assoluto al defconfig salvato. Si forma al momento in cui si specifica l'uso di extgernal_tree.

Correggeremo anche i percorsi nella sezione Configurazione del sistema. Per una tabella con utenti creati:

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

Nella sezione Kernel, modifica il percorso della configurazione del kernel:

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

Ora i nostri file dal nostro albero esterno verranno utilizzati durante l'assemblaggio. Quando ci spostiamo in un'altra directory o aggiorniamo buildroot, avremo un minimo di problemi.

Aggiunta della sovrapposizione root fs:

Questo meccanismo consente di aggiungere/sostituire facilmente i file nel file system di destinazione.
Se il file si trova nell'overlay root fs, ma non nella destinazione, verrà aggiunto
Se il file si trova nell'overlay root fs e nella destinazione, verrà sostituito.
Innanzitutto, impostiamo il percorso per root fs overlay dir. Questo viene fatto nella sezione Configurazione di sistema → Directory di sovrapposizione del filesystem root:

$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/

Ora creiamo due file.

[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

Il primo file (my_tree/board/my_x86_board/rootfs_overlay/etc/hosts) sostituirà il file /etc/hosts sul sistema finito. Verrà aggiunto il secondo file (cat my_tree/board/my_x86_board/rootfs_overlay/new_file.txt).

Raccogliamo e controlliamo:

Buildroot - parte 2. Creazione della configurazione della scheda; utilizzando albero esterno, rootfs-overlay, script post-build

Esecuzione di script di personalizzazione nelle diverse fasi di assemblaggio del sistema

Spesso è necessario eseguire alcune operazioni all'interno del file system di destinazione prima che venga compresso in immagini.

Questo può essere fatto nella sezione Configurazione del sistema:

Buildroot - parte 2. Creazione della configurazione della scheda; utilizzando albero esterno, rootfs-overlay, script post-build

I primi due script vengono eseguiti dopo la creazione del file system di destinazione, ma prima che venga compresso in immagini. La differenza è che lo script fakeroot viene eseguito nel contesto di fakeroot, che simula il lavoro dell'utente root.

L'ultimo script viene eseguito dopo la creazione delle immagini di sistema. Puoi eseguire azioni aggiuntive al suo interno, ad esempio copiare i file necessari su un server NFS o creare un'immagine del firmware del tuo dispositivo.

Ad esempio, creerò uno script che scriverà la versione e la data di compilazione in /etc/.
Per prima cosa indicherò il percorso di questo file nel mio albero esterno:

Buildroot - parte 2. Creazione della configurazione della scheda; utilizzando albero esterno, rootfs-overlay, script post-build

E ora lo script stesso:

[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

Dopo l'assemblaggio, puoi vedere questo file sul sistema.

In pratica lo script può diventare grande. Pertanto, nel progetto reale ho seguito un percorso più avanzato:

  1. Ho creato una directory (my_tree/board_my_x86_board/inside_fakeroot_scripts) in cui ci sono gli script da eseguire, con numeri di serie. Ad esempio, 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh
  2. Ho scritto uno script (my_tree/board_my_x86_board/run_inside_fakeroot.sh) che attraversa questa directory ed esegue in sequenza gli script in essa contenuti
  3. Specificato questo script nelle impostazioni della scheda nella sezione Configurazione di sistema -> Script personalizzati da eseguire all'interno dell'ambiente fakeroot ($(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/run_inside_fakeroot.sh)

Fonte: habr.com

Aggiungi un commento