Hallo An vielen Stellen (TF-A, U-Boot, Kernel, FlashLayout_emmc.tsv ...) wird davon ausgegangen, dass es eine SD card gibt die "mmc0" heißt und optional eine eMMC "mmc1" In meinem Fall habe ich aber nur eine eMMC und KEINE SD. Dadurch heißt die eMMC aber "mmc0" und nicht "mmc1". U-boot bootet falsch, und zwar den rchtigen Kernel, der Kernel findet nicht die richtige Partition, im Flashlayout_emmc steht das falsche mmc1 usw. Ich benutze eine STM32MP157C und baue ein Yocto-Based Kernel. VG
Mehdi J. schrieb: > U-boot bootet falsch, und zwar den rchtigen Kernel, der Kernel findet > nicht die richtige Partition, im Flashlayout_emmc steht das falsche mmc1 > usw. Da ich an dieser Stelle gerade selbst (dienstlich) herum wurschtele: das Flashlayout-File ist nur fürs Flashen da. Das U-Boot musst du dann halt passend modifizieren, dass der gebootete Kernel das rootfs von der richtigen Stelle lädt. Das steckt da mehr oder minder alles in irgendwelchen Bitbake-Files oder teils auch im Sourcecode in Strings drin, die vom U-Boot dann nach dem Start interpretiert werden. Benutze das U-Boot erstmal interaktiv (beim Start rechtzeitig die Leertaste drücken) von der Console aus, um herauszufinden, was du da an Variablen im U-Boot vorfindest und wie du diese modifizieren musst, damit der gebootete Kernel dann sein rootfs findet. Prinzipiell kannst du im Linux das rootfs ja auf verschiedene Weise festlegen (Partition UUID, Filesystem UUID, einfacher Gerätename).
Jörg W. schrieb: > Mehdi J. schrieb: >> U-boot bootet falsch, und zwar den rchtigen Kernel, der Kernel findet >> nicht die richtige Partition, im Flashlayout_emmc steht das falsche mmc1 >> usw. > > Da ich an dieser Stelle gerade selbst (dienstlich) herum wurschtele: das > Flashlayout-File ist nur fürs Flashen da. > > Das U-Boot musst du dann halt passend modifizieren, dass der gebootete > Kernel das rootfs von der richtigen Stelle lädt. Das steckt da mehr oder > minder alles in irgendwelchen Bitbake-Files oder teils auch im > Sourcecode in Strings drin, die vom U-Boot dann nach dem Start > interpretiert werden. > > Benutze das U-Boot erstmal interaktiv (beim Start rechtzeitig die > Leertaste drücken) von der Console aus, um herauszufinden, was du da an > Variablen im U-Boot vorfindest und wie du diese modifizieren musst, > damit der gebootete Kernel dann sein rootfs findet. Prinzipiell kannst > du im Linux das rootfs ja auf verschiedene Weise festlegen (Partition > UUID, Filesystem UUID, einfacher Gerätename). Danke für deine detaillierte Antwort. Noch ne Frage. Ich muss auf dem Host das U-Boot File finden und darin was modifizieren. Weißt du nicht, ob es ein Standard Filename gibt? Wie nennt man dieses File bei dir? Und was hast du genau modifiziert, wenn ich fragen darf?
Mehdi J. schrieb: > Ich muss auf dem Host das U-Boot File finden und darin was modifizieren. Das baust du dir doch im Yocto-Build selbst. Da modifizierst du dir den Sourcecode, nicht etwa das Binary. Meine Änderung besteht hier aus einem .bbappend-File, welches einen Patch lädt, der die Zeile
1 | #define STM32MP_BOOTCMD "bootcmd_stm32mp="
|
um ein paar Kommandos ergänzt, damit man im Bedarfsfall (automatisch) von einem USB-Stick statt eMMC / SD-Karte booten kann.
Aber die ganze Sache mit dem bitbake hat schon eine gewisse Komplexität, wenn man es mit sonst üblichen Build-Systemen vergleicht. Du musst dich da selbst mal mit ein wenig trial&error durch wühlen, da wirst du nicht drum herum kommen.
Jörg W. schrieb: > Mehdi J. schrieb: >> Ich muss auf dem Host das U-Boot File finden und darin was modifizieren. > > Das baust du dir doch im Yocto-Build selbst. Da modifizierst du dir den > Sourcecode, nicht etwa das Binary. > > Meine Änderung besteht hier aus einem .bbappend-File, welches einen > Patch lädt, der die Zeile > #define STM32MP_BOOTCMD "bootcmd_stm32mp=" > > um ein paar Kommandos ergänzt, damit man im Bedarfsfall (automatisch) > von einem USB-Stick statt eMMC / SD-Karte booten kann. Ich muss "nur" noch schauen, wie man die Patches in das Buildsystem von Yocto bringt. Ich möchte so wenige Repositories wie möglich verändern müssen. Ich habe noch eine Stelle, an der ich im Quelltext die "boot_instance" hart mit 0 überschreibe. Lieber wäre mir eine entsprechende Konfiguration, sodass der Quelltext nicht gepatcht werden muss. Mir ist noch nicht klar, wer die "boot_instance" setzt. Diese steht beim Bootmode 0xb010 auf 1 und wird dann im "bootcmd" (falsch) in mmc1 übersetzt. U-Boot erkennt aber die eMMC als mmc0.Dadurch kann auch das UBoot Environment nicht gelesen werden, weil es auch auf mmc1 erwartet wird.
Preg M. schrieb: > Mir ist noch nicht klar, wer die "boot_instance" setzt. Wie schon geschrieben: schau dich mal einen Tag lang interaktiv im U-Boot auf deren Kommandozeile um, analysiere die diversen Variablen dort und versuche nachzuvollziehen, wie sie zu den entsprechenden Entscheidungen gekommen sind. Ich hab da auch 'ne Weile wie ein Schwein aufs Uhrwerk geguckt. Solange du das nicht verstanden hast, kannst du dann aber schlecht einen Patch und ein .bbappend für den Patch zimmern.
Wieso dafür im Sourcecode wühlen? Das lässt sich doch mit UBoot Env Variablen bewältigen?!
nicht angezeigt schrieb: > Das lässt sich doch mit UBoot Env Variablen bewältigen?! Und die kommen woher? Aus der Luft? Von der seriellen Schnittstelle? Irgendwie müssen sie in das U-Boot hinein kommen, und das ist halt wieder Sourcecode …
Jörg W. schrieb: > nicht angezeigt schrieb: >> Das lässt sich doch mit UBoot Env Variablen bewältigen?! > > Und die kommen woher? Die lassen sich selbstverständlich via UBoot Konsole setzen, evtl. über ein Uboot Script Leider hat das Pasten grösserer Textblöcke in die Konsole seine Grenzen in der UBoot-Linebuffer-Kapazität. > > Aus der Luft? Von der seriellen Schnittstelle? > Ja, genau! Von der Seriellen, die die Konsole bedient. Konsole kann aber auch auf einen Netzwerkport gelegt werden. > Irgendwie müssen sie in das U-Boot hinein kommen, und das ist halt > wieder Sourcecode … Nur das Default Env. Aber das interessiert ja höchstens dann, wenn es das Hochkommen der Konsole verhindert. Die auf der Konsole gesetzten Variablen kann man dann ja per saveenv Kommando im Uboot Env dauerhaft speichern, aber ich denke das weisst Du sowieso.
nicht angezeigt schrieb: > Nur das Default Env. Um den Default ging es aber. > Die auf der Konsole gesetzten Variablen kann man dann ja > per saveenv Kommando im Uboot Env dauerhaft speichern, aber ich denke > das weisst Du sowieso. Bin ich mir nicht so sicher, dass das beim STM32MP157 tatsächlich implementiert ist. Wohin sollte er das Environment sichern? Der hat keinen EEPROM (nur OTP), und ob er in seine eigene U-Boot-Partition schreiben kann, habe ich mir noch nicht angesehen. Bei der nächsten Neuinstallation wäre das dann sowieso wieder futsch. Da man so ein Yocto sowieso letztlich from scratch compiliert, sehe ich jetzt auch keinen sinnvollen Grund, warum man das nicht gleich im Sourcecode (per passendem Rezept für die Bitbäckerei) so hinbiegen sollte, dasss es auf genau dieser Plattform funktioniert.
Preg M. schrieb: > Jörg W. schrieb: >> Mehdi J. schrieb: >>> Ich muss auf dem Host das U-Boot File finden und darin was modifizieren. > übersetzt. U-Boot erkennt aber die eMMC als mmc0.Dadurch kann auch das > UBoot Environment nicht gelesen werden, weil es auch auf mmc1 erwartet > wird. Das UBoot selbst erwartet sein Env m.W. unter einer bestimmten Flash-Adresse. Das wird irgendwo im Sourcecode festgelegt, vielleich per dem oben diskutierten Flash_layout und muss halt im erreichbaren Flash-Bereich liegen. In dem Projekt, indem ich zuletzt ein UBoot benutzt habe, waren die ersten drei Flash-Blöcke für den UBoot Code, Block 4 für das Env. Ob das mmc0 oder mmc1 oder was weiss ich ist, dürfte dem UBoot egal sein, bzw. spielt nur eine Rolle in bezug auf den zu bootenden Kernel.
Jörg W. schrieb: > nicht angezeigt schrieb: > >> Nur das Default Env. > > Um den Default ging es aber. > >> Die auf der Konsole gesetzten Variablen kann man dann ja >> per saveenv Kommando im Uboot Env dauerhaft speichern, aber ich denke >> das weisst Du sowieso. > > Bin ich mir nicht so sicher, dass das beim STM32MP157 tatsächlich > implementiert ist. Wohin sollte er das Environment sichern? Der hat Natürlich im Flash, das Uboot enthält ja Code/kommandos zum Flash-Handling, sofern nicht wegkonfiguriert oder wenn das verwendete Flash vom UBoot nicht unterstützt wird. > keinen EEPROM (nur OTP), und ob er in seine eigene U-Boot-Partition > schreiben kann, habe ich mir noch nicht angesehen. Bei der nächsten > Neuinstallation wäre das dann sowieso wieder futsch. Nicht dann, wenn man den Env-Flash-Block beim Löschen verschont. Oder das Env sichert und nach dem Neuinstallieren wieder flasht. Es wäre jedenfalls äusserst lästig, wenn man mit dem Default-Env auskommen müsste, da würde ja die kleinste Konfigurations-Änderung einen Yocto-Rebuild brauchen.... Ich habe mir oft verschiedene Sätze von Env-Variablen in Textfiles geschrieben, z.B für Boot von Flash, SDCard, USB, wasweissich, und die jeweils in die Konsole gepastet oder auch einfach per Perl-Skript auf die Konsolen-Serielle geblasen, um schnell und schmerzfrei umschalten zu können. > > Da man so ein Yocto sowieso letztlich from scratch compiliert, sehe ich > jetzt auch keinen sinnvollen Grund, warum man das nicht gleich im > Sourcecode (per passendem Rezept für die Bitbäckerei) so hinbiegen > sollte, dasss es auf genau dieser Plattform funktioniert. Kann man natürlich tun, wenn man weiss wo eingreifen muss. So gesehen, spricht da nix dagegen. Der Weg über das Env funktioniert schmerzfreier, jedenfalls wenn man das Uboot unabhängig von Yocto oder welchem anderen Build-Env benutzt. Da muss man nur wissen, wie das Boot-Kommando auszusehen hat. Im Yocto-Kontext mag ein Sourcecode-Patch aber durchaus sinnvoller sein.
nicht angezeigt schrieb: > Natürlich im Flash, das Uboot enthält ja Code/kommandos zum > Flash-Handling, > sofern nicht wegkonfiguriert oder wenn das verwendete Flash vom UBoot > nicht unterstützt wird. Genau letzteres ist ja offenbar das Problem des TE: der originale (von STM gewartete und verteilte) Sourcecode enthält als Defaults überall mmc0, aber sein eMMC ist mmc1. Dem ROM-Lader ist das egal, der lädt das von beiden (bzw. er lädt den fsbl, der dann das U-Boot lädt), aber wenn U-Boot dann das Environment von einem nicht vorhandenen Flash lesen will, hilft das halt nicht viel. Henne und Ei und so. Irgendwo muss er da in den Build bzw. dessen Konfiguration schon mal eingreifen.
Jörg W. schrieb: > nicht angezeigt schrieb: > >> Natürlich im Flash, das Uboot enthält ja Code/kommandos zum >> Flash-Handling, >> sofern nicht wegkonfiguriert oder wenn das verwendete Flash vom UBoot >> nicht unterstützt wird. > > Genau letzteres ist ja offenbar das Problem des TE: der originale (von > STM gewartete und verteilte) Sourcecode enthält als Defaults überall > mmc0, aber sein eMMC ist mmc1. Dem ROM-Lader ist das egal, der lädt das > von beiden (bzw. er lädt den fsbl, der dann das U-Boot lädt), aber wenn > U-Boot dann das Environment von einem nicht vorhandenen Flash lesen > will, hilft das halt nicht viel. Henne und Ei und so. > Das wäre schon ein besonderer Fall von Andersbegabung auf Seiten der ST-Programmierer. Meiner Erfahrung (u.a zuletzt auch mit einem ST SoC, aber nicht mit STM32xxx) nach ist es so wie in Beitrag "Falsches Boot/ eMMC nicht erkannt" (Beitrag von 0:26, falls der Link nicht passt) beschrieben. Da es aber Zilliarden unterschiedlich Konfigs gibt, schliesse ich nichts aus.... Bisher hat das mit dem Env aber noch bei jeder Platform mit Uboot funktioniert, die ich in den Fingern hatte. Es liesse sich ja leicht überprüfen, ob saveenv eine Wirkung hat... Man will ja auch mit dem UBoot ein Image flashen können. Deswegen müss(t)en Flash-Management Routinen verfügbar sein. Wenn das ausgerechnet auf das Env nicht anwendbar sein sollte, erschiene mir das unplausibel... > Irgendwo muss er da in den Build bzw. dessen Konfiguration schon mal > eingreifen.
nicht angezeigt schrieb: > Es liesse sich ja leicht überprüfen, ob saveenv eine Wirkung hat... Bei mir funktioniert es, aber ich arbeite auch auf mmc0. Anyway, wenn er eine dauerhafte Lösung haben will, ist es sinnvoller, das in der Bitbäckerei zu patchen, denn dann wird es beim nächsten Deployment wieder genau so geschrieben. Wenn es sich nur um eine Einzellösung handeln soll, kann man das sicher auch manuell aus dem U-Boot heraus zurecht fummeln. eMMC klingt aber nicht nach Einzellösung sondern nach geplanter Serie. (Das Evalboard hat kein eMMC, nur eine SD-Karte.)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.