web-dev-qa-db-fra.com

Comment changer la config de u-boot dans Yocto

Construire linux pour une carte de développement iMX6 à l’aide du projet Yocto, et je souhaite modifier le fichier .config utilisé pour construire u-boot-imx (u-boot pour la carte de développement iMX) - par exemple. changer le délai de démarrage automatique à 1 seconde à titre d'exemple. 

Je peux modifier la configuration (par exemple, rechercher le répertoire de construction et exécuter make menuconfig), mais lorsque je lance bitbake pour reconstruire l'image, le fichier .config est écrasé par défaut. Il existe de nombreux fichiers xxx_defconfig et je ne sais pas lequel il utilise. 

J'ai suivi ce guide pour la configuration du noyau avec le projet Yocto. J'ai apporté une modification au fichier .config, je l'ai copiée sur ma couche et renommée "defconfig". J'ai créé une nouvelle couche avec un u-boot-imx_2017.03.bbappend pour étendre u-boot-imx_2017.03.bb (la recette de u-boot-imx).

Voici mon u-boot-imx_2017.03.bbappend

FILESEXTRAPATHS_prepend := "${THISDIR}:"

SRC_URI += "file://defconfig"

Je l'ai aussi ajouté aux "BBFILES" dans mon layer.conf

Je reconstruis u-boot comme suit: 

bitbake -f -D u-boot-imx -c compile

Lorsque je fais cela, le fichier .config dans le répertoire de construction revient à la configuration par défaut (pas ma version modifiée) et le binaire u-boot résultant n'a pas la modification (délai de démarrage toujours 3 secondes). 

Je pense que ma couche est en cours de traitement car je le vois dans la sortie: 

DEBUG: Appending .bbappend file /home/bob/yocto/morty/sources/meta-mylayer/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bbappend to /home/bob/yocto/morty/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb

Je ne vois aucune sortie de débogage indiquant une erreur (par exemple, impossible de trouver mon fichier defconfig). 

Comment puis-je apporter ce genre de changement à la configuration u-boot avec Yocto?

===== EDIT =====

J'ai suivi les instructions de la réponse de LetoThe2nd ci-dessous. Voici ce que j'ai trouvé: 

bitbake-layers show-appends

Utile! Parmi les couches que je vois: 

u-boot-imx_2017.03.bb:
  /home/bob/yocto/morty/sources/meta-mylayer/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bbappend

Donc, on dirait qu'il a trouvé la couche. 

bitbake -e -c clean u-boot-imx | tee build.log

Grepping dans build.log pour "SRC_URI", j'ai trouvé ceci: 

# $SRC_URI [6 operations]
...
# pre-expansion value:
#   "${UBOOT_SRC};branch=${SRCBRANCH} file://defconfig"
SRC_URI="git://git.freescale.com/imx/uboot-imx.git;protocol=git;branch=imx_v2017.03_4.9.11_1.0.0_ga file://defconfig"

Le file: // defconfig vient de mon bbappend.

Grepping pour UBOOT_MACHINE, j'ai trouvé: 

# $UBOOT_MACHINE [2 operations]
...
UBOOT_MACHINE=" mx6ull_14x14_evk_config"

Cela semble correct! 

J'ai vérifié le fichier .config dans le répertoire de construction de u-boot-imx; c'est toujours incorrect.

