linux-kernel header-files yocto bitbake openembedded

linux kernel - ¿Cómo escribir una receta de controlador BitBake que requiere archivos de encabezado de fuente kernel?



linux-kernel header-files (2)

No creo que nadie pueda responder adecuadamente a esta última pregunta aquí. Está utilizando un método de instalación no estándar: no podemos saber cómo interactuar con él ...

Dicho esto, eche un vistazo a lo que hace meta / classes / module.bbclass. Establece varias variables relacionadas para make: KERNEL_SRC=${STAGING_KERNEL_DIR} , KERNEL_PATH=${STAGING_KERNEL_DIR} , O=${STAGING_KERNEL_BUILDDIR} . ¿Tal vez su instalador admite algunas de estas variables de entorno y puede configurarlas en su receta?

Introducción

Tengo una tarea do_install en una receta de BitBake que he escrito para un controlador donde ejecuto un script de install personalizado. La tarea falla porque la secuencia de comandos de instalación no puede encontrar los archivos de encabezado fuente del núcleo dentro de <the image rootfs>/usr/src/kernel . Esta secuencia de comandos funciona bien en el sistema operativo generado.

Qué esta pasando

Aquí está la parte relevante de mi receta:

SRC_URI += "file://${TOPDIR}/example" DEPENDS += " virtual/kernel linux-libc-headers " do_install () { ( cd ${TOPDIR}/example/Install ; ./install ) }

Aquí hay una parte relevante del script de install :

if [ ! -d "/usr/src/kernel/include" ]; then echo ERROR: Linux kernel source include directory not found. exit 1 fi cd /usr/src/kernel make scripts ... ./install_drv pci ${DRV_ARGS}

¡Verifiqué cambiando a if [ ! -d "/usr/src/kernel" ] if [ ! -d "/usr/src/kernel" ] , que también falló. install pasa diferentes opciones a install_drv , que tengo una parte relevante de abajo:

cd ${DRV_PATH}/pci make NO_SYSFS=${ARG_NO_SYSFS} NO_INSTALL=${ARG_NO_INSTALL} ${ARGS_HWINT} if [ ${ARG_NO_INSTALL} == 0 ]; then if [ `/sbin/lsmod | grep -ci "uceipci"` -eq 1 ]; then ./unload_pci fi ./load_pci DEBUG=${ARG_DEBUG} fi

La build: objetivo de build: dentro de ${DRV_PATH}/pci es esencialmente la siguiente:

make -C /usr/src/kernel SUBDIRS=${PWD} modules

Mi investigación

Encontré estos comentarios dentro de linux-libc-headers.inc relevantes:

# You''re probably looking here thinking you need to create some new copy # of linux-libc-headers since you have your own custom kernel. To put # this simply, you DO NOT. # # Why? These headers are used to build the libc. If you customise the # headers you are customising the libc and the libc becomes machine # specific. Most people do not add custom libc extensions to the kernel # and have a machine specific libc. # # But you have some kernel headers you need for some driver? That is fine # but get them from STAGING_KERNEL_DIR where the kernel installs itself. # This will make the package using them machine specific but this is much # better than having a machine specific C library. This does mean your # recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and # makes total sense. # # There can also be a case where your kernel extremely old and you want # an older libc ABI for that old kernel. The headers installed by this # recipe should still be a standard mainline kernel, not your own custom # one.

No estoy STAGING_KERNEL_DIR si puedo ''obtener'' los encabezados del STAGING_KERNEL_DIR correctamente ya que no estoy usando make.

Dentro de kernel.bbclass provisto en el directorio de meta/classes , existe esta variable assigment:

# Define where the kernel headers are installed on the target as well as where # they are staged. KERNEL_SRC_PATH = "/usr/src/kernel"

Esta ruta luego se empaqueta más tarde dentro de ese archivo .bbclass aquí:

PACKAGES = "kernel kernel-base kernel-vmlinux kernel-image kernel-dev kernel-modules" ... FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH} /lib/modules/${KERNEL_VERSION}/build"

Actualización (1/21):

Una sugerencia en el canal de IRC yocto era usar la siguiente línea:

do_configure[depends] += "virtual/kernel:do_shared_workdir"

lo cual es corroborado por el Manual de Referencia del Proyecto Yocto , que establece que en la versión 1.8, hubo el siguiente cambio:

