web-dev-qa-db-de.com

So ändern Sie die Konfiguration von u-boot in Yocto

Erstellen von Linux für ein iMX6-Dev-Board mit dem Yocto-Projekt, und ich möchte die .config ändern, die zum Erstellen von u-boot-imx verwendet wird (u-boot für das iMX-Dev-Board) - z. Ändern Sie die Auto-Boot-Verzögerung als Beispiel auf 1 Sekunde. 

Ich kann die config bearbeiten (z. B. das build-Verzeichnis finden und make menuconfig ausführen), aber wenn ich bitbake zum Wiederherstellen des Images ausführen, überschreibt es die .config erneut mit der Standardeinstellung. Es gibt viele xxx_defconfig-Dateien, und ich weiß nicht, welche es verwendet. 

Ich habe diesem Leitfaden für die Kernelkonfiguration mit dem Yocto-Projekt gefolgt. Ich habe eine Änderung an der .config-Datei vorgenommen, sie in meine Ebene kopiert und in "defconfig" umbenannt. Ich habe eine neue Ebene mit einem u-boot-imx_2017.03.bbappend erstellt, um u-boot-imx_2017.03.bb zu erweitern (das Rezept für u-boot-imx).

Hier ist mein u-boot-imx_2017.03.bbappend

FILESEXTRAPATHS_prepend := "${THISDIR}:"

SRC_URI += "file://defconfig"

Ich habe es auch zu den "BBFILES" in meiner layer.conf hinzugefügt

Ich baue u-boot wie folgt um: 

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

Wenn ich dies tue, wird die .config-Datei im Build-Verzeichnis auf die Standardkonfiguration (nicht meine geänderte Version) zurückgesetzt, und die resultierende U-Boot-Binärdatei hat keine Änderung (Startverzögerung noch 3 Sekunden). 

Ich denke, dass meine Ebene verarbeitet wird, weil ich dies in der Ausgabe sehe: 

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

Ich kann keine Debug-Ausgabe sehen, die besagt, dass ein Fehler aufgetreten ist (meine defconfig-Datei konnte beispielsweise nicht gefunden werden). 

Wie ändere ich diese Art der Änderung der U-Boot-Konfiguration mit Yocto?

===== BEARBEITEN =====

Ich folgte den Anweisungen von LetoThe2nds Antwort unten. Folgendes habe ich gefunden: 

bitbake-layers show-appends

nützlich! Unter den Schichten sehe ich: 

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

So wie es aussieht, hat es die Schicht gefunden. 

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

Als ich in build.log nach "SRC_URI" suchte, habe ich folgendes gefunden: 

# $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"

Die Datei: // defconfig stammt aus meinem bbappend.

Grepping für UBOOT_MACHINE, fand ich: 

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

Das sieht richtig aus! 

Ich habe die .config im Buildverzeichnis von u-boot-imx überprüft. es ist noch falsch .

(Ich habe den Wert von CONFIG_BOOTDELAY in defconfig von meiner Ebene mit dem Wert in .config im build-Verzeichnis für u-boot-imx verglichen).

===== BEARBEITEN 2 =====

Ich folgte dem Vorschlag 1 im ADDENDUM zu LetoThe2nds Antwort unten. I.e .:

  • Erstellen Sie einen Patch für die xxx_defconfig-Datei, die beim Erstellen von u-boot-imx für mein evk-Board verwendet wird (in diesem Fall [SOURCE DIR]/configs/mx6ull_14x14_evk_defconfig ).

  • Platziere den Patch in meinem Layer-Verzeichnis mit dem .bbappend

  • .Bbappend wurde folgendermaßen geändert: 

FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += " file://mx6ull_14x14_evk_defconfig.patch;patchdir=${S}/configs "
  • Beachten Sie die Verwendung von patchdir = $ {S}/configs - so dass Bitbake weiß, wo der Patch angewendet werden soll, d. H. [SOURCE DIR]/configs. Siehe diese Frage