(J'ai comparé la valeur de CONFIG_BOOTDELAY dans defconfig de ma couche avec la valeur de .config dans le répertoire de construction de u-boot-imx).

===== EDIT 2 =====

J'ai suivi la suggestion 1 dans l'addenda à la réponse de LetoThe2nd ci-dessous. C'est à dire.:

  • Créez un correctif pour le fichier xxx_defconfig utilisé lors de la construction de u-boot-imx pour ma carte evk (dans ce cas, [SOURCE DIR]/configs/mx6ull_14x14_evk_defconfig)

  • Placez le patch dans mon répertoire de couche avec le .bbappend

  • Changé .bbappend pour regarder la ligne ceci: 

_ 

FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += " file://mx6ull_14x14_evk_defconfig.patch;patchdir=${S}/configs "
  • Notez l’utilisation de patchdir = $ {S}/configs - ainsi, bitbake sait où appliquer le correctif, c’est-à-dire [SOURCE DIR]/configs. Voir cette question

Cela a fonctionné! (c’est-à-dire que le délai d’initialisation automatique ajusté que j’ai mis dans le patch a été utilisé dans u-boot-imx). 

Je n'ai pas essayé la suggestion 2 car la première méthode sonnait mieux. 

linuxembeddedyoctobitbake
4
Jeremy

Techniquement, le processus que vous avez décrit me semble correct. Mais il y a quelques obstacles à surveiller et à vérifier:

  1. votre .bbappend est-il réellement traité?

Bien que cela semble être le cas pour vous (vous l'avez découvert grâce à la sortie de débogage), ceci est généralement plus facile à vérifier avec:

bitbake-layers show-appends

Cela vous donnera une liste complète et détaillée de toutes les annexes en vigueur dans votre situation actuelle.

  1. Est-ce que le .bbappend a effectivement l'effet désiré?

Si plusieurs recettes sont impliquées, les choses peuvent être compliquées et se remplacer mutuellement. Vérifier avec

bitbake -e u-boot-imx

pour voir ce qui se passe réellement. Il est préférable de combiner cette opération avec une diffusion dans less (ou le pageur de votre choix), puis la recherche des valeurs modifiées, comme SRC_URI.

  1. Découvrez ce qu'est votre machine u-boot.

Compte tenu des informations de 2., ceci est plutôt trivial: recherchez la variable appelée

UBOOT_MACHINE

car c’est ce que u-boot devrait vraiment voir.

  1. Essayez de ne pas dire à BitBake quoi faire trop de détails.

La combinaison des commutateurs -f et -c peut avoir des résultats inattendus, car vous bricolez les dépendances des tâches. D'après mon expérience, quelque chose de long

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

devrait mieux fonctionner, car il traverse toute la dépendance de la construction, y compris la configuration, les correctifs, etc.

EDIT/ADDENDUM

J'ai vérifié avec les développeurs OE, et le problème principal est que le mécanisme de defconfig est spécifique au noyau (linux), ce qui explique également pourquoi cela est expliqué dans le manuel du noyau.

Donc, pour obtenir votre configuration dans la construction réelle, il existe une solution et demie.

  1. La bonne façon:

Préparez un correctif pour les sources u-boot. Dans votre cas, il s’agit probablement d’une modification mineure du fichier defconfig déjà utilisé. Avoir le patch dans le format canonique et l'ajouter à SRC_URI, alors il devrait automatiquement être ramassé et faire l'affaire.

  1. Le hackish (et non testé, donc seulement la moitié):

Préparez votre configuration en format complet (pas la version simplifiée de defconfig). Ajoutez-le ensuite à SRC_URI et utilisez-le pour une tâche supplémentaire dans votre .bbappend:

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

Cela devrait injecter la nouvelle configuration directement avant le début de la compilation. Il faudra peut-être un peu de bricolage, mais vous avez certainement l’idée. Une autre approche serait d’injecter votre defconfig sur le fichier d’origine.

Cela dit, je recommande fortement la première façon.

3
LetoThe2nd

il n'est pas nécessaire de copier l'intégralité du fichier .config privé dans le dossier de compilation u-boot. S'il est nécessaire de modifier certains paramètres dans defconfig, sed fonctionne parfaitement dans la méthode do_compile_prepend. Exemple:

`

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

`

les espaces sont parfaitement acceptables dans les motifs de recherche et de remplacement. ${BOARD_DEVICE_TREE} pourrait être défini dans l’un des fichiers de configuration du Yocto. cette méthode fonctionne également bien pour les fichiers source/en-tête déjà corrigés avec une liste de correctifs basée sur une recette.

0
Oleg Kokorin