Es ist möglich, defconfig als reguläre Datei hinzuzufügen, als Beispiel füge ich einige funktionierende bbappend:
einPR = "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/ \
"
Die Zeile "file://am335x_cmpc30_defconfig;subdir=git/configs/" hat also tatsächlich die gesamte defconfig in den u-boot-Quellcode eingefügt.
Es ist nicht erforderlich, den gesamten privaten .config zu kopieren Datei in den U-Boot-Build-Ordner, wenn es notwendig ist, einige Einstellungen in defconfig zu ändern, sed funktioniert perfekt innerhalb des do_compile_prepend Methode auch. Beispiel:
`
do_configure_prepend() {
sed -i -e 's,CONFIG_DEFAULT_DEVICE_TREE=,CONFIG_DEFAULT_DEVICE_TREE= ${BOARD_DEVICE_TREE},g' ${S}configs/mx7ulp_evk_defconfig
}
`
Leerzeichen sind innerhalb der Such- und Ersetzungsmuster vollkommen in Ordnung. ${BOARD_DEVICE_TREE} könnte in einer der Yocto-Konfigurationsdateien definiert werden. diese Methode funktioniert auch gut für Quell-/Header-Dateien, die bereits mit einer rezeptbasierten Patch-Liste gepatcht sind.
Technisch klingt der von Ihnen beschriebene Prozess für mich korrekt. Aber es gibt ein paar Hindernisse zu beachten bzw. zu überprüfen:
- wird Ihr .bbappend tatsächlich verarbeitet?
Während dies bei Ihnen der Fall zu sein scheint (Sie haben es durch die Debug-Ausgabe herausgefunden), lässt sich dies normalerweise einfacher überprüfen mit:
bitbake-layers show-appends
Dadurch erhalten Sie eine vollständige und detaillierte Liste aller Anhänge, die in Ihrer aktuellen Build-Situation wirksam sind.
- Hat das .bbappend tatsächlich den gewünschten Effekt?
Wenn mehr als ein Rezept beteiligt ist, können die Dinge kompliziert werden und sich gegenseitig überschreiben. Überprüfen Sie mit
bitbake -e u-boot-imx
um zu sehen, was wirklich passiert. Dies lässt sich am besten mit einer Weiterleitung an less (oder den Pager Ihrer Wahl) kombinieren und dann nach den geänderten Werten suchen, wie z. B. SRC_URI.
- Finden Sie heraus, was Ihr U-Boot-Rechner ist.
Angesichts der Informationen aus 2. ist dies ziemlich trivial:Suchen Sie nach der Variablen namens
UBOOT_MACHINE
denn das sollte u-boot wirklich sehen.
- Versuche, Bitbake nicht zu detailliert zu sagen, was zu tun ist.
Insbesondere die Kombination der Schalter -f und -c kann zu unerwarteten Ergebnissen führen, da Sie im Grunde an den Aufgabenabhängigkeiten basteln. Meiner Erfahrung nach etwas entlang
bitbake -c clean u-boot-imx && bitbake u-boot-imx
sollte besser funktionieren, da es die gesamte Build-Abhängigkeit durchläuft, einschließlich Konfiguration, Patching und so weiter.
BEARBEITUNG / NACHTRAG
Ich habe mit den OE-Entwicklern nachgefragt, und das Hauptproblem ist, dass der defconfig-Mechanismus (linux-)kernelspezifisch ist, deshalb wird er auch im Handbuch für Kernel-Entwickler erklärt.
Um also Ihre Konfiguration in den eigentlichen Build zu bekommen, gibt es anderthalb Lösungen.
- Der richtige Weg:
Bereiten Sie einen Patch für die u-boot-Quellen vor. In Ihrem Fall handelt es sich wahrscheinlich nur um eine geringfügige Änderung der bereits verwendeten defconfig-Datei. Haben Sie den Patch im kanonischen Format und fügen Sie ihn zu SRC_URI hinzu, dann sollte er automatisch aufgenommen werden und den Zweck erfüllen.
- Der hackige (und ungetestete, daher nur halbe) Weg:
Bereiten Sie Ihre Konfiguration im vollständigen Format vor (nicht die abgespeckte Version von defconfig). Fügen Sie es dann zu SRC_URI hinzu und verwenden Sie es durch eine zusätzliche Aufgabe in Ihrem .bbappend:
do_compile_prepend() {
cp YOURFILENAME ${S}/.config
}
Dies sollte die neue Konfiguration direkt vor Beginn der Kompilierung injizieren. Es könnte ein wenig Basteln erfordern, aber Sie bekommen sicherlich die Idee. Ein anderer Ansatz wäre, Ihre defconfig über die Originaldatei zu injizieren.
Trotzdem empfehle ich dringend den ersten Weg.