Cómo cambiar la configuración de u-boot en Yocto

Es posible agregar defconfig como archivo normal, como ejemplo, estoy pegando algunos bbappend que funcionan:

PR = "r7"
BRANCH = "ti-u-boot-2020.01"
SRCREV = "ae8ceb7b6e3acb4bc90f730e33dafc7b65066591"
FILESEXTRAPATHS_prepend := "${THISDIR}:" 

SRC_URI +=  "file://0001-Add-am335x-cmpc30-target.patch \
         file://am335x-cmpc30.dts;subdir=git/arch/arm/dts \
         file://am335x_cmpc30_defconfig;subdir=git/configs/ \
        "

Entonces, la línea "file://am335x_cmpc30_defconfig;subdir=git/configs/" en realidad puso todo el defconfig en el código fuente de u-boot.

no es necesario copiar todo .config privado archivo en la carpeta de compilación de u-boot, si es necesario modificar algunas configuraciones dentro de defconfig, sed está funcionando perfectamente dentro del do_compile_prepend método también. ejemplo:

`

do_configure_prepend() {
        sed -i -e 's,CONFIG_DEFAULT_DEVICE_TREE=,CONFIG_DEFAULT_DEVICE_TREE= ${BOARD_DEVICE_TREE},g'  ${S}configs/mx7ulp_evk_defconfig
}

`

los espacios están perfectamente bien dentro de los patrones de búsqueda y reemplazo. ${BOARD_DEVICE_TREE} podría definirse en uno de los archivos de configuración de Yocto. este método también funciona bien para los archivos de origen/encabezado que ya están parcheados con una lista de parches basada en recetas.

Técnicamente, el proceso que describiste me parece correcto. Pero hay un par de obstáculos que hay que tener en cuenta, respectivamente cosas que hay que comprobar:

1. ¿Se ha procesado realmente su .bbappend?

Si bien este parece ser su caso (lo descubrió a través de la salida de depuración), generalmente es más fácil verificarlo con:

bitbake-layers show-appends

Esto le dará una lista completa y detallada de todos los anexos que están vigentes en su situación de compilación actual.

1. ¿El .bbappend realmente tiene el efecto deseado?

Si hay más de una receta involucrada, las cosas pueden complicarse y sobrescribirse entre sí. Consulte con

bitbake -e u-boot-imx

para ver lo que realmente sucede. Esto se combina mejor con la canalización hacia less (o el localizador de su elección) y luego buscando los valores modificados, como SRC_URI.

1. Descubra cuál es su máquina u-boot.

Dada la información de 2., esto es bastante trivial:verifique la variable llamada

UBOOT_MACHINE

ya que esto es lo que u-boot realmente debería ver.

1. Trate de no decirle demasiado a bitbake qué hacer.

Especialmente la combinación de los modificadores -f y -c puede tener resultados inesperados, ya que básicamente se modifican las dependencias de las tareas. En mi experiencia, algo a lo largo

bitbake -c clean u-boot-imx && bitbake u-boot-imx

debería funcionar mejor, ya que pasa por toda la dependencia de compilación, incluida la configuración, la aplicación de parches, etc.

EDITAR / ANEXO

Verifiqué con los desarrolladores de OE, y el problema principal es que el mecanismo de configuración de configuración es (linux-) específico del kernel, por eso también se explica en el manual de kernel-dev.

Entonces, para obtener su configuración en la compilación real, hay una solución y media.

1. La forma correcta:

Prepare un parche para las fuentes de u-boot. En su caso, probablemente sea solo una modificación menor al archivo defconfig que ya está en uso. Tenga el parche en el formato canónico y agréguelo a SRC_URI, luego debería ser recogido automáticamente y hacer el truco.

1. El camino hackish (y no probado, por lo tanto, solo a medias):

Prepare su configuración en formato completo (no la versión reducida de defconfig). Luego agréguelo a SRC_URI y utilícelo a través de una tarea adicional en su .bbappend:

do_compile_prepend() {
  cp YOURFILENAME ${S}/.config
}

Esto debería inyectar la nueva configuración directamente antes de que comience la compilación. Puede que necesite un poco de retoques, pero ciertamente entiendes la idea. Otro enfoque sería inyectar su configuración predeterminada sobre el archivo original.

Dicho esto, recomiendo encarecidamente la primera forma.