Il est possible d'ajouter defconfig en tant que fichier normal, à titre d'exemple, je colle quelques bbappend fonctionnels :
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/ \
"
Ainsi, la ligne "file://am335x_cmpc30_defconfig;subdir=git/configs/" met en fait tout le defconfig dans le code source de u-boot.
pas nécessaire de copier tout le .config privé fichier dans le dossier de construction u-boot, s'il est nécessaire de modifier certains paramètres dans defconfig, sed fonctionne parfaitement bien à l'intérieur du do_compile_prepend méthode aussi. 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 OK à l'intérieur des modèles de recherche et de remplacement. ${BOARD_DEVICE_TREE} peut être défini dans 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 la recette.
Techniquement, le processus que vous avez décrit me semble correct. Mais il y a quelques obstacles à surveiller, respectivement des choses à vérifier :
- 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), cela 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 tous les ajouts qui sont en vigueur dans votre situation de construction actuelle.
- Le .bbappend a-t-il réellement l'effet souhaité ?
Si plus d'une recette est impliquée, les choses peuvent être compliquées et s'écraser les unes les autres. Vérifiez avec
bitbake -e u-boot-imx
pour voir ce qui se passe réellement. Il est préférable de combiner cela avec un tuyau vers less (ou le pager de votre choix), puis en recherchant les valeurs modifiées, comme SRC_URI.
- Découvrez quelle est votre machine u-boot.
Compte tenu des informations de 2., c'est plutôt trivial :vérifiez la variable appelée
UBOOT_MACHINE
car c'est ce que u-boot devrait vraiment voir.
- Essayez de ne pas dire trop de détails à bitbake.
En particulier, la combinaison des commutateurs -f et -c peut avoir des résultats inattendus, car vous modifiez essentiellement les dépendances des tâches. D'après mon expérience, quelque chose le long
bitbake -c clean u-boot-imx && bitbake u-boot-imx
devrait mieux fonctionner, car il passe par toute la dépendance de construction, y compris la configuration, les correctifs, etc.
MODIFIER / ADDENDA
J'ai vérifié auprès des développeurs OE, et le principal problème est que le mécanisme de defconfig est spécifique au noyau (linux), c'est aussi pourquoi il est expliqué dans le manuel du noyau de développement.
Donc, pour intégrer votre configuration dans la version réelle, il existe une solution et demie.
- La bonne méthode :
Préparez un correctif pour les sources de u-boot. Dans votre cas, c'est probablement juste une modification mineure du fichier defconfig qui est déjà utilisé. Ayez le patch au format canonique et ajoutez-le à SRC_URI, puis il devrait être automatiquement récupéré et faire l'affaire.
- La méthode hackish (et non testée, donc à moitié) :
Préparez votre configuration au format complet (pas la version simplifiée de defconfig). Ajoutez-le ensuite à SRC_URI et utilisez-le via 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émarrage 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 méthode.