El proceso de compilación del kernel se cambió para colocar el origen en un área de trabajo compartido común y para colocar artefactos de construcción por separado en el árbol de códigos fuente. En teoría, las rutas de migración se han proporcionado para los usos más comunes en las recetas de kernel, pero esto podría no funcionar en todos los casos. En particular, los usuarios deben asegurarse de que ${S} (archivos de origen) y ${B} (artefactos de construcción) se usan correctamente en funciones como do_configure y do_install . Para las recetas del kernel que no heredan de kernel-yocto o incluyen linux-yocto.inc , es posible que desee linux.inc archivo linux.inc en la capa meta-oe para conocer los tipos de cambios que debe realizar. Como referencia, aquí está la confirmación donde se linux.inc archivo linux.inc en meta-oe .

Las recetas que se basan en el código fuente del kernel y no heredan las clases del módulo podrían necesitar agregar dependencias explícitas en la tarea do_shared_workdir kernel, por ejemplo:

do_configure[depends] += "virtual/kernel:do_shared_workdir"

Pero estoy teniendo dificultades para aplicar esto a mi receta. Por lo que entiendo, debería ser capaz de cambiar la línea anterior a:

do_install[depends] += "virtual/kernel:do_shared_workdir"

Lo que significaría que la tarea do_install ahora debe ejecutarse después de la tarea do_shared_workdir de la receta virtual/kernel , lo que significa que debería poder trabajar con el directorio de trabajo compartido (consulte la Pregunta 3 a continuación), pero aún tengo el mismo encabezado del kernel que falta problema.

Mis preguntas

Estoy usando un núcleo de Linux personalizado (v3.14) de git.kernel.org . que hereda la clase kernel . Aquí están algunas de mis preguntas:

  1. ¿No debería el paquete kernel-dev ser parte de cualquier receta que herede la clase kernel ? ( esta sección del glosario de variables)
  2. Si agrego el virtual/kernel a la variable DEPENDS , ¿no significaría eso que kernel-dev se incorporaría?
  3. Si kernel-dev es parte de las dependencias de mi receta, ¿no podría apuntar al directorio /usr/src/kernel desde mi receta? De acuerdo con esta respuesta en la lista de correo de Yocto , creo que debería.
  4. ¿Cómo puedo hacer una referencia adecuada de los archivos de encabezado fuente del núcleo, preferiblemente sin cambiar el script de instalación?

Considera tu entorno

Recuerde que hay diferentes entornos dentro del entorno de tiempo de compilación, que consiste en:

  • sysroots
  • en el caso de los kernels, un directorio de trabajo compartido
  • paquetes de destino

kernel-dev es un paquete de destino, que se instalaría en los rootfs del sistema de destino para ciertas cosas como los mapas de símbolos del kernel que son necesarios mediante herramientas de perfilado como perf / oprofile. No está presente en el momento de la compilación, aunque algunos de sus contenidos están disponibles en los sysroots o en el directorio de trabajo compartido.

Señale los directorios correctos

Tu do_install ejecuta en tiempo de compilación, por lo que se encuentra dentro de las estructuras de directorio de compilación del sistema de compilación, no del de destino. En particular, /usr/src/ no será correcto, necesitaría ser alguna ruta dentro de su directorio de compilación. La tarea virtual/kernel do_shared_workdir rellena ${STAGING_DIR_KERNEL} por lo que le gustaría cambiar a ese directorio en su secuencia de comandos.

Agregar una dependencia de tarea

Los:

do_install[depends] += "virtual/kernel:do_shared_workdir

la dependencia parece correcta para su caso de uso, suponiendo que nada en do_configure o do_compile acceda a los datos allí.

Reconsiderar el module clase BitBake

Las otras respuestas son correctas en la recomendación de observar module.bbclass , ya que esto ilustra cómo se pueden construir los módulos comunes del kernel. Si quiere usar funciones personalizadas o hacer comandos, está bien, puede anularlos. Si realmente no quieres usar esa clase, sugeriría que me inspirara.

Dependencias de tareas

Agregar virtual/kernel a DEPENDS significa virtual/kernel:do_populate_sysroot debe ejecutarse antes de nuestra tarea do_configure . Como necesita una dependencia para do_shared_workdir aquí, un DEPENDS en virtual/kernel no es suficiente.

Respuesta a la pregunta 3

El paquete kernel-dev se compilaría, sin embargo, necesitaría ser instalado en su imagen objetivo y utilizado en tiempo de ejecución en un objetivo real. Necesitas esto en tiempo de compilación para que kernel-dev no sea apropiado.

Otras sugerencias

Es probable que desee el paquete kernel-devsrc para lo que está haciendo, no el paquete kernel-dev .