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!
Vielleicht eine Spezialausgabe fuer ein Dummfon. (Ex-)Nokia hat die gern und oft verbaut.
"This is an obsolete device, and it is no longer supported" https://e2e.ti.com/support/omap/f/885/t/312707
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.
Olli Z. schrieb: > Das ist ein Application > Processor aus einem KFZ-Navi/Radiosystem. Hatte wohl Blaupunkt mal eingesetzt. mfg Klaus
Ja, ihr habt alle recht. Weiter bringt mich das aber leider nicht. Hat denn wirklich niemand ein solches Datenblatt?
Wenn ich mich recht erinnere, gibts die Infos zu den "vertical market" omap5 nur gegen NDA...Chancen also gering, hier was zu finden.
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.
:
Bearbeitet durch User
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").
1 | Connecting to target via JTAG |
2 | TotalIRLen = 50, IRPrint = 0x001444031F3D81 |
3 | JTAG chain detection found 3 devices: |
4 | #0 Id: 0x031F3D81, IRLen: 34, Unknown device
|
5 | #1 Id: 0x0692602F, IRLen: 04, ARM9TDMI Core
|
6 | #2 Id: 0x00000001, IRLen: 12, Unknown device
|
7 | CP15.0.0: 0x41069263: ARM, Architecure 5TEJ |
8 | CP15.0.1: 0x1D112152: ICache: 16kB (4*128*32), DCache: 8kB (4*64*32) |
9 | Cache type: Separate, Write-back, Format C (WT supported) |
10 | ARM9 identified. |
11 | ETM V1.3: 4 pairs addr.comp, 2 data comp, 8 MM decs, 2 counters, sequencer |
12 | J-Link>h |
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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!
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.