Hallo,
ich suche Infos (vor allem ein Datenblatt) für den Application Processor
OMAP5948 von Texas Instruments.
Auf deren Homepage ist absolut nichts über diesen Typ zu finden. In
einem Forum konnte ich erfahren das dieser Chip wohl nicht aus der
OMAP5-Serie stammte, wie man vermuten könnte, sondern dem OMAP1610 sehr
kommen soll.
Aber auch über diesen Chip finde ich nichts, vor allem kein Datenblatt.
Kann mir hier jemand damit aushelfen? Ein Pinout wäre schonmal ein
Anfang :-)
Vielen Dank!
Ja, danke, aber das weiss ich alles schon :-)
Deshalb ja mein "Hilferuf" hier im Forum. Das ist ein Application
Processor aus einem KFZ-Navi/Radiosystem.
Irgendwie muss das Ding ne JTAG oder was ähnliches haben. Ein Datenblatt
hätte da sicher etwas zu zu bieten.
Habe inzwischen die Info das der OMAP5948 kein normaler Chip von TI ist,
sondern eine Sondernanfertigung für Blaupunkt war. Er ist auch nicht aus
der OMAP5-Serie, wie die Bezeichnung einem glauben machen möchte.
Der OMAP5948 besteht aus einem ARM926EJ-S Prozessor und einem TMS320C55x
DSP.
Im SEGGER-Forum gibt es jemand der eine Anpassung für den J-TAG von
Segger dafür bereitgestellt hat:
http://download.ronetix.info/peedi/cfg_examples/arm9/omap5948.cfg
Der Prozessor von TI der dem OMAP5948 am nächsten kommt ist wohl der
OMAP5912. Der hat diese CPU und DSP drin.
Weiss denn jemand welchem frei verfügbaren OMAP dieser am nähesten
kommt? Im Netz findet man Hinweise das der OMAP5948 eine Sonderform des
OMAP-L138 sein soll.
Mittels Segger J-Link bekomme ich zumindest mal mit der CPU-Wahl "ARM9"
einen Connect hin und kann sogar die CPU anhalten ("h") und weiterlaufen
lassen ("g").
Bei dieser Auswahl wird die CPU als "ARM9TDMI" angezeigt, was ja nur der
Urvater aller ARM9's ist. Im OMAP-L138 würde aber eine ARM926EJ-S drin
stecken, die schon wesentlich weiter entwickelt ist. Anscheinend passt
aber dann die CPU-ID nicht dazu. Naja, vielleicht ist der OMAP5948 ja
wirklich "speziell" im Sinne von "abgespeckt" ?!
Bin für jeden Hinweis dankbar, da ich momentan total im dunklen tappe!
:-)
Bei TI wurde im Automotive Bereich gerne die ARM926EJ-S Prozessor und
einem TMS320C64x+ Kombination verwendet. Das waren in der Regel OEM SOC
chips, also nichts wo man ohne NDA rankommt.
Vermutlich wirst Du in der Jacinto Serie von TI einen SOC finden, der zu
90% identisch mit diesem OMAP ist.
Viel Glück.
Danke Dir!
Wie ist das eigentlich, könnte ich das Datenblatt von TI nicht gegen
Zeichnung einer NDA bekommen? Oder wird das an Privatleute grundsätzlich
nicht ausgegeben?
Olli Z. schrieb:> Wie ist das eigentlich, könnte ich das Datenblatt von TI nicht gegen> Zeichnung einer NDA bekommen?
Diese Frage wird Dir niemand besser beantworten können als TI.
Rufus Τ. F. schrieb:> Olli Z. schrieb:>> Wie ist das eigentlich, könnte ich das Datenblatt von TI nicht gegen>> Zeichnung einer NDA bekommen?>> Diese Frage wird Dir niemand besser beantworten können als TI.
Hier der wesentliche Teil der Antwort auf meine Anfrage bei TI:
"Part Number OMAP5948is a customized product and it is not available
from TI official website. Please confer to your source of information
since we do not have any more information on this product."
Olli Z. schrieb:> ich suche Infos (vor allem ein Datenblatt) für den Application Processor> OMAP5948 von Texas Instruments.
Was willst Du denn überhaupt damit machen?
Ich meine, wenn das Ding eh Kundenspezifisch ist, dann wirst Du auch
keine "Hardwaretreiber", Startupcode etc. dafür finden und das wäre mega
viel Arbeit und Reverse-Engineering um damit überhaupt etwas machen zu
können.
Da würde ich vorher die Hardware samt und rund um den Prozessor komplett
ersetzen z.B. durch ein Eval. Board oder so, wo es auch Support dafür
gibt.
Was ich tun möchte ist den an einem OMAP5948 hängenden Flash-Speicher,
ein Spansion S29GL256 auslesen weil ich dort einen Defekt vermute der
das Gerät beim Start abstürzen lässt.
Mit dem hier beigefügten JFLASH Projekt "OMAP5948ZXF.jflash" (im ZIP)
für den Segger J-Link EDU habe ich es zumindest geschafft einzelne
Sektoren auszulesen! Lese ich jedoch mehrere bekomme ich einen
Lesefehler. Dieser resultiert daraus das die CPU nach wenigen Sekunden
"aus geht". Dort werkelt mit Sicherheit ein Watchdog.
Im J-Flash Project werden für die Kommunikation nur die MMU Deaktiviert
(vermutlich wird er damit den Coprozessor, CP15, abschalten weil eine
MMU hat der OMAP nicht) und die CPU angehalten. Wie auch immer er das
macht, das wird wohl reines JTAG sein (Kommandos), denn von irgendeiner
Software ist darin nix zu finden.
Um nun den Watchdog auszuschalten braucht es mit Sicherheit ein Stück
ARM9-Code welcher ins RAM der CPU geladen und ausgeführt wird. Zumindest
gibt es dafür kein auswählbares JTAG-Kommando in den Init-Steps der
Project-Settings.
Nach langerer Recherche bin ich auf das "omap5948.cfg" PEEDI-File
gestoßen, wo scheinbar genau dieses Problem behandelt wird. Zumindest
sieht der Code sehr stimmig aus. Hier ein Auszug:
1
...
2
3
[INIT_OMAP5948]
4
; reset ARM
5
set cpsr 0x000000D3 ; set supervisor mode
6
set pc 0x00000000
7
set control 0x00050078 ; CP15 Control : disable caches
8
9
; disable ARM9 Watchdog Timer
10
mem write 0xFFFEC808 0x00F5 ; convert WD timer into GP timer
11
mem write 0xFFFEC808 0x00A0 ;
12
13
mem write 0xFFFEB048 0xAAAA ; stop the wahtchdog timer
14
mem write 0xFFFEB048 0x5555
15
16
...
Der OMAP5912 ist dem OMAP5948 wohl sehr änhlich (hab ich gelesen) und
von dem gibt es ein Datenblatt und jede Menge Infos. Aus dem "Reference
Guide (SPRU748A)" habe ich auf Seite 612 folgendes entnommen:
Der Watchdog ist laut dem Guide nach dem Reset aktiv und besteht aus
einem 32-Bit Timer mit der Teilung CK_REF/14.
1
OMAP5912 Power Management Software User Guide
2
3
Disable the MPU watchdog timer by writing the sequence F5, A0 in the
4
TIMER_MODE register:
5
Command WR32 0xFFFE C808 0x0000 00F5
6
Command WR32 0xFFFE C808 0x0000 00A0
Die beiden unteren Kommandos aus dem PEEDI-Scripts sind dann wohl
OMAP5948 spezifisch, jedenfalls finde ich nichts über diese Adressen im
OMAP5912.
Nach "viel" sieht es ja nicht aus was da fehlt. Kann mir jemand helfen
das in eine Segger-J-Link konforme "Sprache" umzusetzen?
So, meine OpenOCD-Umgebung habe ich soweit eingerichtet und mich durch
das Handbuch gewühlt. Das Interface (JTAG-Probe von Olimex) konnte ich
mit der existierenden Vorlage
"scripts/interface/ftdi/olimex-arm-usb-ocd-h.cfg" problemlos einbinden.
USB-Treiber ist drauf und kommuniziert.
Als Vorlage für meinen OMAP5948 habe ich im "target" Ordner eine
"omap5912.cfg" gefunden. An dieser werde ich mich orientieren.
Ausgehend vom J-Link Adapter hat die JTAG-Chain folgenden Aufbau:
1
TotalIRLen = 50, IRPrint = 0x001444031F3D81
2
JTAG chain detection found 3 devices:
3
#0 Id: 0x031F3D81, IRLen: 34, Unknown device
4
#1 Id: 0x0692602F, IRLen: 04, ARM9TDMI Core
5
#2 Id: 0x00000001, IRLen: 12, Unknown device
Ich denke Device #0 ist der DSP und Device #1 der ICE, obgleich die ID
vom ICE schon recht merkwürdig aussieht und ein 4-bit breites
JTAG-Kommandoregister für eine CPU auch nicht gerade viel ist.
Also sähe die Kette wohl so aus: [DSP:34] [CPU:4] [ICE:12]
In der omap5912.cfg von OpenOCD ist die Chain so definiert:
jtag newtap $_CHIPNAME dsp -irlen 38 -expected-id 0x03df1d81
jtag newtap $_CHIPNAME arm -irlen 4 -expected-id 0x0692602f
jtag newtap $_CHIPNAME unknown -irlen 8
Die ID und IRLen für die CPU ist identisch, jedoch die vom DSP und ICE
nicht, ebenso deren IDs. Gut, das ist auch ein anderer Prozessor, kann
also durchaus sein. Jedenfalls stimmt die Reihenfolge :-)
Im "omap5948.cfg" des PEEDI JTAG-Adapters ist die Chain so definiert:
JTAG_CHAIN = 8, 4, 38 ; list of IR lenghts of all
TAP controller in JTAG chain
Der PEEDI scheint sich für IDs nicht sonderlich zu interessieren,
jedenfalls ist dort nicht definiert was was ist. Auch scheint die
Reihenfolge hier andersrum zu sein, trifft aber eher wieder die vom
omap5912 aus dem OpenOCD package.
Ich muss jetzt wohl mal ein wenig rumprobieren...?! Was könnte ich denn
tun um zu erkennen ob meine Einstellung für die Chain stimmt?
Vom Alter und vom verwendeten ARM Core her fällt der OMAP5948 in die
Generation OMAP-1 SOCs. Hier gibt es z,B, den OMAP5912 welcher dem sehr
änhlich scheint.
Zur Zeit versuche ich den Bootprozess zu verstehen und mittels JTAG zu
untersuchen.
Nach dem Power-On-Reset führt der wohl erstmal den internen Boot ROM
Code aus. Dieser soll im wesentlichen den Bootmodus und die Bootquelle
bestimmen und den 2nd stage bootloader ins SRAM laden und zur Ausführung
bringen. Aus anderen Artikeln weiss ich das dieser X-Loader z.b. ein
U-Boot Bootmanager sein könnte, wie er bei Embedded Linux zum Einsatz
kommt, oder aber auch direkt ein spezieller Loader um den Kernel eines
RTOS oder sowas zu laden.
Ich glaube es ist so das dieser 2nd stage Teil nur 2kb sein darf und auf
dem gewählten Bootmedium als erster Sektor verfügbar sein muss. In
meinem Fall steht der schicher im externen Flash (EMIFS Interface) in
Sektor 0.
Das Bootmedium bestimmt wohl auch die Startadresse des programms, aber
ab hier komme ich nicht mehr so ganz klar...
Der Inhalt des Boot ROM ist geheim und ab Werk unverändlich aufgebracht.
Es soll über SYSBOOT Pins bestimmt werden welches Bootmedium genutzt
wird. Diese Pins finde ich irgendwie nicht. Es werden nur bestimmte
Medien und Typen unterstützt, wie z.B? bestimmte NAND und NOR Flashes,
aber auch USB OTG und UART. Das bestimmen die 16 SYSBOOT Bits/Pins
irgendwie. Der Zustand dieser Pins soll auch in einem internen Register
gehalteb werden, das würde ich natürlich per JTAG gern mal auslesen,
weiss nur nicht recht wie.
Dann würde mich interessieren was das Boot ROM ins SRAM kopiert und and
welche Adresse. Auch das sollte sich doch irgendwie per JTAG auslesen
lassen?
Meine Idee ist diesen Bootprozess zu verstehen, den 2nd BTL zu
identifizieren und zu disassemblieren um diesen dann ggf. mit GDB
schrittweise ausführen zu lassen oder sogar mittels QEMU zu emulieren.
Leider stehe ich noch ganz am Anfang, finde das aber total spannend und
würde gern weiter kommen.
Ich würde mich sehr über etwas Hilfe und Unterstützung freuen :-)
Danke!
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten