Forum: Compiler & IDEs Falsches Boot/ eMMC nicht erkannt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Preg M. (omegaprimus)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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).

von Preg M. (omegaprimus)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Preg M. (omegaprimus)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von nicht angezeigt (Gast)


Lesenswert?

Wieso dafür im Sourcecode wühlen?

Das lässt sich doch mit UBoot Env Variablen bewältigen?!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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 …

von nicht angezeigt (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von nicht angezeigt (Gast)


Lesenswert?

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.

von nicht angezeigt (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von nicht angezeigt (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.