Bis OSD335X U-Boot auf einer benutzerdefinierten Karte ausführt (Hinweis) https://qiita.com/nonNoise/items/ef6702fd666421bd5688
Jetzt, da ich sehen kann, wie U-Boot funktioniert, lassen Sie uns darüber sprechen.
Wenden Sie einen Patch auf U-Boot an
wget -c https://rcn-ee.com/repos/git/u-boot-patches/v2018.01/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch wget -c https://rcn-ee.com/repos/git/u-boot-patches/v2018.01/0002-U-Boot-BeagleBone-Cape-Manager.patch wget -c https://raw.githubusercontent.com/RobertCNelson/Bootloader-Builder/master/patches/v2018.03-rc1/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
patch -p1 < 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch patch -p1 < 0002-U-Boot-BeagleBone-Cape-Manager.patch patch -p1 < 0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
Ich habe nach U-Boot-Patches gesucht. Ich möchte U-Boot für das Original-Board anpassen. Zuerst habe ich mir angesehen, was Pach überhaupt gemacht hat. Ich habe nach der Quelle gesucht und gedacht, dass es sich um kompilierten Inhalt handelt, aber ich kann ihn nicht finden. Ich habe es vor dem Kompilieren gepatcht ... vielleicht ...
Die Patch-Datei war normalerweise eine Datei, die Git-Diff-Informationen enthielt. Ich sehe, es gab einen Patch-Befehl. Wenn Sie also glauben, dass es einen Mechanismus gibt, ist es ein solcher Mechanismus? In diesem Fall frage ich mich, ob ich meinen eigenen Patch erstellen kann, indem ich den Unterschied zwischen den Patches erfasse, die Quelle des U-Boot-Hauptgeräts neu schreibe und den Unterschied als Patch verwende. Ich verstehe, ich wusste es nicht.
Wenn Sie sich die Diff-Informationen von git ansehen, ist es praktisch, auf einen Blick zu wissen, mit welcher Datei Sie gespielt haben
◎ 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
◎ 0002-U-Boot-BeagleBone-Cape-Manager.patch
◎ 0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
Beim Betrachten von Diff stellte ich fest, dass dieselbe Datei von verschiedenen Patches verarbeitet wurde. Daher dachte ich, dass ein Konflikt in der Reihenfolge zu Konflikten führen würde.
Vorerst eins nach dem anderen
◎ 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
Es ist der erste Patch, der angewendet wird. am335x_pocketbeagle_defconfig wurde am meisten geändert. Dies ist ein Block von U-Boot / configs, und es scheint, dass welche Funktion auf y / n gesetzt ist.
◎ 0002-U-Boot-BeagleBone-Cape-Manager.patch
Der nächste Patch, der angewendet werden soll. board / ti / am335x / board.c hat sich am meisten verändert. Ich habe das Gefühl, dass ich hier einen Patch auf das Board bringe. Insbesondere BeagleBone-Cape, ein etwas neueres Board in BeagleBone https://github.com/u-boot/u-boot/tree/master/board/ti/am335x
◎ 0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
Der letzte Patch, den ich angewendet habe. board / ti / common / board_detect.c hat sich am meisten verändert. Da es üblich ist, habe ich das Gefühl, dass es die kartenspezifische Schnittstelle (externe Erweiterungsfunktion) modifiziert. https://github.com/u-boot/u-boot/tree/master/board/ti/common
weiß nicht. Schließlich denke ich, es geht darum, die grundlegende U-Boot-Quelle zu betrachten, dann die Unterschiede zwischen den drei Arten von Patches zu erfassen und den Korrektur-Patch anzuwenden, den ich ausführen möchte. Da es sich um einen Diff handelt, wird der korrigierte (gelöschte) Teil als Minus angezeigt. Wenn Sie also vorerst 3 Arten von Patches anwenden und dann mit der Quelle spielen und den Diff verlassen, wird meiner Meinung nach ein hoch reproduzierbarer U-Boot-Patch abgeschlossen. ..
Ich möchte den Patch mit der neuesten U-Boot-Version neu erstellen, aber das ist wahrscheinlich eine Technik mit unterschiedlichem Verständnis und Quellenverständnis.
Recommended Posts