Dans cette section, je considère certaines des capacités de personnalisation dont j'avais besoin. Ce n'est pas une liste complète de ce que propose buildroot, mais ils fonctionnent assez bien et ne nécessitent aucune intervention dans les fichiers de buildroot lui-même.
Utilisation du mécanisme EXTERNE pour la personnalisation
Dans l'article précédent, nous avons considéré un exemple simple d'ajout de votre configuration en ajoutant le defconfig de la carte et les fichiers nécessaires directement dans le répertoire Buildroot.
Mais cette méthode n'est pas très pratique, surtout lors de la mise à jour de buildroot. Pour résoudre ce problème, il existe un mécanisme d' arborescence externe . Son essence est que vous pouvez stocker board, configs, packages et autres répertoires dans un répertoire séparé (par exemple, j'utilise le répertoire patches pour appliquer des patchs aux packages, plus dans une section séparée) et buildroot les ajoutera à ceux de son propre répertoire.
Remarque: vous pouvez appliquer plusieurs arborescences externes Ă la fois, il y a un exemple dans le manuel de buildroot
Créez le répertoire my_tree situé à côté du répertoire buildroot et transférez-y notre configuration. La sortie doit être la structure de fichiers suivante:
[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
Comme vous pouvez le voir, en général, la structure suit la structure de buildroot.
Le répertoire de la carte contient des fichiers spécifiques à chaque carte dans notre cas:
- bef_cr_fs_img.sh - un script qui sera exécuté après la construction du système de fichiers cible, mais avant de le compresser en images. À l'avenir, nous l'utiliserons
- linux.config - configuration du noyau
- rootfs_overlay - répertoire à superposer au-dessus du système de fichiers cible
- users.txt - fichier avec une description des utilisateurs créés
Le répertoire configs contient les defconfigs de nos cartes. Nous n'en avons qu'un.
Package - un catalogue avec nos packages. Au départ, buildroot contient des descriptions et des règles pour construire un nombre limité de packages. Plus tard, nous ajouterons ici le gestionnaire de fenêtres icewm et le gestionnaire de connexion Slim.
Patches - vous permet de stocker facilement vos patchs pour différents packages. Plus de détails dans une section séparée ci-dessous.
Maintenant, nous devons ajouter les fichiers de description de notre arbre externe. 3 fichiers en sont responsables: external.desc, Config.in, external.mk.
external.desc contient la description réelle:
[alexey@alexey-pc my_tree]$ cat external.desc name: my_tree desc: My simple external-tree for article
La première ligne est le nom. À l'avenir, buildroot créera la variable $ (BR2_EXTERNAL_MY_TREE_PATH) , qui devra être utilisée lors de la configuration de l'assembly. Par exemple, le chemin d'accès au fichier avec les utilisateurs peut être défini de la manière suivante:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
La deuxième ligne est une brève description lisible par l'homme.
Config.in, external.mk - fichiers pour la description des packages ajoutés. Si vous n'ajoutez pas vos packages, ces fichiers peuvent être laissés vides. Jusqu'à présent, nous le ferons.
Maintenant, nous avons notre arbre externe prêt, contenant le defconfig de notre carte et les fichiers dont il a besoin. Nous allons aller dans le répertoire buildroot, nous allons spécifier l'utilisation de l'arborescence externe:
[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
Dans la première commande, nous utilisons l'argument BR2_EXTERNAL = .. / my_tree / , indiquant l'utilisation d'une arborescence externe. Vous pouvez spécifier plusieurs arborescences externes en même temps pour l'utilisation. Il suffit de le faire une fois, après quoi un fichier de sortie / .br-external.mk est créé qui stocke informations sur l'arborescence externe utilisée:
[alexey@alexey-pc buildroot]$ cat output/.br-external.mk
Important! Dans ce fichier, les chemins seront absolus!
Le point de menu Options externes est apparu:
Ce sous-menu contiendra nos packages de notre arbre externe. Maintenant, cette section est vide.
Maintenant, il est plus important pour nous de réécrire les chemins nécessaires pour utiliser un arbre externe.
Notez que dans la section Options de construction → Emplacement pour enregistrer la configuration de buildroot, il y aura un chemin absolu vers le defconfig enregistré. Il est formé au moment de spécifier l'utilisation de extgernal_tree.
Toujours dans la section Configuration système, corrigez les chemins. Pour une table avec création d'utilisateur:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
Dans la section Kernel, changez le chemin d'accès à la configuration du noyau:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/linux.config
Maintenant, l'assembly utilisera nos fichiers de notre arbre externe. Lors du transfert vers un autre répertoire, la mise à jour de buildroot, nous aurons un minimum de problèmes.
Ajout d'une superposition fs racine:
Ce mécanisme facilite l'ajout / le remplacement de fichiers dans le système de fichiers cible.
Si le fichier est en superposition fs racine mais pas dans la cible, il sera ajouté
Si le fichier est en superposition fs racine et en cible, il sera remplacé.
Tout d'abord, définissez le chemin d'accès au répertoire de superposition fs racine. Cela se fait dans la section Configuration système → Répertoires de superposition du système de fichiers racine:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/
Créons maintenant deux fichiers.
[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
Le premier fichier (my_tree / board / my_x86_board / rootfs_overlay / etc / hosts) remplacera le fichier / etc / hosts sur le système terminé. Un deuxième fichier (cat my_tree / board / my_x86_board / rootfs_overlay / new_file.txt) sera ajouté.
Nous collectons et vérifions:
Exécution de scripts de personnalisation à différentes étapes de l'assemblage du système
Souvent, vous devez effectuer certaines actions à l'intérieur du système de fichiers cible avant qu'il ne soit compressé en images.
Cela peut être fait dans la section Configuration du système:
Les deux premiers scripts sont exécutés après la construction du système de fichiers cible, mais avant de le compresser en images. La différence est que le script fakeroot est exécuté dans le contexte du fakeroot, ils simulent le travail de l'utilisateur root.
Le dernier script est exécuté après la création des images système. Vous pouvez y effectuer des actions supplémentaires, par exemple, copier les fichiers nécessaires sur le serveur nfs ou créer une image du micrologiciel de votre appareil.
Par exemple, je vais créer un script qui va écrire la version et la date de construction dans / etc /.
Tout d'abord, je vais indiquer le chemin d'accès à ce fichier dans mon arborescence externe:
Et maintenant, le script lui-mĂŞme:
[alexey@alexey-pc buildroot]$ cat ../my_tree/board/my_x86_board/bef_cr_fs_img.sh
Après l'assemblage, vous pouvez voir ce fichier dans le système.
En pratique, un script peut devenir gros. Par conséquent, dans un vrai projet, je suis allé de manière plus avancée:
- Création d'un répertoire (my_tree / board_my_x86_board / inside_fakeroot_scripts), dans lequel se trouvent les scripts d'exécution, avec des numéros de série. Par exemple, 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh
- J'ai écrit un script (my_tree / board_my_x86_board / run_inside_fakeroot.sh) qui passe par ce répertoire et exécute séquentiellement les scripts qu'il contient
- Ce script indiqué dans les paramètres de la carte dans la configuration du système -> Scripts personnalisés à exécuter dans l'environnement fakeroot ($ (BR2_EXTERNAL_my_tree_PATH) /board/my_x86_board/run_inside_fakeroot.sh)