È possibile aggiungere defconfig come file normale, ad esempio sto incollando alcuni bbappend funzionanti:
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/ \
"
Quindi la riga "file://am335x_cmpc30_defconfig;subdir=git/configs/" inserisce l'intero defconfig nel codice sorgente di u-boot.
non è necessario copiare l'intero .config privato file nella cartella build di u-boot, se è necessario modificare alcune impostazioni all'interno di defconfig, sed funziona perfettamente all'interno del do_compile_prepend anche il metodo. esempio:
`
do_configure_prepend() {
sed -i -e 's,CONFIG_DEFAULT_DEVICE_TREE=,CONFIG_DEFAULT_DEVICE_TREE= ${BOARD_DEVICE_TREE},g' ${S}configs/mx7ulp_evk_defconfig
}
`
gli spazi sono perfettamente OK all'interno dei modelli di ricerca e sostituzione. ${BOARD_DEVICE_TREE} potrebbe essere definito in uno dei file di configurazione di Yocto. questo metodo funziona bene anche per i file sorgente/header che sono già stati patchati con un elenco di patch basato su ricette.
Tecnicamente il processo che hai descritto mi sembra corretto. Ma ci sono un paio di ostacoli a cui prestare attenzione, rispettivamente cose da controllare:
- il tuo .bbappend è effettivamente elaborato?
Anche se questo sembra essere il tuo caso (l'hai scoperto tramite l'output di debug), di solito è più facile verificarlo con:
bitbake-layers show-appends
Questo ti darà un elenco completo e dettagliato di tutte le aggiunte che sono attive nella tua attuale situazione di costruzione.
- Il .bbappend ha effettivamente l'effetto desiderato?
Se è coinvolta più di una ricetta, le cose possono essere complicate e sovrascriversi a vicenda. Verifica con
bitbake -e u-boot-imx
per vedere cosa succede realmente. È meglio combinarlo con il piping in less (o il cercapersone di tua scelta) e quindi cercare i valori modificati, come SRC_URI.
- Scopri qual è la tua macchina u-boot.
Date le informazioni da 2., questo è piuttosto banale:controlla la variabile chiamata
UBOOT_MACHINE
poiché questo è ciò che u-boot dovrebbe realmente vedere.
- Cerca di non dire a bitbake cosa fare in modo troppo dettagliato.
Soprattutto la combinazione delle opzioni -f e -c potrebbe avere risultati inaspettati, dato che in pratica armeggi con le dipendenze delle attività. Nella mia esperienza, qualcosa insieme
bitbake -c clean u-boot-imx && bitbake u-boot-imx
dovrebbe funzionare meglio, in quanto passa attraverso l'intera dipendenza della build, inclusa la configurazione, l'applicazione di patch e così via.
MODIFICA/AGGIUNTA
Ho verificato con gli sviluppatori dell'ambiente operativo e il problema principale è che il meccanismo defconfig è specifico del kernel (linux), ecco perché è spiegato nel manuale kernel-dev.
Quindi, per inserire la tua configurazione nella build effettiva, ci sono una soluzione e mezza.
- Il modo corretto:
Preparare una patch per i sorgenti di u-boot. Nel tuo caso, questa è probabilmente solo una piccola modifica al file defconfig che è già in uso. Avere la patch nel formato canonico e aggiungerla a SRC_URI, quindi dovrebbe essere prelevata automaticamente e fare il trucco.
- Il modo hacker (e non testato, quindi solo a metà):
Prepara la tua configurazione in formato completo (non la versione ridotta di defconfig). Quindi aggiungilo a SRC_URI e usalo tramite un'attività aggiuntiva nel tuo .bbappend:
do_compile_prepend() {
cp YOURFILENAME ${S}/.config
}
Questo dovrebbe iniettare la nuova configurazione direttamente prima dell'inizio della compilazione. Potrebbe aver bisogno di un piccolo ritocco, ma sicuramente hai avuto l'idea. Un altro approccio sarebbe quello di iniettare il tuo defconfig sul file originale.
Detto questo, consiglio vivamente il primo modo.