Ich habe hier ein Problem mit einem Radio auf dem ein OMAP-Prozessor
(OMAP5912 derivat) verbaut ist. Der hat eine ARM9 CPU drauf, externen
SDRAM und Flash. Ich kann per JTAG auf die CPU zugreifen und auch das
Flash lesen/programmieren. Trotzdem bootet das Ding nicht weil irgendwas
nicht stimmt. Ich habe bereits die Firmware neu geflasht (von einem
laufenden Gerät), aber das hat nichts geändert. Es gibt wohl eine
externe Abhängigkeit/defekt die ich noch nicht gefunden habe.
Beim Connect mit J-Link sehe ich das die CPU nach einem Reset immer hier
hängen bleibt:
1
J-Link: ARM9 CP15 Settings changed: 5327F from 78, MMU On, ICache On, DCache On
0xFFFF000C ist der Reset-Vector vom ABORT Interrupt (soweit ich das
weis). Und der "ABORT mode" zeigt es ja auch an.
War es nicht so das in einem solchen Fall R13 auf den Stacktrace zeigt
und R14 auf die Adresse in der der Abbruch stattfand?
1
ABT: R13=BBE9D6AB, R14=00000002, SPSR=000000F7
Von der Adresse her wäre aber doch in R14 ein illegaler Wert mit
0x0000_0002?
Die von R13 angezeigte Stack-Trace Adresse liegt im Bereich des externen
SDRAMs (EMIFF), welcher von 0x8000_0000 bis 0xEFFF_FFFF geht. Wenn ich
versuche über JTAG den Bereich zu lesen erhalte ich einen Fehler:
1
J-Link>mem 0xbbe9d6ab, 64
2
Could not read memory.
Aus dem internen SRAM kann ich aber lesen. Möglicherweise ist aber zum
Zeitpunkt des ABORTs das externe SDRAM noch garnicht verfügbar, wodurch
der Adressbereich noch nicht belegt ist?
Hat hier jemand genug Erfahrung mir da ein wenig unter die ARMe zu
greifen? ;-) Ich würde gern herausfinden warum und wo der ABORT
stattfindet. Evtl. gibt mir das Aufschluß darüber was mit der Hardware
nicht stimmt?
Ein Abort kann ja auch durch Timeouts beim Zugriff auf externe
Peripherie ausgelöst werden. Hier liegt meine Vermutung. Aber ohne einen
Anhaltspunkt wo ist das stochern im Nebel. Natürlich habe ich schon die
bekannten bzw. möglichen Fehlerquellen geprüft wie das RAM, das Flash,
die Stromversorgungen, Power-Control und Boot-Control, aber alles ohne
erkennbares Problem.
Normalerweise läuft das Programm ja im SVC mode (Supervisor). Irgendwann
kommt dann das Problem und er wechselt in den ABORT mode. Ist dann nicht
vom obigen regs der letzte ausgeführte Befehl hier zu suchen?
1
SVC: R13=2000FE18, R14=00001FA0, SPSR=00000010
Also an R14?
Hier mal der Disassembly aus diesem Bereich:
1
ROM:00001F7C PUSH {R4,LR}
2
ROM:00001F80 MOV R4, R0
3
ROM:00001F84 MOV R0, R1
4
ROM:00001F88 MOV R1, R2
5
ROM:00001F8C MOV R2, R3
6
ROM:00001F90 LDR R3, [SP,#8+arg_0]
7
ROM:00001F94 ADD R4, R4, #0x14
8
ROM:00001F98 MOV LR, PC
9
ROM:00001F9C BX R4
10
ROM:00001FA0 POP {R4,PC}
Das habe ich mal mit einem Breakpoint ein paar Befehle davor geprüft:
An 0x1F9C springt er ja mit einem call an die Adresse von R4, wo zu
diesem Zeitpunkt 0x9000_0014 drin steht. Eine Zielmarke im SDRAM. Dort
springt er wohl weiter nach 0x9000_0034. Die Adresse muss er ja aus dem
Speicherort 0x9000_0014 - 0x18 = 0x8FFF_FFFC gelesen haben. Von der
Zielmarke her (aligned) eher ein ARM als ein Thumb-Befehl?. Aber das
scheint er dann nicht mehr hin zu bekommen (Fehlermeldung). Danach ist
der PC auf 0xE51FF018 gestellt, warum auch immer?!
Den Speicher ab 0x9000_0000 kann ich übrigens problemlos auslesen:
Einzig das bei mehreren gleichen Lesezyklen ab und zu mal ein anderer
Inhalt erscheint, wenn auch immer derselbe:
1
J-Link>mem 0x90000000, 64
2
90000000 = 60 54 05 FA 01 1F 0F E2 60 54 05 FA 01 1F 0F E2 `T......`T......
3
90000010 = 60 54 05 FA 01 1F 0F E2 60 54 05 FA 01 1F 0F E2 `T......`T......
4
90000020 = 60 54 05 FA 01 1F 0F E2 60 54 05 FA 01 1F 0F E2 `T......`T......
5
90000030 = 60 54 05 FA 01 1F 0F E2 60 54 05 FA 01 1F 0F E2 `T......`T......
6
90000040 = 60 54 05 FA 01 1F 0F E2 60 54 05 FA 01 1F 0F E2 `T......`T......
7
90000050 = 60 54 05 FA 01 1F 0F E2 60 54 05 FA 01 1F 0F E2 `T......`T......
8
90000060 = 60 54 05 FA `T..
Da das im SDRAM ist, dürfte das doch bei einer angehaltenen CPU nicht
sein, oder? Das müsste doch immer gleich sein...
Vom Rest des Codes her ist das in einem Bereich wo Images aus dem Flash
ins RAM geladen werden. Was darin genau abgeht weiss ich noch nicht aber
es wird ein Image nach dem anderen übertragen und dann ausgeführt
(initialisiert). Und in einem davon scheint es dann zu knallen.
Ich schaue mal ob ich durch einen Breakpoint in der Verzeigungsroutine
(case) herausbekomme bei welchem das der Fall ist.
Hier auch mal zur Vollständigkeit das Decompile dieses Bereichs:
Ich glaube ich liege total falsch, diese Kaskade da oben scheint eher
ein Teil des Bootloaders zu sein. Hier wird im Kern ein String-Vergleich
durchgeführt. Und zwar gibt es im SRAM eine Adresse (z.B. 0x2C5EB7A5)
welche durch die ganze Kette durchgeschleust und nach einem String-Match
gesucht wird. An besagtem SRAM steht da:
Nun wird nacheinander verglichen ob der String an der Position im SRAM
mit einem der fixen Strings in der Switch/Case übereinstimmt.
Interessant ist, das es in diesem SRAM-Bereich zwar ein "SDRAM_INIT"
gibt, dieses in der großen Switch/Case aber nicht vorkommt. Hmm...
Hallo!
Ich würde mal versuchen die Register ESR_EL3 (Exception Syndrome
Register) und FAR_EL3 (Fault Address Register) auszulesen, wenn mit
J-Link möglich. Solltest du das noch nicht gemacht haben. Bei FAR_ELx
"sollte" die tatsächliche Adresse hinterlegt sein, wo der Fehler
aufgetreten ist. ESR_ELx "sollte" angeben, was der Fehler genau war.
Exception Syndrome Register:
https://developer.arm.com/documentation/ddi0595/2020-12/AArch64-Registers/ESR-EL3--Exception-Syndrome-Register--EL3-
Johannes K. schrieb:>> Ich würde mal versuchen die Register ESR_EL3 (Exception Syndrome> Register) und FAR_EL3 (Fault Address Register) auszulesen, wenn mit> J-Link möglich.
Ab welcher ARM Generation gibt es die denn? Ich befürchte dass der ARM9
(also Generation ARMv4 oder ARMv5 von ca. 2002) des TO diese noch nicht
hat.
Dieter S. schrieb:> Johannes K. schrieb:>>>> Ich würde mal versuchen die Register ESR_EL3 (Exception Syndrome>> Register) und FAR_EL3 (Fault Address Register) auszulesen, wenn mit>> J-Link möglich.>> Ab welcher ARM Generation gibt es die denn? Ich befürchte dass der ARM9> (also Generation ARMv4 oder ARMv5 von ca. 2002) des TO diese noch nicht> hat.
Ab ARMv8... Dachte an ARMv9. ARMv9 != ARM9
Sorry, mein Fehler.
Thread beobachten
Seitenaufteilung abschalten