Ich versuche gerade, auf einem STM32MP157 die "hello_world" standalone
App vom U-Boot zum Laufen zu bringen. Ich habe schon rausgefunden, dass
die Standardumgebung auf eine völlig falsche Startadresse
(CONFIG_STANDALONE_LOAD_ADDR) gelinkt hat (0xc100000), weil das einfach
mal der Fallback für "irgendein ARM, der nirgends genannt worden ist"
war. Das wurde korrigiert, die Adresse steht jetzt auf etwas, wo es auf
jeden Fall RAM gibt.
Trotzdem jedoch, wenn ich die App starten will, bekomme ich ein
"undefined instruction", und die Kiste rebootet.
Disassemble:
Die standalone app wird im Rahmen eines normalen U-Boot-Buildprozesses
(in diesem Falle ein bitbake eines Yocto) angeschoben; die
Compileroptionen für U-Boot selbst und für die standalone app sind die
gleichen.
Hat jemand irgendeine Idee?
Könnts sein, dass der Cortex-A7 im ARM statt Thumb Modus läuft?
Leider zeigt dein uboot das CPSR nicht an.
Aber da der PC c4600008 ist undnicht c4600009 gehe ich vom ARM Modus aus
(im Thumb Mode ist das LSB des PC immer 1).
Dann sieht er:
e92d41f0
46054608 <- rumms
460ef000 <- er zeigt hierhin, weil bei einer undef instr bereits der
PC+4 ist (pipelining ;))
Eigentlich müsst dir auch schon das stmdb um die Ohren fliegen.
Der SP sieht komisch aus, is da RAM?
Mw E. schrieb:> Könnts sein, dass der Cortex-A7 im ARM statt Thumb Modus läuft?
Da die standalone App ja im Kontext des U-Boots selbst läuft (und das
Buildsystem sie genau so produziert hat), vermute ich mal, dass U-Boot
intern auf Thumb schaltet. Aber wissen tu ich's nicht … Im Disassembly
vom U-Boot selbst finde ich Vorkehrungen sowohl für ARM als auch Thumb.
Ich könnte natürlich mal gucken, ob ich die Makefiles so modifizieren
kann, dass da ARM-Code generiert wird.
Andererseits: die Compiler-Optionen -mthumb -mthumb-interwork sehe ich
auch im restlichen Compile-Aufruf von U-Boot an vielen Stellen.
Du musst unterscheiden womit uboot gebaut wird und in welchem Modus die
geladene Software gestartet wird.
Aber der PC sagt ARM Modus wegen dem LSB = 0.
Was heißt im Kontext des Uboots selbst läuft?
Uboot läd Images ins RAM, das muss/sollte mit einem Tool packen und per
Header versehen.
Der Header sgat dann zB obs zipepd ist oder ARM/Thumb.
-> https://linux.die.net/man/1/mkimage
Gut, dann ist da schonmal RAM.
Mw E. schrieb:> Du musst unterscheiden womit uboot gebaut wird und in welchem Modus die> geladene Software gestartet wird.
Naja, die Software gehört ja (als Beispielcode) zu U-Boot und wird
automatisch von deren Buildsystem mit gebaut. Daher gehe ich
grundsätzlich davon aus, dass sie da wissen, was sie tun.
> Aber der PC sagt ARM Modus wegen dem LSB = 0.
Ja, das ist komisch, in der Tat.
> Was heißt im Kontext des Uboots selbst läuft?
Die Library-Aufrufe sind nur Stubs. Benutzt werden die Lib-Funktionen
des U-Boots selbst; die Verbindung erfolgt über r9, welches offenbar als
eine Art context pointer fungiert.
1
c4600098 <getc>:
2
c4600098: f8d9 c078 ldr.w ip, [r9, #120] ; 0x78
3
c460009c: f8dc f004 ldr.w pc, [ip, #4]
4
5
c46000a0 <tstc>:
6
c46000a0: f8d9 c078 ldr.w ip, [r9, #120] ; 0x78
7
c46000a4: f8dc f008 ldr.w pc, [ip, #8]
8
9
c46000a8 <putc>:
10
c46000a8: f8d9 c078 ldr.w ip, [r9, #120] ; 0x78
11
c46000ac: f8dc f00c ldr.w pc, [ip, #12]
12
13
c46000b0 <puts>:
14
c46000b0: f8d9 c078 ldr.w ip, [r9, #120] ; 0x78
15
c46000b4: f8dc f010 ldr.w pc, [ip, #16]
> Uboot läd Images ins RAM, das muss/sollte mit einem Tool packen und per> Header versehen.
Kann man, muss man für eine standalone app aber nicht unbedingt - sagt
die Doku. Mit Header kann man dann das bootm-Kommando benutzen, welches
sich automatisch um die Caches kümmert.
Der Crash passiert allerdings auch, wenn ich die Caches ausschalte.
Doku:
https://www.denx.de/wiki/view/DULG/UBootStandalone
Das muss Thumb Code sein, weil die mov Operationen als 16 Bit Opcodes
codiert sind. Im ARM Modus wären das alles 32 Bit Opcodes. Also müsste
bei der Startadresse Bit 0 gesetzt sein.
> ## Starting application at 0xC4600000 ...> undefined instruction
Auch das ist dann logisch, wenn Thumb/Thumb2 Code im ARM-Modus
ausgeführt werden soll.
fchk
Soweit sind wir ja schon, dass Thumb im ARM Modus ausgeführt wird ;)
Ich hab nochmal geguckt: auch mkimage kennt nur "-A arm" und nicht
thumb.
Mysteriös!
Bisher hab ich uboot auch nur dazu genutzt Images per TFTP auf ARM Kerne
zu laden und das im ARM Modus, aber da nen thumb mitzugeben muss doch
möglich sein.
Auch wenns einkompiliert ist.
Jörg W. schrieb:> Der Crash passiert allerdings auch, wenn ich die Caches ausschalte.
Es ist ja auch kein Cache Problem, aber trotzdem erstmal deaktiviert
lassen bis alles läuft.
Frank K. schrieb:> Also müsste bei der Startadresse Bit 0 gesetzt sein.
Ah, mir dämmert da was …
Kann es sein, dass ich "go 0xC4600001" schreiben müsste?
Jörg W. schrieb:> Frank K. schrieb:>> Also müsste bei der Startadresse Bit 0 gesetzt sein.>> Ah, mir dämmert da was …>> Kann es sein, dass ich "go 0xC4600001" schreiben müsste?
CONFIG_CPU_V7M ist für die STM32MP1 ziemlich sicher nicht gesetzt da die
eher ARMV7 (ohne M) sind. Ich würde einfach deine standalone nicht für
Thumb übersetzen.
Matthias
Μαtthias W. schrieb:> ch würde einfach deine standalone nicht für Thumb übersetzen.
Wäre auch 'ne Option.
Muss mir jetzt sowieso mal ansehen, wie ich daraus dann custom commands
innerhalb der Yocto-Bitbäckerei zusammen genagelt bekomme.
Jörg W. schrieb:> Muss mir jetzt sowieso mal ansehen, wie ich daraus dann custom commands> innerhalb der Yocto-Bitbäckerei zusammen genagelt bekomme.
Wer Yocto kennt nimmt Buildroot ;-)
Matthias
Thread beobachten
Seitenaufteilung abschalten