En esta sección, considero algunas de las capacidades de personalización que necesitaba. Esta no es una lista completa de lo que ofrece buildroot, pero funcionan bastante y no requieren intervención en los archivos de buildroot.
Usando el mecanismo EXTERNO para la personalización
En el artículo anterior, consideramos un ejemplo simple de agregar su configuración agregando el defconfig de la placa y los archivos necesarios directamente al directorio Buildroot.
Pero este método no es muy conveniente, especialmente al actualizar buildroot. Para resolver este problema, hay un mecanismo de árbol externo . Su esencia es que puede almacenar el tablero, las configuraciones, los paquetes y otros directorios en un directorio separado (por ejemplo, uso el directorio de parches para aplicar parches a paquetes, más en una sección separada) y buildroot los agregará a aquellos en su propio directorio.
Nota: puede aplicar varios árboles externos a la vez, hay un ejemplo en el manual de buildroot
Cree el directorio my_tree junto al directorio buildroot y transfiera nuestra configuración allí. El resultado debe ser la siguiente estructura de archivos:
[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
Como puede ver, en general, la estructura sigue la estructura de buildroot.
El directorio de la placa contiene archivos específicos para cada placa en nuestro caso:
- bef_cr_fs_img.sh: un script que se ejecutará después de compilar el sistema de archivos de destino, pero antes de empaquetarlo en imágenes. En el futuro lo usaremos
- linux.config - configuración del kernel
- rootfs_overlay - directorio para superponer en la parte superior del sistema de archivos de destino
- users.txt: archivo con una descripción de los usuarios creados
El directorio configs contiene los defconfigs de nuestros tableros. Solo tenemos uno.
Paquete : un catálogo con nuestros paquetes. Inicialmente, buildroot contiene descripciones y reglas para construir un número limitado de paquetes. Más adelante agregaremos el administrador de ventanas icewm y el administrador de inicio de sesión Slim aquí.
Parches : le permite almacenar convenientemente sus parches para diferentes paquetes. Más detalles en una sección separada a continuación.
Ahora necesitamos agregar los archivos de descripción de nuestro árbol externo. 3 archivos son responsables de esto: external.desc, Config.in, external.mk.
external.desc contiene la descripción real:
[alexey@alexey-pc my_tree]$ cat external.desc name: my_tree desc: My simple external-tree for article
La primera línea es el nombre. En el futuro, buildroot crea la variable $ (BR2_EXTERNAL_MY_TREE_PATH) , que debe usarse al configurar el ensamblado. Por ejemplo, la ruta al archivo con usuarios se puede configurar de la siguiente manera:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
La segunda línea es una descripción breve, legible por humanos.
Config.in, external.mk : archivos para la descripción de los paquetes agregados. Si no agrega sus paquetes, estos archivos se pueden dejar vacíos. Hasta ahora lo haremos.
Ahora tenemos nuestro árbol externo listo, que contiene el defconfig de nuestra placa y los archivos que necesita. Iremos al directorio buildroot, especificaremos el uso del árbol externo:
[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
En el primer comando, usamos el argumento BR2_EXTERNAL = .. / my_tree / , que indica el uso de un árbol externo. Puede especificar varios árboles externos para usar al mismo tiempo. Es suficiente hacer esto una vez, después de lo cual se crea un archivo output / .br-external.mk que almacena información sobre el árbol externo usado:
[alexey@alexey-pc buildroot]$ cat output/.br-external.mk
Importante! ¡En este archivo, las rutas serán absolutas!
Aparece el elemento de menú Opciones externas:
Este submenú contendrá nuestros paquetes de nuestro árbol externo. Ahora esta sección está vacía.
Ahora es más importante para nosotros reescribir las rutas necesarias para usar un árbol externo.
Tenga en cuenta que en la sección Opciones de compilación → Ubicación para guardar la configuración de compilación de raíz, habrá una ruta absoluta a la configuración de configuración guardada. Se forma al momento de especificar el uso de extgernal_tree.
También en la sección Configuración del sistema, arregle las rutas. Para una tabla con usuario creado:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
En la sección Kernel, cambie la ruta a la configuración del kernel:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/linux.config
Ahora, el ensamblado usará nuestros archivos de nuestro árbol externo. Al transferir a otro directorio, actualizar buildroot, tendremos un mínimo de problemas.
Agregar superposición de fs raíz:
Este mecanismo facilita agregar / reemplazar archivos en el sistema de archivos de destino.
Si el archivo está en la superposición de la raíz fs pero no en el destino, se agregará
Si el archivo se encuentra en la superposición de fs raíz y en el destino, se reemplazará.
Primero, configure la ruta al directorio raíz de superposición fs. Esto se hace en la sección Configuración del sistema → Directorios de superposición del sistema de archivos raíz:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/
Ahora creemos dos archivos.
[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
El primer archivo (my_tree / board / my_x86_board / rootfs_overlay / etc / hosts) reemplazará el archivo / etc / hosts en el sistema terminado. Se agregará un segundo archivo (cat my_tree / board / my_x86_board / rootfs_overlay / new_file.txt).
Recopilamos y verificamos:
Ejecución de scripts de personalización en diferentes etapas del ensamblaje del sistema.
A menudo, debe realizar algunas acciones dentro del sistema de archivos de destino antes de empaquetarlo en imágenes.
Esto se puede hacer en la sección Configuración del sistema:
Los primeros dos scripts se ejecutan después de construir el sistema de archivos de destino, pero antes de empaquetarlo en imágenes. La diferencia es que el script fakeroot se ejecuta en el contexto del fakeroot, simulan el trabajo del usuario root.
El último script se ejecuta después de crear las imágenes del sistema. Puede realizar acciones adicionales en él, por ejemplo, copiar los archivos necesarios a un servidor nfs o crear una imagen del firmware de su dispositivo.
Como ejemplo, crearé un script que escribirá la versión y la fecha de compilación en / etc /.
Primero, indicaré la ruta a este archivo en mi árbol externo:
Y ahora el script en sí:
[alexey@alexey-pc buildroot]$ cat ../my_tree/board/my_x86_board/bef_cr_fs_img.sh
Después del ensamblaje, puede ver este archivo en el sistema.
En la práctica, un guión puede hacerse grande. Por lo tanto, en un proyecto real, fui de una manera más avanzada:
- Creó un directorio (my_tree / board_my_x86_board / inside_fakeroot_scripts), en el que se encuentran los scripts para la ejecución, con números de serie. Por ejemplo, 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh
- Escribí un script (my_tree / board_my_x86_board / run_inside_fakeroot.sh) que recorre este directorio y ejecuta secuencialmente los scripts en él
- Este script se indica en la configuración de la placa en Configuración del sistema -> Scripts personalizados para ejecutarse dentro del entorno fakeroot ($ (BR2_EXTERNAL_my_tree_PATH) /board/my_x86_board/run_inside_fakeroot.sh)