【Trasplante de Yocto】Intercambio de tecnología

Enterprise 2023-07-26 05:46:00 views: null

Uso de Yocto para construir un sistema Linux integrado

prefacio

En términos generales, un sistema completo de Linux integrado incluye principalmente U-Boot, kernel de Linux y sistema de archivos raíz. Construir un sistema Linux integrado es en realidad trasplantar U-Boot, el kernel de Linux y el sistema de archivos raíz a la plataforma de hardware utilizada y, de acuerdo con las necesidades reales del proyecto, puede implicar agregar software proporcionado por un tercero al sistema integrado integrado. el sistema Linux, para que el programa de aplicación pueda cumplir con los requisitos del producto de forma rápida, conveniente y confiable. Hay muchas formas y herramientas para construir un sistema Linux integrado.Este artículo utiliza Yocto para construir un sistema Linux integrado que se ejecuta en la plataforma imx8mm de NXP. El Proyecto Yocto es bien conocido en el mundo de Linux embebido por su flexibilidad y facilidad de uso. El propósito del proyecto Yocto es crear una distribución de Linux para fabricantes de hardware y software integrados Muchos fabricantes de placas base utilizan Yocto para crear la distribución de Linux integrada correspondiente. Este intercambio sirve como una introducción básica a Yocto para ayudarlo a comprender el proceso y el método básicos para construir un sistema Linux integrado basado en Yocto.

1. Obtenga el código fuente del software Yocto

Cambie a la ruta de trabajo de Yocto /opt/work/yocto-kirkstone, y luego use el siguiente comando repo para obtener el proyecto Yocto (clone la rama imx-linux-kirkstone del proyecto oficial imx-manifest.git de NXP):

repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-kirkstone -m imx-5.15.32-2.0.0.xml

Nota: antes de ejecutar las instrucciones anteriores, debe instalar Python3 en el entorno ubuntu

Una vez completada la clonación, /opt/work/yocto-kirkstonehay archivos en el directorio /.repo/manifests/imx-5.15.32-2.0.0.xml, que definen qué bibliotecas Git se usaron en la rama imx-linux-kirkstone. Finalmente, en /opt/work/yocto-kirkstoneel directorio, ejecute repo syncel comando para obtener el proyecto Yocto.

Después de obtener con éxito el código fuente del proyecto Yocto, obtendrá /opt/work/yocto-kirkstone/, imx-setup-release.shy otros archivos en la ruta de trabajo de Yocto setup-environment. en:sources
inserte la descripción de la imagen aquí

  • imx-setup-release.sh: este script se usa para inicializar Yocto para construir el entorno de trabajo del sistema Linux integrado.
  • setup-environment: este script configura el entorno de trabajo de Yocto de acuerdo con imx-setup-release.shlos parámetros ingresados ​​al ejecutar el script MACHINEy .DISTRO-b <build_dir>
  • Carpeta de fuentes: muchos archivos se almacenan en esta carpeta, incluidos algunos códigos fuente y herramientas de compilación, que se utilizan para construir sistemas Linux integrados.
    inserte la descripción de la imagen aquí
  • base: esta carpeta almacena principalmente bblayers.conf y setup-environment, que se utilizan al construir el entorno de trabajo de Yocto.
  • meta-advantech: El desarrollo de proyectos utiliza esta capa.
  • meta-clang: frontend de la familia del lenguaje C y backend del compilador LLVM.
  • metanavegador : proporciona varios navegadores, como gnome, mozilla.
  • meta-freescale : proporciona un software de soporte básico basado en la placa de referencia oficial de Freescale ARM.
  • metaimx :
    • meta-bspIncluyendo la información de configuración de uboot y kernel, los directorios son
      sources/meta-imx/meta-bsp/recipes-bsp/u-boot
      sources/meta-imx/meta-bsp/recipes-kernel
    • meta-sdkIncluir algún software actualizado, como el archivo bbappend de Google Chrome que se encuentra en este directorio
      sources/meta-imx/meta-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium
    • meta-ml: Software relacionado con el aprendizaje automático.
  • meta-freescalse-distro: algunas distribuciones oficiales de Linux integradas.
  • meta-freescalse-3rdparty: software de soporte de placa de terceros.
  • meta-nxp-demo-experience: algunas demostraciones proporcionadas oficialmente por NXP NXP.
  • meta-openembedded: Algunas colecciones de kernels OE, que definen algún software de herramienta utilizado para construir Yocto.
  • meta-qt6: software relacionado con QT6.
  • poky: La distribución básica de Yocto , en base a esta versión, crea tu propia distribución embebida de Linux.

Cabe señalar que la configuración de la placa se define i.MXprincipalmente en meta-imxy , incluido el kernel y cierta información de configuración de hardware a nivel de placa.meta-freescaleLinuxU-Boot

2. Inicialice el directorio de compilación de Yocto

Después de obtener el código fuente del proyecto Yocto a través del repositorio, también debe inicializar el directorio de compilación de Yocto, que se usa para que Yocto construya el entorno de trabajo del sistema Linux integrado (realmente crea algunas carpetas, inicializa algunos valores de variables y obtiene archivos de configuración para crear distribuciones de Linux integradas específicas). Bajo la ruta de origen del proyecto Yocto (/opt/work/yocto-kirkstone/) obtenida por repositorio, Freescales proporciona el script imx-setup-release.sh.

Se ejecuta el script 2.1.imx-setup-release.sh

Ingrese el siguiente comando en la ruta donde se encuentra imx-setup-release.sh para ejecutar el script imx-setup-release.sh

MACHINE=imx8mmeamb9918a1 DISTRO=fsl-imx-xwayland source  imx-setup-release.sh -b eamb9918a1

imx-setup-release.shDespués de que se ejecute el script, primero leerá algunas licencias EULA. Una vez completada la lectura, se completa la inicialización del directorio de compilación de Yocto.
Una vez que el script termine de ejecutarse, eamb9918a1se generará automáticamente una carpeta y se cambiará a eamb9918a1la ruta. El proceso de construcción del sistema posterior se completa en esta carpeta. Al mismo tiempo, en la carpeta eamb9918a1, se generará una carpeta conf:
inserte la descripción de la imagen aquí
hay dos archivos importantes en la carpeta conf: bblayers.confy local.confdos archivos de configuración:

  • eamb9918a1/conf/bblayer.conf: este archivo de configuración define las metacapas necesarias para construir la distribución del sistema Linux integrado.
  • eamb9918a1/conf/local.conf: este archivo de configuración define los elementos de configuración de MACHINE y DISTRO .

Análisis del script 2.2.imx-setup-release.sh

Cuando se ejecuta el script imx-setup-release.sh, se deben ingresar tres parámetros principales:

  • MACHINE=imx8mmeamb9918a1
  • DISTRO=fsl-imx-xwayland
  • -beamb9918a1