Das hat funktioniert! (Die eingestellte Auto-Boot-Verzögerung, die ich in den Patch eingefügt habe, wurde in u-boot-imx verwendet). 

Ich habe Vorschlag 2 nicht ausprobiert, da die erste Methode besser klang. 

4
Jeremy

Technisch klingt der von Ihnen beschriebene Prozess für mich richtig. Es gibt jedoch ein paar Hindernisse, auf die Sie achten müssen, bzw. auf Dinge, die Sie überprüfen sollten:

  1. wird dein .bbappend tatsächlich verarbeitet?

Während dies für Sie der Fall zu sein scheint (Sie haben es durch die Debug-Ausgabe herausgefunden), ist dies normalerweise einfacher zu überprüfen:

bitbake-layers show-appends

Dadurch erhalten Sie eine vollständige und detaillierte Liste aller Anhänge, die in Ihrer aktuellen Build-Situation wirksam sind.

  1. Hat das .bbappend tatsächlich den gewünschten Effekt?

Wenn mehr als ein Rezept betroffen ist, können die Dinge kompliziert sein und sich überschreiben. Überprüfen Sie mit

bitbake -e u-boot-imx

um zu sehen, was tatsächlich passiert. Dies wird am besten mit einer Weiterleitung in less (oder dem Pager Ihrer Wahl) kombiniert und dann nach den geänderten Werten wie SRC_URI gesucht.

  1. Finden Sie heraus, was Ihre u-boot-Maschine ist.

Angesichts der Informationen aus 2. ist dies eher trivial: Prüfen Sie, ob die Variable aufgerufen wird

UBOOT_MACHINE

da sollte u-boot wirklich sehen.

  1. Versuchen Sie, Bitbake nicht zu sagen, was zu tun ist.

Insbesondere das Kombinieren der Optionen -f und -c kann zu unerwarteten Ergebnissen führen, da Sie im Wesentlichen mit den Abhängigkeiten der Aufgaben basteln. Nach meiner Erfahrung etwas entlang

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

sollte besser funktionieren, da es die gesamte Build-Abhängigkeit durchmacht, einschließlich Konfiguration, Patches usw.

BEARBEITEN/ADDENDUM

Ich habe mit den OE-Entwicklern nachgefragt, und das Hauptproblem ist, dass der Mechanismus defconfig (linux-) kernelspezifisch ist. Deswegen wird er auch im Kernel-dev-Handbuch erklärt.

Um Ihre Konfiguration in den eigentlichen Build zu bringen, gibt es eineinhalb Lösungen.

  1. Der richtige Weg:

Bereiten Sie einen Patch für die U-Boot-Quellen vor. In Ihrem Fall ist dies wahrscheinlich nur eine geringfügige Änderung der bereits verwendeten defconfig-Datei. Habe den Patch im kanonischen Format und füge ihn zu SRC_URI hinzu, dann sollte er automatisch abgeholt werden und den Trick ausführen.

  1. Der hackische (und ungeprüfte, also nur halbwegs) Weg:

Bereiten Sie Ihre Konfiguration im vollständigen Format vor (nicht die defconfig-Version). 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 dem Kompilieren einfügen. Möglicherweise müssen Sie ein bisschen basteln, aber Sie haben bestimmt die Idee. Ein anderer Ansatz wäre, Ihre defconfig über die Originaldatei zu injizieren.

Trotzdem empfehle ich den ersten Weg.

3
LetoThe2nd

es ist nicht notwendig, die gesamte private .config-Datei in den U-Boot-Build-Ordner zu kopieren. Wenn Sie einige Einstellungen in defconfig ändern müssen, funktioniert sed auch in der do_compile_prepend-Methode einwandfrei. 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 eignet sich auch für Quell-/Headerdateien, die bereits mit einer auf Rezept basierenden Patchliste gepatcht wurden.

0
Oleg Kokorin