Forum: Mikrocontroller und Digitale Elektronik Suche Infos zum OMAP5948


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 Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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!

von (º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht eine Spezialausgabe fuer ein Dummfon.
(Ex-)Nokia hat die gern und oft verbaut.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
"This is an obsolete device, and it is no longer supported"

https://e2e.ti.com/support/omap/f/885/t/312707

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Klaus R. (klara)


Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Das ist ein Application
> Processor aus einem KFZ-Navi/Radiosystem.

Hatte wohl Blaupunkt mal eingesetzt.
mfg Klaus

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
Ja, ihr habt alle recht. Weiter bringt mich das aber leider nicht. Hat 
denn wirklich niemand ein solches Datenblatt?

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich mich recht erinnere, gibts die Infos zu den "vertical market" 
omap5 nur gegen NDA...Chancen also gering, hier was zu finden.

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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
von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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! 
:-)

von Nils P. (torus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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."

von Johnny B. (johnnyb)


Bewertung
0 lesenswert
nicht lesenswert
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
von Olli Z. (z80freak)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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!

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.