En general, el script imx-setup-release.sh determina el entorno de compilación a través de estos tres parámetros, entre los cuales se genera una carpeta eamb9918a1-b eamb9918a1 para almacenar los archivos temporales, los registros de compilación y los archivos de instalación finales generados, etc. Al mismo tiempo, Yocto encuentra los archivos de configuración correspondientes (.conf) de acuerdo con estos dos parámetros, y estos archivos de configuración definen las funciones y el estado del sistema Linux embebido que se construirá. Por ejemplo:DISTROMACHINE

  • El script imx-setup-release.sh encontrará el archivo .conf correspondiente al valor de DISTRO en la ruta de origen según el valor de DISTRO, por ejemplo: encontrará el archivo en la ruta , en el que se encuentran algunas variables. definido, use Para configurar distribuciones de Linux integradas. Al mismo tiempo, se encuentra que debajo de la ruta se define la plataforma de hardware que admite la configuración del sistema Linux integrado.DISTRO= fsl-imx-xwaylandsources/meta-imx/meta-sdk/conf/distrofsl-imx-xwayland.confsources/meta-imx/meta-bsp/conf/machine
  • imx-setup-release.sh encontrará el archivo .conf correspondiente al valor de MÁQUINA en la ruta de origen según el valor de MÁQUINA, por ejemplo: MACHINE= imx8mmeamb9918a1encontrará el archivo sources/meta-advantech/meta-adv-imx/conf/machineen la ruta imx8mmeamb9918a1.conf, en el que se definen algunas variables para Configurar la plataforma de hardware en la que se ejecuta Linux incorporado.

2.3. Se ejecuta el script del entorno de instalación

En el script imx-setup-release.sh , el script del entorno de instalación se DISTRO=$FSLDISTRO MACHINE=$MACHINE . ./$PROGNAME $BUILD_DIRllamará .

# Set up the basic yocto environment
if [ -z "$DISTRO" ]; then
   DISTRO=$FSLDISTRO MACHINE=$MACHINE . ./$PROGNAME $BUILD_DIR
else
   MACHINE=$MACHINE . ./$PROGNAME $BUILD_DIR
fi

Vea la información de ayuda de la secuencia de comandos del entorno de configuración , que enumera las MÁQUINAS admitidas en la ruta de Yocto y también explica cómo usar la secuencia de comandos del entorno de configuración .

usage()
{
    
    
    echo -e "
Usage: MACHINE=<machine> DISTRO=<distro> source $PROGNAME <build-dir>
Usage:                                   source $PROGNAME <build-dir>
    <machine>    machine name
    <distro>     distro name
    <build-dir>  build directory

The first usage is for creating a new build directory. In this case, the
script creates the build directory <build-dir>, configures it for the
specified <machine> and <distro>, and prepares the calling shell for running
bitbake on the build directory.

The second usage is for using an existing build directory. In this case,
the script prepares the calling shell for running bitbake on the build
directory <build-dir>. The build directory configuration is unchanged.
"

    ls sources/meta-advantech/*/conf/machine/*.conf > /dev/null 2>&1
    ls sources/meta-freescale-distro/conf/distro/fslc-*.conf > /dev/null 2>&1
    if [ $? -eq 0 ]; then
        echo -e "
Supported machines: `echo; ls sources/meta-advantech/*/conf/machine/*.conf \
| sed s/\.conf//g | sed -r 's/^.+\///' | xargs -I% echo -e "\t%"`

Supported Freescale's distros: `echo; ls sources/meta-freescale-distro/conf/distro/fslc-*.conf \
| sed s/\.conf//g | sed -r 's/^.+\///' | xargs -I% echo -e "\t%"`

Available Poky's distros: `echo; ls sources/poky/meta-poky/conf/distro/*.conf \
| sed s/\.conf//g | sed -r 's/^.+\///' | xargs -I% echo -e "\t%"`

Examples:

- To create a new Yocto build directory:
  $ MACHINE=imx8mmeamb9918a1 DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b imx8mmeamb9918a1

- To use an existing Yocto build directory:
  $ source $PROGNAME build
"
    fi
}

Al comparar las secuencias de comandos imx-setup-release.sh y setup-environment, la secuencia de comandos imx-setup-release.sh completa principalmente las operaciones relacionadas con la licencia de EULA y escribe la capa, la máquina, la distribución y otra información en los archivos de configuración; script de entorno, complete la creación del directorio de compilación emab9918 y busque el archivo de configuración en la ruta correspondiente de acuerdo con los dos parámetros de DISTRO y MACHINE, y prepare el entorno para llamar al shell para ejecutar la herramienta de compilación bitbake en el directorio de compilación.

3. Cree un sistema Linux integrado

3.1 Breve análisis del proceso del sistema de compilación de BitBake

El primer paso en una compilación de Bitbake es analizar los archivos de configuración de la base de metadatos que determinan algunas de las capacidades y características de la distribución del sistema Linux incorporado que se está compilando.
Primero comprendamos algunos conceptos
de metadatos : después de obtener el proyecto yocto a través del repositorio, hay algunas carpetas en el directorio de origen, y estas carpetas son metadatos uno por uno . Cuando se usa bitbake para compilar el sistema, los metadatos que se usarán se imx-setup-release.shdeterminan cuando se inicializa el script. Bajo la ruta build/conf/ , se genera un archivo de configuración bblayers.conf y la herramienta bitbake se basará en bblayers.conf file La definición en determina qué metadatos usar.recetas : en los metadatos, hay muchos archivos almacenados en la carpeta source/meta-xxx, de los cuales: el
inserte la descripción de la imagen aquí
archivo bbclass en esta carpeta, el archivo bbclass guarda la función o variable general, Puede ser referenciado por la palabra claveHeredar en otras recetas . Un poco similar al concepto de clases en C++. : El archivo layer.conf debajo de la carpeta conf define qué archivos .bb y .bbappend utilizados en los metadatos participan en la construcción del sistema Linux integrado. : Hay muchos archivos .bb o .bbappend en esta carpeta, que definen los paquetes de software o los códigos fuente necesarios para compilar el sistema Linux integrado, que incluyen principalmente:
inserte la descripción de la imagen aquí

classes
conf
recipes-xxx

  • Información básica del paquete de software: autor, página de inicio, licencia, etc.
  • Información de versión
  • archivo dependiente
  • Dónde y cómo descargar paquetes
  • Información del parche del paquete de software: si se requiere un parche, dirección y método de descarga del parche, etc.
  • Cómo configurar, cómo compilar el paquete de software, ubicación de instalación, etc.
    Tome el archivo bb del paquete u-boot como ejemplo:
qing@Qing:/opt/work/yocto-kirkstone/sources/meta-imx/meta-bsp/recipes-bsp/u-boot$ cat u-boot-imx_2022.04.bb 
# Copyright (C) 2013-2016 Freescale Semiconductor
# Copyright 2018 (C) O.S. Systems Software LTDA.
# Copyright 2017-2022 NXP

require recipes-bsp/u-boot/u-boot.inc
###############################################################
########### For upstream u-boot-imx-common_2022.04.inc ########
DESCRIPTION = "i.MX U-Boot suppporting i.MX reference boards."

LICENSE = "GPL-2.0-or-later"
LIC_FILES_CHKSUM = "file://Licenses/gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263"

UBOOT_SRC ?= "git://source.codeaurora.org/external/imx/uboot-imx.git;protocol=https"
SRCBRANCH = "lf_v2022.04"
SRC_URI = "${UBOOT_SRC};branch=${SRCBRANCH}"
SRCREV = "1c881f4da83cc05bee50f352fa183263d7e2622b"
LOCALVERSION = "-${SRCBRANCH}"

DEPENDS += "flex-native bison-native bc-native dtc-native gnutls-native"

S = "${WORKDIR}/git"
B = "${WORKDIR}/build"

inherit fsl-u-boot-localversion

BOOT_TOOLS = "imx-boot-tools"

###############################################################
# require recipes-bsp/u-boot/u-boot-imx-common_${
      
      PV}.inc

PROVIDES += "u-boot"

inherit uuu_bootloader_tag

UUU_BOOTLOADER            = ""
UUU_BOOTLOADER:mx6-nxp-bsp        = "${UBOOT_BINARY}"
UUU_BOOTLOADER:mx7-nxp-bsp        = "${UBOOT_BINARY}"
UUU_BOOTLOADER_TAGGED     = ""
UUU_BOOTLOADER_TAGGED:mx6-nxp-bsp = "u-boot-tagged.${UBOOT_SUFFIX}"
UUU_BOOTLOADER_TAGGED:mx7-nxp-bsp = "u-boot-tagged.${UBOOT_SUFFIX}"

do_deploy:append:mx8m-nxp-bsp() {
    
    
    # Deploy u-boot-nodtb.bin and fsl-imx8m*-XX.dtb for mkimage to generate boot binary
    if [ -n "${UBOOT_CONFIG}" ]
    then
        for config in ${
    
    UBOOT_MACHINE}; do
            i=$(expr $i + 1);
            for type in ${
    
    UBOOT_CONFIG}; do
                j=$(expr $j + 1);
                if [ $j -eq $i ]
                then
                    install -d ${
    
    DEPLOYDIR}/${
    
    BOOT_TOOLS}
                    install -m 0777 ${
    
    B}/${
    
    config}/arch/arm/dts/${
    
    UBOOT_DTB_NAME}  ${
    
    DEPLOYDIR}/${
    
    BOOT_TOOLS}
                    install -m 0777 ${
    
    B}/${
    
    config}/u-boot-nodtb.bin  ${
    
    DEPLOYDIR}/${
    
    BOOT_TOOLS}/u-boot-nodtb.bin-${
    
    MACHINE}-${
    
    type}
                fi
            done
            unset  j
        done
        unset  i
    fi
}

PACKAGE_ARCH = "${MACHINE_ARCH}"
COMPATIBLE_MACHINE = "(mx6-generic-bsp|mx7-generic-bsp|mx8-generic-bsp)"

bbappendArchivos: los archivos .bbappend se utilizan para ampliar o anular la información del archivo de recetas. Cada archivo bbappend tiene un archivo de receta correspondiente, los dos archivos usan el mismo nombre de archivo, pero el sufijo es diferente. Por ejemplo u-boot-imx_2022.04.bby u-boot-imx_2022.04.bbappend. También se puede %utilizar como comodín en los nombres de los archivos de recetas. Por ejemplo, un busybox_1.21.%.bbappendarchivo adjunto llamado puede extender y sobrescribir cualquier archivo de recetas llamado busybox_1.21.x.bb, y la x en el nombre del archivo puede ser cualquier cadena, como busybox_1.21.1.bb, busybox_1.21.2.bb... Por lo general, utilice el signo de porcentaje como comodín para el número de versión.

Después de aclarar los conceptos anteriores, hablemos sobre el proceso de construcción de bitbake
En general , bitbake encuentra el directorio meta-layers/conf correspondiente de acuerdo con las meta-capas habilitadas definidas en build/conf/bblayers.conf layer.conf. En layer.conf, las recetas utilizadas en la capa actual se especifican mediante bbFILESy . bbPATHEs decir, a través de bbPATH, decirle a bitbake en qué rutas, qué archivos .bb y .bbappend buscar, y decirle a bitbake a través de estos archivos qué paquetes de software o códigos fuente se utilizarán para construir la distribución integrada de Linux. Cuando se analiza la receta, se generará una " lista de tareasbitbake -s " y puede usar comandos para enumerar todas las tareas construibles en el proyecto actual. El siguiente paso es que bitbake construye el sistema de acuerdo a la " lista de tareas" De hecho, en el proceso de construcción del sistema, se lleva a cabo en forma de tareas.

3.2 Breve análisis de las tareas del sistema de compilación de BitBake

Al ejecutar el método más simple para crear un paquete bitbake <package_name>, bitbake buscará el archivo de receta de este paquete, analizará las opciones de configuración en la receta después de encontrarlo y luego realizará las siguientes tareas en secuencia:

  • do_fetch descargar código fuente
  • do_unpack descomprime el código fuente
  • do_patch para parchear el código fuente
  • configuración do_configure
  • hacer_compilar compilar
  • instalación do_install, copie el archivo en el directorio de destino
  • do_package genera el paquete de instalación
    y también puede ejecutar tareas individuales a través del parámetro **-c**, por ejemplo, solo descargando el código fuente puede ejecutar bitbake -c fetch .

3.2.1 Obtener el código fuente

El proceso de obtención del código fuente se completa con la tarea do_fetch , que está controlada principalmente por la variable SRC_URI , que puede especificar la ubicación del código fuente, el protocolo para obtener el código fuente, etc. Hay tres fuentes de código fuente: versiones de proyectos anteriores , archivos de proyectos locales y administradores de versiones de código como git/svn .
Los lanzamientos de proyectos anteriores existen en forma de archivos de almacenamiento, como: zip, paquetes tar, etc.
El código fuente publicado a través del administrador de control de versiones generalmente se descarga mediante el protocolo git/svn. Por ejemplo, si usa este método para especificar el código fuente, cuando bitbake ejecuta la tarea do_fetch en el proceso de construcción del sistema Linux , clonará el código fuente para participar en la construcción del sistema de acuerdo con las variables SRC_URI y SRCREV definidas en la receta Además, si el código fuente se obtiene como archivo comprimido, la tarea do_unpack liberará el código fuente en la ruta señalada por la variable ${S}. El valor predeterminado de S es ${WORKDIR} / ${BPN} - ${PV}. Si se descarga el paquete de código fuente y la estructura interna del paquete se ajusta a la convención del subdirectorio de nivel superior ${BPN} - ${PV}, entonces no hay necesidad de configurar S. Sin embargo, si el paquete comprimido no se ajusta a esta convención, o si el código fuente se clona desde un servidor de administración de versiones como git, debe establecer manualmente S. Por ejemplo, git clonará el código fuente en la ruta ${WORKDIR}/git, por lo que este valor debe establecerse en la receta.
La siguiente imagen es un diagrama esquemático de cómo obtener y liberar el código fuente:
inserte la descripción de la imagen aquí
como en el archivo linux-imx_5.15.bb, debe establecer manualmente el valor de S:

KERNEL_SRC = "git://github.com/Advantech-IIoT/linux-imx.git;protocol=https;branch=${SRCBRANCH}"
SRC_URI = "${KERNEL_SRC}"
SRCREV = "065aa1f91e58e1108720dc701a074760be878962"

S = "${WORKDIR}/git"

El código fuente final se descargará en eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/linux-imx/5.10.72+gitAUTOINC+b8bb4918e6-r0/gitla ruta.

3.2.2 Aplicación de parches

Una vez que el software obtiene el código fuente, debe parchearse. En SRC_URI, patch, .diff o el paquete comprimido diff.gz con estos sufijos son todos códigos de parche. El parche se aplica automáticamente cuando se ejecuta la tarea do_patch. Por lo general, colocamos los archivos de parches en una carpeta llamada ${BP} ${BPN} o archivos al lado del archivo de recetas.
Entre ellos, los archivos de parche se colocan en el directorio de archivos.

root@ning-QiTianM620-N000:sources/meta-advantech/meta-adv-imx/recipes-extended/cpio# ls
cpio_%.bbappend  files
root@ning-QiTianM620-N000:sources/meta-advantech/meta-adv-imx/recipes-extended/cpio/files$ ls
0001-Wrong-CRC-with-ASCII-CRC-for-large-files.patch

Entre ellos, el archivo de parche se coloca en el directorio chromium-ozone-wayland, que es una carpeta creada con el nombre de receta ${BPN} del paquete de compilación.

root@ning-QiTianM620-N000:/recipes-browser/chromium/chromium-ozone-wayland# ls
0001-Add-knob-for-imx-gpu.patch

3.2.3 Configuración

La mayoría del software debe configurarse antes de compilarse, generalmente de las siguientes tres maneras:

  1. Autotools: si hay un archivo configure.ac en el archivo de origen, entonces el software se compila con Autotools y el archivo de recetas debe heredar la clase autotools (heredar autotools). En este caso, no es necesario incluir do_configure Es posible que deba configurar EXTRA_OECONF o PACKAGE_CONFARGS para pasar las opciones de configuración requeridas.
  2. CMake: si hay un archivo CMakeLists en el archivo fuente, entonces su software está construido con CMake, el archivo de recetas necesita heredar la clase cmake (heredar cmake) y no tiene que contener la tarea do_configure, puede hacer algunos ajustes configurando EXTRA_OECMAKE.
  3. Otros; en otros casos, debe proporcionar una tarea do_configure en la receta para la configuración.

3.2.4 Compilar

Después de que la configuración sea exitosa, el sistema llamará automáticamente a la tarea do_compile para compilar.

3.2.5 Instalación

Durante la instalación, la estructura de archivos y directorios generada por la tarea do_install de la llamada al sistema se copia en la ubicación del espejo en el dispositivo de destino. Los archivos de los directorios ${S} ${B} y ${WORKDIR} se copiarán en el directorio ${D} para crear la estructura en el sistema de destino. Para los paquetes de software creados con autotools y cmake, el sistema llamará a sus comandos de instalación para realizar las tareas de instalación. En otros casos, debe modificar o escribir manualmente la tarea do_install. Podemos definir una función do_install en la receta y luego agregar instrucciones de instalación.
Si desea instalar manualmente, primero debe usar install -d en la función do_install para crear un directorio bajo ${D}. Una vez que existen estos directorios, puede usar install para instalar archivos manualmente en estos directorios.
Tome la función do_install en un archivo .bb como ejemplo para ilustrar lo siguiente:

do_install() {
    
    	
	install -d ${
    
    D}/usr/bin/
    install -m 755 ${
    
    S}/bin/gester ${
    
    D}/usr/bin/
}

3.2.6 Embalaje

Si usa cmake o Autotools, este paso también es automático; de lo contrario, debe escribir una función do_package.

4. Sistema Linux integrado personalizado

El sistema Yocto organiza y administra los paquetes de software, el código fuente, la información de configuración, etc. utilizados por el sistema de compilación en forma de metadatos. Hasta cierto punto, los metadatos pueden entenderse como capas, que en realidad son carpetas una por una (estas carpetas generalmente se nombran en forma de meta-xxx).
El uso de capas para administrar los datos de origen es propicio para mantener un método de diseño modular. Una capa contiene los datos de origen requeridos por algunas funciones específicas, y cada capa no interfiere entre sí. Cuando las funciones requeridas por el sistema construido cambian, solo es necesario modificar la capa correspondiente a esta función, que mantiene la independencia y diseño modular de la función.

4.1 Crear meta-micapa

Hay dos formas de crear una metacapa, una es crearla manualmente y la otra es usar el comando bitbake-layers para crearla. Cabe señalar que antes de crear una capa, puede http://layers.openembedded.org/layerindex/layers/verificar la capa existente en .Si la capa a crear ya existe, puede usarla directamente. Si no, tendrás que crearlo tú mismo.

4.1.1 Creación automática

bitbake-layers create-layer meta-mylayer

4.1.2 Creación manual

1. Cree una carpeta para almacenar los datos en la capa, generalmente llamada meta-xxx. Por ejemplo: meta-micapa.
2. Cree un archivo de configuración de capas. Cree un archivo conf/layer.conf en la carpeta de capas recién creada (por ejemplo: meta-mylayer).El marco básico del archivo layer.conf es el siguiente:

# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
   ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "mylayer"
BBFILE_PATTERN_mylayer = "^${LAYERDIR}/"
BBFILE_PRIORITY_mylayer = "5"

Entre ellos, los significados de cada variable son los siguientes:
(1) BBPATH: agregue la ruta de la capa recién agregada a la variable global BBPATH, y bitbake encontrará la capa correspondiente de acuerdo con esta variable al construir el sistema.
(2) BBFILES: agregue el archivo de receta (es decir, archivo .bb o .bbappend) en la capa recién agregada a la variable global BBFILES, y bitbake encontrará el archivo de receta correspondiente de acuerdo con esta variable al construir el sistema.
(3) BBFILE_COLLECTIONS: Agregue el nombre de la capa a la variable bbFILE_COLLECTIONS, es decir, asigne xxx en la carpeta de la capa nombre meta-xxx a BBFILE_COLLECTIONS.
(4) BBFILE_PATTERN: La variable BBFILE_PATTERN es una expresión regular, que se utiliza para hacer coincidir los archivos definidos en BBFILES en una capa específica.Esta variable debe tener como prefijo el nombre de la capa específica.
(5) BBFILE_PRIORITY: La prioridad de la capa. Cuando se define la misma receta en diferentes capas, se utilizará el archivo de receta correspondiente según la prioridad alta correspondiente a BBFILE_PRIORITY.
3. Agregue contenido. De acuerdo con el tipo de capa, algunas capas agregarán configuraciones de máquina y distribución. Por lo tanto, debe agregar configuraciones de máquina en el archivo conf/machine/ debajo de la Capa, y agregar configuraciones de distribución en el archivo conf/distro/ en esta capa.

4.2 Habilitar meta-micapa

Después de crear una nueva capa, debe habilitarse antes de que pueda participar en el proceso de construcción del sistema. Las capas utilizadas por el sistema de compilación participante se definen en eamb9918a1/config/bblayers.conf. Freescale proporciona oficialmente el script imx-setup-release.sh para modificar el archivo eamb9918a1/conf/bblayers.conf Al inicializar el directorio de compilación de Yocto, llame al script imx-setup-release.sh. Por lo tanto, simplemente modifique el script imx-setup-release.sh, y el método de modificación es el siguiente:
inserte la descripción de la imagen aquí
También puede bitbake-layers add-layer meta-mylayeragregar meta-mylayer al archivo bblayers.conf ejecutando el directorio relativo de meta-mylayer.

cd /opt/work/yocto-kirkstone/eamb9918a1
bitbake-layers add-layer ./sources/meta-mylayer

4.3 Crear recetas

Las recetas (archivos .bb) son los componentes básicos en el entorno del proyecto Yocto. Hay dos formas relativamente sencillas de crear nuevas recetas:

  • recetatool: una herramienta proporcionada por Yocto para crear automáticamente recetas basadas en archivos de origen
  • recetas existentes: modifique una receta existente con requisitos funcionales similares. Hay muchas recetas mantenidas por la comunidad en http://layers.openembedded.org/layerindex/branch/master/layers/ , puede encontrar las que satisfacen sus necesidades y obtener directamente para su uso.
recipetool create -o example/example_0.1.bb  ../../meta-mylayer/

La siguiente es la receta creada al ejecutar las instrucciones anteriores.

# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order to be fully functional.
# (Feel free to remove these comments when editing.)

# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is
# your responsibility to verify that the values are complete and correct.
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
# No information for SRC_URI yet (only an external source tree was specified)
SRC_URI = ""

# NOTE: no Makefile found, unable to determine what needs to be done
do_configure () {
    
    
	# Specify any needed configure commands here
	:
}
do_compile () {
    
    
	# Specify compilation commands here
	:
}
do_install () {
    
    
	# Specify install commands here
	:
}

En el archivo anterior, se proporcionan la licencia de derechos de autor de la receta, la suma de comprobación del archivo de licencia y el URI del código fuente, y se proporciona la interfaz de reescritura para tareas como do_configure.

4.4 Compilar recetas

Después de usar el script imx-setup-release para inicializar el directorio de compilación de Yocto, automáticamente ingresará al directorio de compilación. En esta ruta, ejecute el siguiente comando para compilar

bitbake example

Entre ellos, ejemplo es el nombre de la receta. Durante el proceso de compilación, el sistema de compilación OpenEmbedded creará una carpeta temporal para cada receta para almacenar archivos descomprimidos, archivos de registro, etc. Los archivos temporales para cada receta están organizados de la siguiente manera:

BASE_WORKDIR ?= "${TMPDIR}/work"
WORKDIR = "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"

Por ejemplo: imx8mmeamb9918a1-poky-linux es la arquitectura del sistema, el archivo de recetas es rs9116nb0_git.bb y la ruta del archivo generado es la siguiente:

eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/rs9116nb0/2022.06_git-r0

Además, podemos usar el siguiente comando para ubicar el directorio de trabajo al construir un paquete:

bitbake -e linux-imx | grep ^WORKDIR=  //定位linux-imx工作目录
bitbake -e linux-imx | grep ^S=        //定位源码解压后的位置
bitbake -e linux-imx | grep ^B=        //定位源码编译目录
bitbake -e linux-imx | grep -E "^PN=|^PV=|^PR="  //定位构建包的配方名称、配方版本和构建包的配方的修订版

Hay varias carpetas importantes en el directorio de archivos anterior:

  • image : almacene los archivos que se instalarán en el sistema de destino y guárdelos de acuerdo con la ruta de instalación.
  • deployment : almacena los paquetes de instalación en formato rpm/deb.
  • temp : almacena todas las instrucciones de tareas ejecutadas durante el proceso de compilación y los registros del proceso ejecutado.
    El orden en que BitBake ejecuta las tareas está controlado por su programador de tareas. ${WORKDIR}/temp/En el directorio, run_los archivos que comienzan con registran el contenido detallado de cada tarea después del análisis, log_los archivos que comienzan con registran el registro cuando se ejecuta la tarea y log.task_orderlos archivos registran las tareas ejecutadas por el objetivo actual en orden.
    inserte la descripción de la imagen aquí

4.5 Crear archivo de máquina

En general, la plataforma de hardware personalizada se referirá a la configuración de la plataforma de hardware imx8mmevk proporcionada oficialmente por Freescale.Necesitamos modificar la plataforma de hardware imx8mmevk según el diseño de interfaz de hardware personalizado para garantizar que nuestros controladores de interfaz de hardware funcionen normalmente. Por lo tanto, necesitamos referirnos a los archivos sources/meta-imx/meta-bsp/conf/machinedebajo de la ruta imx8mmevk.confcomo los archivos de configuración para la plataforma de hardware que usamos para construir el sistema. imx8mmevk.confEl archivo consta principalmente de las siguientes partes:

  • archivo incluido En el archivo imx8mmevk.conf, la palabra
    clave require hace referencia al archivo y, en el archivo, la palabra clave require hace referencia al archivo .sources/meta-freescale/conf/machine/imx8mm-lpddr4-evk.confimx8mm-lpddr4-evk.confimx8mm-evk.inc
qing@Qing:sources$ cat meta-freescale/conf/machine/imx8mm-lpddr4-evk.conf
......
require include/imx8mm-evk.inc
......

imx8mm-evk.increferenciado en el expediente

require conf/machine/include/imx-base.inc
require conf/machine/include/arm/armv8a/tune-cortexa53.inc

Entre ellos, imx8mm pertenece al núcleo de la serie coretexa53, por lo que se hace referencia al archivo coretexa53.inc. Este archivo se encuentra sources/poky/meta/conf/machine/include/arm/armv8a/tune-cortexa53.incdebajo de la ruta y define principalmente algunas definiciones relacionadas con el núcleo de la arquitectura coretexa53. Para coretexa53.inc, no necesitamos modificar él. Además, el archivo imx-base.inc se encuentra sources/meta-freescale/conf/machine/include/imx-base.incdebajo de la ruta, que define principalmente algunos parámetros predeterminados de la CPU de la serie imx, como la dirección de entrada de uboot, la definición predeterminada del kernel, etc.

  • Definición del árbol de dispositivos del kernel
    En el archivo imx8mmevk.conf, el archivo del árbol de dispositivos generado por el kernel de Linux durante la compilación se define a través de la variable KERNEL_DEVICETREE . Cuando necesite modificar el archivo de árbol de dispositivos generado por el kernel de Linux durante la compilación, debe modificar el valor de la variable KERNEL_DEVICETREE .
# Include device trees for other boards for internal test
KERNEL_DEVICETREE += " \
    freescale/imx8mm-ddr4-evk.dtb \
    freescale/imx8mm-ddr4-evk-pcie-ep.dtb \
    freescale/imx8mm-ddr4-evk-rm67191.dtb \
    freescale/imx8mm-ddr4-evk-rm67191-cmd-ram.dtb \
    freescale/imx8mm-ddr4-evk-rm67199.dtb \
    freescale/imx8mm-ddr4-evk-rm67199-cmd-ram.dtb \
    freescale/imx8mm-ddr4-evk-revb.dtb \
    freescale/imx8mm-ddr4-evk-revb-rm67191.dtb \
    freescale/imx8mm-ddr4-evk-revb-rm67191-cmd-ram.dtb \
    freescale/imx8mm-ddr4-evk-revb-rm67199.dtb \
    freescale/imx8mm-ddr4-evk-revb-rm67199-cmd-ram.dtb \
"
  • Configuración de U-BOOT
    En el archivo imx8mm-lpddr4-evk.conf, se agrega el archivo de configuración predeterminado de U-Boot correspondiente para la plataforma de hardware personalizada y se habilita configurando la variable UBOOT_CONFIG , como se muestra a continuación:
UBOOT_CONFIG ??= "sd"
UBOOT_CONFIG_BASENAME = "imx8mm_evk"
UBOOT_CONFIG[sd]      = "${UBOOT_CONFIG_BASENAME}_defconfig,sdcard"
UBOOT_CONFIG[mfgtool] = "${UBOOT_CONFIG_BASENAME}_defconfig"
UBOOT_CONFIG[fspi]    = "${UBOOT_CONFIG_BASENAME}_fspi_defconfig"

En el archivo imx8mm-evk.inc, el archivo de árbol de dispositivos utilizado por uboot en la compilación está definido por la variable UBOOT_DTB_NAME .

# Set u-boot DTB
UBOOT_DTB_NAME = "${KERNEL_DEVICETREE_BASENAME}.dtb"
  • Configuración de DDR FIRMWARE
    En el archivo imx8mm-lpddr4-evk.conf, el archivo bin utilizado por DDR durante la compilación está definido por la variable DDR_FIRMWARE_NAME .
# Set DDR FIRMWARE
DDR_FIRMWARE_NAME = " \
 lpddr4_pmu_train_1d_imem.bin \
 lpddr4_pmu_train_1d_dmem.bin \
 lpddr4_pmu_train_2d_imem.bin \
 lpddr4_pmu_train_2d_dmem.bin \
"

4.6 Personalizar la imagen del sistema

4.6.1 Usando el método IMAGE_INSTALL

Modificando el archivo de imagen del sistema existente. Por ejemplo: si desea crear un imx-image-fullarchivo de imagen del sistema basado en el sistema, pero necesita agregar un paquete de seguimiento adicional, puede agregar el paquete de seguimiento creando un archivo y agregando el siguiente código en el imx-image-full.bbappendnuevo archivo:.bbappend

IMAGE_INSTALL:append = "strace"

Además, el archivo también se puede modificar conf/local.conf, pero la modificación aquí es global y hará que todos los archivos de imagen creados surtan efecto, lo que no favorece la gestión de proyectos. La mejor manera es crear un nuevo archivo bbappend correspondiente a la imagen para modificar, y solo instalar un determinado paquete en un archivo de imagen específico.

El método anterior para agregar paquetes es agregar o eliminar paquetes en el sistema de imagen de destino configurando la variable IMAGE_INSTALL Puede usar la sintaxis :append para agregar un paquete y la sintaxis :remove para eliminar un paquete. Los paquetes y grupos de paquetes generalmente se instalan en la imagen de destino a través de la configuración de la variable IMAGE_INSTALL.Un grupo de paquetes es una colección de paquetes, que generalmente están definidos por archivos .bb.

4.6.1 Usando el método IMAGE_FEATURES

Además de usar la variable IMAGE_INSTALL, también puede usar la variable IMAGE_FEATURES para establecer las características de la imagen de destino. Esta variable no se limita a paquetes y grupos de paquetes, y los usuarios pueden definirla por sí mismos. También podemos modificar el contenido de la variable IMAGE_FEATURES con la sintaxis :append y :remove. Como se usa en el proyecto:

IMAGE_FEATURES:remove = " ssh-server-dropbear"
IMAGE_FEATURES:append = " ssh-server-openssh"

Arriba, a través de la variable IMAGE_FEATURES , se agregó el paquete: ssh-server-openssh a la imagen fsl-image-multimedia y se eliminó el paquete: ssh-server-dropbear. Además, al ejecutar el siguiente comando, podemos saber que las adiciones y eliminaciones anteriores a través de IMAGE_FEATURES:remove y IMAGE_FEATURES:append también son grupos de paquetes.

$ bitbake -e fsl-image-multimedia | grep ^FEATURE_PACKAGES
FEATURE_PACKAGES_ssh-server-dropbear="packagegroup-core-ssh-dropbear"
FEATURE_PACKAGES_ssh-server-openssh="packagegroup-core-ssh-openssh"

El definido ssh-server-opensshsignifica que packagegroup-core-ssh-opensshel definido ssh-server-dropbearsignifica que packagegroup-core-ssh-dropbearlos archivos .bb de los dos grupos de paquetes anteriores se pueden buscar directamente en el directorio del código fuente:

$ find ./ -name "packagegroup-core-ssh-openssh*"
./poky/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb

4.6.3 Usando PACKAGE_EXCLUDE

Finalmente, si el paquete que queremos eliminar no se muestra en la definición de IMAGE_INSTALL e IMAGE_FEATURES , generalmente se encapsula en el grupo de paquetes. En este momento, se puede configurar con la variable PACKAGE_EXCLUDE :

PACKAGE_EXCLUDE = "package_name package_name package_name ..."

Ninguno de los paquetes enumerados se instalará en la imagen de destino. Puede haber un problema aquí, si algún otro paquete depende del paquete listado aquí (es decir, listado en la variable RDEPENDS), reportará un error al construir, y la dependencia correspondiente debe ser tocada. Tome la eliminación de connman como ejemplo:

PACKAGE_EXCLUDE = "connman"

El siguiente error ocurre al construir:

$ bitbake fsl-image-machine-test
...
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 packagegroup-core-tools-testapps : Depends: connman-client but it is not going to be installed
                                    Depends: connman-tools but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
...

Tanto connman-client como connman-tools en el grupo de paquetes packagegroup-core-tools-testapps dependen de connman, que se puede ver en el archivo packagegroup-core-tools-testapps.bb:

RDEPENDS_${
    
    PN} = "\
    blktool \
    ${KEXECTOOLS} \
    alsa-utils-amixer \
    alsa-utils-aplay \
    ltp \
    connman-tools \
    connman-tests \
    connman-client \
    ${@bb.utils.contains('DISTRO_FEATURES', 'x11', "${
    
    X11TOOLS}", "", d)} \
    ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', "${
    
    X11GLTOOLS}", "", d)} \
    ${@bb.utils.contains('DISTRO_FEATURES', '3g', "${
    
    3GTOOLS}", "", d)} \
    "

Puede crear un nuevo archivo packagegroup-core-tools-testapps.bbappend y eliminarlo usando la sintaxis _remove:

RDEPENDS_${
    
    PN}_remove = "connman-tools connman-tests connman-client"

Cinco, uboot trasplante

Modificación del código fuente de 5.1.u-boot

Durante el proceso de portabilidad de U-Boot, se debe modificar el código fuente de uboot correspondiente. No modificaremos directamente la receta proporcionada por Yocto, pero configuraremos el proceso de compilación del software U-Boot creando un archivo bbappend con la misma receta de nombre en nuestra capa de meta-advantech recién creada. El proveedor de uboot está definido por
la variable PREFERRED_PROVIDER_virtual/bootloader_imx = "u-boot-imx", de la siguiente manera:

PREFERRED_PROVIDER_virtual/bootloader_imx = "u-boot-imx"

Se puede ver que el proveedor de imx8mm es u-boot-imx, de hecho corresponde a u-boot-imx_2022.04 bajo la ruta de /sources/meta-imx/meta-bsp/recipes-bsp/u- archivos de arranque/.bb. Por lo tanto, creamos la siguiente ruta: sources/meta-advantech/meta-adv-imx/recipes-bsp/u-boot/y creamos el archivo u-boot-imx_2022.04.bbappend. El contenido del archivo es el siguiente:

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

UBOOT_SRC = "git://github.com/Advantech-IIoT/uboot-imx.git;protocol=https"
SRCBRANCH = "lf_v2022.04"
SRC_URI = "${UBOOT_SRC};branch=${SRCBRANCH}"
SRCREV = "642b7925a0bcfc145e5ef51214b008afe472cc6d"
LOCALVERSION = "-${SRCBRANCH}"

Desde el archivo bbappend anterior, especifique la ubicación del código fuente de uboot que participa en el sistema de compilación mediante las variables SRC_URI y SRCREV.

5.2.archivo de árbol de dispositivo u-boot

Al crear el archivo machine.conf anteriormente, se mencionó que la variable UBOOT_DTB_NAME debe configurarse para definir el archivo de árbol de dispositivos utilizado por uboot en la compilación. Los ajustes para otras configuraciones de uboot también se establecen en el archivo machine.conf.

5.3.construcción del código fuente de u-boot

Después de cargar el entorno de trabajo de Yocto a través del comando MACHINE=imx8mmeamb9918a1 DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b eamb9918a1, el kernel se puede compilar de las siguientes dos maneras:
Ejecutar comando: bitbake imx-image-fullcompilar todo el sistema
Ejecutar comando: bitbake u-boot-imxcompilar uboot solo
Para que el comando compile todo el sistema en el modo 1, el Linux incorporado la versión de distribución se completará al mismo tiempo U-Boot, el kernel de Linux, los archivos del árbol del dispositivo, la compilación del sistema de archivos raíz, la instalación del paquete y otros procesos generarán directamente el archivo de destino final; mientras usa el método 2, solo uboot se compilará por separado, y después de la compilación, se generará bajo el eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/u-boot-imx/2022.04-r0/image/bootarchivo road force u-boot.bin.

eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/u-boot-imx/2022.04-r0/image/boot$ ls
u-boot.bin  u-boot.bin-sd  u-boot-sd-2022.04-r0.bin  u-boot-spl.bin  u-boot-spl.bin-sd  u-boot-spl.bin-sd-2022.04-r0

6. Trasplante de granos

6.1 Modificación del código fuente del kernel de Linux

Durante el proceso de portabilidad del kernel de Linux, se debe modificar el código fuente del kernel de Linux correspondiente. Del mismo modo, no modificaremos directamente la receta proporcionada en Yocto, sino que crearemos una nueva receta en el meta-advantech que creamos anteriormente. Configurar la compilación del kernel de Linux proceso.
El proveedor del kernel de Linux está definido por la variable PREFERRED_PROVIDER_virtual/kernel_imx , de la siguiente manera:

PREFERRED_PROVIDER_virtual/kernel_imx = "linux-imx"

Se puede ver que el proveedor del kernel de Linux imx8mm es linux-imx, de hecho, corresponde al archivo linux-imx_5.15.bb en /sources/meta-imx/meta-bsp/recipes-kernel/linux / camino. Por lo tanto, creamos rutas como esta: sources/meta-advantech/meta-adv-imx/recipes-kernel/linux/，并创建linux-imx_5.15.bbappendarchivo. El contenido del archivo es el siguiente:

sources/meta-advantech/meta-adv-imx/recipes-kernel/linux$ cat linux-imx_5.15.bbappend 
SRCBRANCH = "lf-5.15.y"
LOCALVERSION = "-lts-5.15.y"
KERNEL_SRC = "git://github.com/Advantech-IIoT/linux-imx.git;protocol=https;branch=${SRCBRANCH}"
SRC_URI = "${KERNEL_SRC}"
SRCREV = "065aa1f91e58e1108720dc701a074760be878962"

De manera similar, especificamos la ubicación del código fuente del kernel que participa en el sistema de compilación mediante las variables SRC_URI y SRCREV .

6.2 Archivo de árbol de dispositivos del kernel de Linux

Al crear el archivo machine.conf anteriormente, se mencionó que se debe configurar la variable KERNEL_DEVICETREE.El archivo de árbol de dispositivos utilizado en el proceso de compilación del kernel de Linux está definido por la variable KERNEL_DEVICETREE.

6.3 Creación y obtención de archivos de parches del kernel de Linux

Durante el proceso de portabilidad del kernel de Linux, se involucrará la obtención o creación de archivos de parches. La forma más sencilla es usar el comando git para enviar cambios y generar archivos de parches.

$ git add init/calibrate.c
$ git commit -m "calibrate.c - Added some printk statements"
$ git format-patch -1
0001-calibrate.c-Added-some-printk-statements.patch

Coloque el archivo de parche generado en la ruta meta-mylayer/recipes-kernel/linux/linux-imx/ y agregue el archivo .bbappend:

SRC_URI：append = " file://0001-calibrate.c-Added-some-printk-statements.patch"

Ejecute el siguiente comando para borrar primero el directorio de compilación del kernel y luego vuelva a aplicar el parche:

$ bitbake linux-imx -c clean
$ bitbake linux-imx -c patch

Luego verifique el código fuente parcheado, confirme que el parche haya tenido efecto y compílelo:

$ bitbake linux-imx

Otra forma de modificar la configuración del kernel es abrir bitbake linux-imx -c menuconfiguna interfaz interactiva y modificar la configuración aquí:
inserte la descripción de la imagen aquí
la configuración aquí proviene del archivo .config en el directorio de compilación.Si es la primera compilación, este archivo es el arco/brazo del kernel. código fuente Una copia de un archivo defconfig en el directorio /conifg, qué archivo es, generalmente especificado en la tarea do_config del archivo de recetas.
Después de modificar en menuconfig, guarde y salga. Se generará un archivo .config actualizado en el directorio de compilación tmp/work/imx8mmeamb9918a1-poky-linux/linux-imx/5.15.32+gitAUTOINC+065aa1f91e-r0/build/, y el .config original se renombrará como .config .viejo. Luego llame a la opción diffconfig para generar un fragmento de configuración:

bitbake linux-imx -c diffconfig

Este paso es para comparar la diferencia entre .config y .config.old, determinar el contenido modificado y generar un archivo de parche, que se denomina fragmento de configuración.El archivo generado se encuentra en fragment.cfg en el directorio de compilación del kernel . Podemos copiar este archivo en el directorio meta-advantech/meta-adv-imx/recipes-kernel/linux/linux-imx/ y luego agregar el archivo linux-imx_5.10.72.bbappend:

SRC_URI += "file://fragment.cfg"

Es una buena idea cambiar fragment.cfg a un nombre de archivo significativo, ya que a menudo se usan múltiples fragmentos de configuración para agregar diferentes tipos de modificaciones. Antes de compilar, puede llamar kernel_configchecka la opción para verificar si la configuración del kernel es correcta:

bitbake linux-imx -c kernel_configcheck

6.4 Construcción del código fuente del kernel de Linux

Después de cargar el entorno de trabajo de Yocto a través del comando MACHINE=imx8mmeamb9918a1 DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b eamb9918a1, el kernel se puede compilar de las siguientes dos maneras:
Ejecutar comando: bitbake imx-image-fullcompilar todo el sistema
Ejecutar comando: bitbake linux-imxcompilar el kernel de Linux por separado
Para el comando para compilar todo el sistema en el método 1, el La versión de distribución integrada de Linux se completará al mismo tiempo U-Boot, el kernel de Linux, los archivos del árbol del dispositivo, la compilación del sistema de archivos raíz, la instalación del paquete y otros procesos generarán directamente el archivo de destino final; mientras se usa el método 2, solo el kernel de Linux y el dispositivo Los archivos de árbol se compilarán por separado. Después de la compilación, el archivo de imagen se generará en eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/linux-imx/5.15.32+gitAUTOINC+065aa1f91e-r0/build/arch/arm64/boot , y el archivo se generará bajo dtsla fuerza de la carretera dtb;

eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/linux-imx/5.15.32+gitAUTOINC+065aa1f91e-r0/build/arch/arm64/boot/dts/freescale$ ls
imx8mm-adv-eamb9918-a1.dtb  imx8mm-evk.dtb

El archivo dtb anterior es el archivo de árbol de dispositivos generado durante el proceso de compilación del kernel de Linux. En consecuencia, en el archivo sources/meta-advantech/meta-adv-imx/conf/machine/imx8mmeamb9918a1.conf, la variable definida KERNEL_DEVICETREE solo corresponde al archivo de árbol de dispositivos generado.
Si necesita implementar la imagen compilada del kernel de Linux, puede usar el siguiente comando:

bitbake -c deploy -f linux-imx                    //部署内核镜像到deploy目录

Este comando implementará el archivo de imagen del kernel de Linux generado en la ruta /tmp/deploy/images.

Siete Construya el sistema de archivos raíz

Al crear una distribución de sistema Linux integrado, todo el sistema Linux integrado completo se crea a través del comando bitbake imx-image-multimedia. Entre ellos, Freescale proporciona varios archivos de imagen de destino para elegir. Cabe señalar que cuantas más funciones admita el archivo de imagen, mayor será el sistema de archivos raíz: aquí, se
inserte la descripción de la imagen aquí
selecciona imx-image-full. De hecho, al ejecutar el comando bitbake imx-image-full, bitbake encontrará los archivos /sources/meta-imx/meta-sdk/dynamic-layers/qt6-layer/recipes-fsl/imagesen la ruta imx-image-full.bby construirá el sistema de acuerdo con la configuración en el archivo imx-image-full.bb. Al mismo tiempo, /sources/meta-imx/meta-sdk/recipes-fsl/imagestambién puede ver fsl-image-multimedia.bbotros archivos debajo de la ruta, que corresponden a los archivos espejo mencionados en la tabla anterior.
Además, al construir el sistema de archivos, necesitamos instalar y configurar un nuevo software funcional creando el archivo bbppend correspondiente de acuerdo con las necesidades del proyecto real. Finalmente, podemos comenzar a usar la herramienta bitbake para construir un sistema Linux embebido ejecutando el comando bitbake imx-image-full . Una vez creado el sistema de archivos, el archivo imx-image-full-xxx.xxxeamb9918a1/tmp/deploy/images/imx8mmeamb9918a1 se generará en la ruta , que corresponde al sistema de archivos Yocto. Al mismo tiempo, bajo esta ruta, también se genera un archivo de manifiesto que contiene los paquetes de software instalados en el sistema de archivos correspondiente. Vea el archivo de manifiesto ejecutando el siguiente comando y consulte si el paquete de software instalado en el sistema de archivos raíz integrado contiene el navegador Chrome
inserte la descripción de la imagen aquí

eamb9918a1/tmp/deploy/images/imx8mmeamb9918a1$ cat imx-image-full-imx8mmeamb9918a1.manifest | grep chromium
chromium-ozone-wayland armv8a-mx8mm 96.0.4664.110-r0

Además, al construir el sistema de archivos raíz, a menudo se encuentran con algunos errores como fetch/request.En términos generales, es un problema de red y puede realizar la operación correspondiente nuevamente. Por ejemplo, si el mensaje de error indica que se ha informado de un error durante la obtención, entonces podemos ejecutar la tarea do_fetch solo. Después de que la tarea do_fetch sea exitosa, volvemos a ejecutar la construcción del sistema de archivos. Si ocurre un problema repetidamente al construir el sistema de archivos raíz, puede intentar eliminar el contenido de la carpeta de construcción y ejecutar el comando para construir el sistema de archivos nuevamente.

Resumir

Por ejemplo: lo anterior es de lo que hablaré hoy. Este artículo solo presenta brevemente la introducción y el uso del sistema Yocto para ayudarlo a comprender rápida y fácilmente el proceso de trasplante del sistema Yocto.

Supongo que te gusta

Origin blog.csdn.net/weixin_53860846/article/details/127381127
Recomendado
Clasificación
Diario
Más
2024-05-19(0)
2024-05-18(30)
2024-05-17(4)
2024-05-16(22)
2024-05-15(5)
2024-05-14(10)
2024-05-13(7)
2024-05-12(22)
2024-05-11(31)
2024-05-10(32)

Code World

© 2018 codetd.com