Vermutliches TMS320C6xx-Binary disassemblieren

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Seit Jahren versucht ein kleiner Kreis Interessierter den im OMAP4/OMAP5 
von TI (https://www.ti.com/lit/po/swpt034b/swpt034b.pdf) eingebetteten 
Audio-Signalprozessor zu verstehen. Sehr wahrscheinlich handelt es sich 
um einen TMS320C64x oder C66x oder ein Derivat aber das ist nicht ganz 
klar und nirgends verlässlich dokumentiert.

Bekannt ist der Firmwarecode, der von Linux beim booten in den 
Sound-Prozessor (AE = Audio Engine) geladen wird. Dieser ist als C-File 
mit eingebettetem Hex-Code verfügbar (ABE = Audio Backend): 
https://github.com/omap-audio/abefw/blob/master/fw/009590/abe_firmware.c

Wenn man das übersetzt und lädt, kann man aus dem AESS-Subsystem und dem 
debugfs die angehängte Binärdatei (pmem = program memory) zurücklesen. 
Diese enthält sicherlich die Signalverarbeitungsroutinen, 
Filterparameter und Code, der die Verbindung zu den Interfaces steuert.

Eigene Versuche mit capstone (tms320x64x) haben bisher zu keinen 
verständlichen Ergebnissen geführt.

Sieht hier ein DSP/TMS320-Spezialist eine Chance diese angehängte Datei 
so zu disassemblieren, dass man das das C-File durch einen echten 
Source-Code (natürlich für einen geeigneten Assembler) ersetzen und ggf. 
modifizieren kann? Kann man aus dem Code herausfinden, welcher 
Signalprozessorbefehlssatz das wirklich ist? Wer kennt/hat geeignete 
Tools und Erfahrungen mit TMS320-Architektur und Befehlssatz und würde 
sich daran versuchen wollen?

[Ob S. (Firma: 1984now) (observer)]

Nikolaus S. schrieb:

> Kann man aus dem Code herausfinden, welcher
> Signalprozessorbefehlssatz das wirklich ist?

Eher nur im Ausschlußverfahren, also man könnte zumindest verifizieren, 
ob das wirklich TMS320-Code ist.

> Wer kennt/hat geeignete
> Tools und Erfahrungen mit TMS320-Architektur und Befehlssatz und würde
> sich daran versuchen wollen?

Das wirst du nicht bezahlen wollen...

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Ob S. schrieb:
> Nikolaus S. schrieb:
>
>> Kann man aus dem Code herausfinden, welcher
>> Signalprozessorbefehlssatz das wirklich ist?
>
> Eher nur im Ausschlußverfahren, also man könnte zumindest verifizieren,
> ob das wirklich TMS320-Code ist.

Also TMS320 ist 99,99% sicher, denn es ist ja TI. Nur welche Variante...

Falls es hilft: TI hatte eine Library die "Hardware Abstraction" macht: 
https://www.ti.com/pdfs/wtbu/OMAP4430_4460_4470_PUBLIC_TRM_Addendum_ABE_HAL_vF.pdf 
aber das ist Code der außerhalb der DSP-Firmware läuft und höchstens mit 
ihr irgendwie kommuniziert. Das macht der Linux-Kernel-Treiber aber auch 
und der ist Open-Source.

Auch OMAPpedia weiss nichts Genaues: 
https://omappedia.com/wiki/Audio_Drive_Arch

ChatGPT meint zu glauben es wäre ein "TI C55x DSP Core". Auf Nachfrage 
nach einer Quelle schwenkt es um und behauptet es wäre doch ein C64. 
Immerhin gab es dann einen Hinweis auf: 
https://en.wikipedia.org/wiki/TMS320#C6000_series

Dort steht (auch ohne Quelle): "OMAP4 and OMAP5 chips include an ARM 
Cortex-A9 or A15 (ARMv7) with a custom C64x+ derivative known as Tesla 
(or C64T)"

Demnach könnte man hier fündig werden: 
https://www.ti.com/lit/ug/spru732j/spru732j.pdf

D.h. wenn jemand einen C64+-Disassembler in Betrieb hat und die 
Architektur kennt, könnte man das einfach mal auf die Datei anwenden um 
zu sehen ob was sinnvolles erkennbar wird...

>> Wer kennt/hat geeignete
>> Tools und Erfahrungen mit TMS320-Architektur und Befehlssatz und würde
>> sich daran versuchen wollen?
>
> Das wirst du nicht bezahlen wollen...

Schon klar dass das niemand bezahlen wird, es baut ja auch keiner mehr 
neue Produkte auf Basis OMAP4/5. Es interessiert die 
Open-Source-Community und ich mache da auch nur als Hobby mit und weil 
es mich als ungelöstes Rätsel beschäftigt...

[Cartman E. (cartmaneric)]

Hast du es denn schon einmal mit dem Code Composer von TI versucht?
Der hat für die C6000 einen Debugger/Simulator.
Der kann natürlich auch dissassemblieren.

ChatGPT ist wie immer ahnungslos. Die C55 sind Fixkomma-DSP.
Manche 6000er wie die 6200er aber auch.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Cartman E. schrieb:
> Hast du es denn schon einmal mit dem Code Composer von TI versucht?
> Der hat für die C6000 einen Debugger/Simulator.
> Der kann natürlich auch dissassemblieren.

Hatte es vor Jahren mal erfolglos probiert.

Und es gerade versucht neu zu installieren (Version 20.1.1 für macOS). 
Da ist aber anscheinend kein TMS320-Support in der Liste "Select 
Components" dabei. Kann/muss man das dann nachinstallieren?

EDIT: habe es wohl gefunden:
https://www.ti.com/tool/de-de/C6000-CGT

[Dieter S. (ds1)]

Nur disassemblieren (ohne das Ergebnis zu verstehen) ist das kleinste 
Problem wenn man den DSP kennen würde.

TRACE32 kann die ganzen TMS320Cxxx disassemblieren (IDA Pro natürlich 
auch einen grossen Teil davon). TRACE32 kennt auch den DSP der meisten 
OMAPs (z.B. für den OMAP4430 ist das bei TRACE32 "OMAP4430TESLA"), 
allerdings ergibt die "pmem" Datei keinen sinnvollen Code damit.

Die Frage ist ob der ABE DSP des OMAP identisch zum Haupt-DSP ist oder 
ob der eventuell etwas anderes ist.

BTW, die Firmware C-Dateien von hier

https://github.com/mvduin/abefw-omap4plus

enhalten Kommentare um die unterschiedlichen Speicherbereiche zu 
kennzeichnen, da kann man sich den PMEM Bereich direkt rausholen.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Dieter S. schrieb:
> Nur disassemblieren (ohne das Ergebnis zu verstehen) ist das kleinste
> Problem wenn man den DSP kennen würde.

Eben, da ist das zunächst schwierigere Problem herauszufinden welcher 
Befehlssatz das überhaupt ist (wenn das nicht gar noch etwas 
proprietäres oder zumindest modifiziertes ist).

>
> TRACE32 kann die ganzen TMS320Cxxx disassemblieren (IDA Pro natürlich
> auch einen grossen Teil davon). TRACE32 kennt auch den DSP der meisten
> OMAPs (z.B. für den OMAP4430 ist das bei TRACE32 "OMAP4430TESLA"),

Ok, dann scheint der Hinweis auf C64-Tesla aus Wikipedia ja schon mal 
etwas mehr bestätigt.

> allerdings ergibt die "pmem" Datei keinen sinnvollen Code damit.

Danke für den Versuch! Es könnte sein, dass die Byte-Order nicht stimmt.

> Die Frage ist ob der ABE DSP des OMAP identisch zum Haupt-DSP ist oder
> ob der eventuell etwas anderes ist.

Ja, das stimmt. Im OMAP4 gibt es auch noch weitere DSPs und der AE ist 
wahrscheinlich eine im Funktionsumfang reduziert Version.

>
> BTW, die Firmware C-Dateien von hier
>
> https://github.com/mvduin/abefw-omap4plus
>
> enhalten Kommentare um die unterschiedlichen Speicherbereiche zu
> kennzeichnen, da kann man sich den PMEM Bereich direkt rausholen.

Das ist mehr oder weniger dasselbe wie 
https://github.com/omap-audio/abefw/blob/master/fw/009590/abe_firmware.c.

Um die Firmware zu bauen, wird dieses File per #include in ein C-Array 
gepackt, dann kommen Header dazu, damit der Linux-Firmware-Loader weiss 
was das ist. Der lädt das und schreibt es ins pmem. Die Bytes scheinen 
auch identisch zu sein, wenn man einen hexdump von der pmem-Datei macht 
- bis auf evtl. byte-order-Effekte.

Ich habe inzwischen auch mal den dis6x aus 
https://www.ti.com/tool/de-de/C6000-CGT probiert darauf anzusetzen. 
Leider crasht er mit einem Segfault, wenn ich direkt die pmem-Datei 
angebe. Wahrscheinlich will er ein ELF-File und kein reines Binary.

Aber -o=0x... disassembliert wenigstens einzelne Worte, so dass ich das 
in eine Schleife packen konnte.

Ungeswappt gibts ein paar halbwegs sinnvoll erscheinende Sequenzen:

520c 0x0041008A .word 0x0041008a
5210 0x003300D3 ADDK.S2 26113,B0
5214 0x003600D8 SUB.L1 -16,A13,A0
5218 0x003900D9 SUB.L1 8,A14,A0
521c 0x010500DA SUB.L2 8,B1,B2
5220 0x0105007D STW.D2T1 A2,*+B14[1280]
5224 0x0060007E STW.D2T2 B0,*+B14[24576]
5228 0x0060007E STW.D2T2 B0,*+B14[24576]
522c 0x010B007D STW.D2T1 A2,*+B14[2816]
5230 0x010B0082 .word 0x010b0082
5234 0x01080081 MPYH.M1 A0,A2,A2
5238 0x01080082 MPYH.M2 B0,B2,B2
523c 0x00030081 .word 0x00030081
5240 0x00030134 .word 0x00030134
5244 0x00030079 .word 0x00030079
5248 0x0024007A ADD.L2 B0,B9,B0
524c 0x00240134 .word 0x00240134
5250 0x00240079 ADD.L1 A0,A9,A0
5254 0x0107007A .word 0x0107007a
5258 0x01090085 LDHU.D2T1 *-B2[8],A2
525c 0x01070085 LDHU.D2T1 *-B1[24],A2
5260 0x0107013C STB.D2T1 A2,*+B14[1793]
5264 0x01090086 LDHU.D2T2 *-B2[8],B2
5268 0x0109013C STB.D2T1 A2,*+B14[2305]

Aber die .word deuten darauf hin dass da nur Rauschen übersetzt wurde. 
Ich konnte auch nichts finden was auf Schleifen hindeutet (wie ist das 
Mnemonic beim C64x für einen Branch?)

Geswappt aber auch nicht besser (da gibt es auch oft viele Codes die der 
dis6x einfach leer ausgibt):

520c 8a004100 EXTU.S1 A0,0,0,A0
5210 d3003300 NOP
5214 d8003600 NOP
5218 d9003900 NOP
521c da000501 NOP
5220 7d000501 LDHU.D1T2 *-A0[0],B0
5224 7e006000 LDHU.D1T2 *-A0[0],B0
5228 7e006000 LDHU.D1T2 *-A0[0],B0
522c 7d000b01 LDHU.D1T2 *-A0[0],B0
5230 82000b01 ADDK.S1 640,A0
5234 81000801 .word 0x04d3f961
5238 82000801 .word 0x04e33ba1
523c 81000300 LDW.D2T1 *+B14[21495],A9
5240 34010300 STB.D2T1 A4,*+B15[1780]
5244 79000300 LDW.D2T1 *+B15[13682],A9
5248 7a002400 LDHU.D1T2 *-A0[0],B0
524c 34012400 .word 0x0206fcf0
5250 79002400 .word 0x04b57b20
5254 7a000701 LDHU.D1T2 *-A0[0],B0
5258 85000901 LDH.D2T1 *+B4[8],A10
525c 85000701 STW.D2T1 A10,*+B15[4353]
5260 3c010701 NOP
5264 86000901 .word 0x05204505
5268 3c010901 NOP

Vielleicht ist dieser Ausschnitt aber auch nur eine Datentabelle?

Ich kenne die TMS320-Architektur leider viel zu wenig.

Was mir aufgefallen ist, ist dass es anscheinend verschiedene 
Befehlssätze für unterschiedliche Zwecke gibt. So ähnlich wie ARM Thumb. 
Vielleicht ist das auch noch vermengt?

Eine weitere Frage fällt mir ein: unter welcher Adresse beginnt der 
Programmablauf beim C64x normalerweise?

[Uwe (uhi)]

Zum Verständnis: Das oben angehängte pmem soll den gleichen Inhalt haben 
wie der C-Code in 
https://github.com/omap-audio/abefw/blob/master/fw/009590/abe_firmware.c 
? Ich frag, weil das zwar am Anfang stimmt (bis auf 4 Byte 
Verschiebung), aber weiter hinten nicht mehr zusammenpasst. Oder ist das 
gewollt / verstanden, dass das zwar ähnliche, aber nicht gleiche Daten 
sind? Wenn es gewollt unterschiedliche sind, dann könnte man die 
Unterschiede untersuchen, ob die etwas interessantes ergeben.

Edit: Der Disassembler macht seltsame Sachen. Ich versteh nicht, wie er 
auf dieses kommt:
5234 81000801 .word 0x04d3f961
5238 82000801 .word 0x04e33ba1
Die "81000801" sind die Rohdaten, richtig? Dann ist zum "82000801" nur 
ein Bit verschoben. Die Werte hinten sind aber deutlich 
unterschiedlicher.

Edit 2: Die pmem ist nur ca. 11kByte groß. Es ist nicht klar, woher der 
Disassembler die Adresse 0x5234 etc nimmt. Weil das wären ja über 
20kByte.

[Dieter S. (ds1)]

Mit der "pmem" Datei von weiter oben stimmt wohl etwas nicht. Wenn man 
die Bytes entsprechend anordnet bekommt man das (20 Bytes aus "pmem" je 
Zeile):

00000000: 90 95 00 00 00 20 00 00 AC 1E 00 00 00 40 00 00
00000010: 60 54 00 00 0F 20 00 16 10 09 00 0A 00 00 20 08
00000020: 00 00 20 08 00 00 80 07 CE 75 00 16 E0 0D 20 0A
00000030: E4 00 40 01 E5 00 40 01 E6 00 40 01 E7 00 40 01
00000040: E8 00 40 01 E9 00 40 01 EA 00 40 01 EB 00 40 01
00000050: EC 00 40 01 ED 00 40 01 EF 00 40 01 EF 00 40 01
00000060: E4 00 40 14 00 00 00 9E E0 0D 20 0A 40 00 00 9E
...
...

Das sind also 4 Bytes Offset und dann 16 Bytes Daten, die Daten 
entsprechen dem Inhalt aus "abe_firmware.c", die Reihenfolge der Bytes 
in den 32-Bit Werten ist allerdings vertauscht.

Seltsam ist dass der Header (Versionsnummer und die Längen) auch 
enthalten sind.

Ausserdem taucht an ein paar Stellen noch ein zusätzliches "0x0C" auf, 
dessen Bedeutung unklar ist:

...
...
00001080: 30 43 A0 0A 0B 00 00 06 A0 42 80 0A 0D 00 00 06  - 0C
00001090: 30 43 A0 0A 80 44 04 9D 80 47 04 9D 80 04 10 9C  - 0C
000010A0: 00 07 10 9C 90 44 04 9D 90 47 04 9D 80 46 04 9D
000010B0: 80 84 10 9D 00 87 10 9D B0 43 00 0A D0 00 80 05
000010C0: 30 43 A0 0A 90 44 04 9D 00 07 10 9C 90 47 04 9D  - 0C
000010D0: 80 84 10 9D 00 87 10 9D 80 44 04 9D 80 47 04 9D
...
...

[Dieter S. (ds1)]

Ich gehe inzwischen davon aus dass der DSP des ABE (im Prinzip wohl der 
mit "AE" bezeichnete "Audio Engine") ein eher kleiner DSP ist und ein 
anderer Typ als der Haupt-DSP des OMAP ist.

Die ABE Header Dateien geben ja ein paar Einblicke, insbesondere die 
Adressen in "abe_cm_addr.h", "abe_dm_addr.h" und "abe_sm_addr.h".

Die Firmware besteht wohl aus verschiedenen Tasks, siehe "abe_taskid.h".

Interessant wäre der DMEM Bereich wenn die Firmware läuft, speziell der 
Stack (der liegt im DMEM) würde eventuell ein paar mehr Rückschlüsse zum 
verwendeten DSP ermöglichen.

Und ein Blick in die "ABE Subsystem and ABE HAL addendums" wäre schön, 
die es laut einem Beitrag im TI Forum gegen NDA gibt. Die öffentliche 
Version davon enthält ja nur einen Teil des Ganzen.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Uwe schrieb:
> Zum Verständnis: Das oben angehängte pmem soll den gleichen Inhalt haben
> wie der C-Code in
> https://github.com/omap-audio/abefw/blob/master/fw/009590/abe_firmware.c
> ? Ich frag, weil das zwar am Anfang stimmt (bis auf 4 Byte
> Verschiebung),

Ja. Sollte das Gleiche sein. Entstanden ist die Datei durch Übersetzen 
der abe_firmware, Installation in /lib/firmware, starten des AESS auf 
einem Pandaboard ES und auslesen der pmem-Datei aus 
/sys/kernel/debug/omap-aess/pmem. Dabei werden die ersten 5 Worte Header 
aus abe_firmware.c entfernt und sind nicht im /sys pmem enthalten.

> aber weiter hinten nicht mehr zusammenpasst.

Danke für die Argus-Augen :)

> Oder ist das
> gewollt / verstanden, dass das zwar ähnliche, aber nicht gleiche Daten
> sind? Wenn es gewollt unterschiedliche sind, dann könnte man die
> Unterschiede untersuchen, ob die etwas interessantes ergeben.

Unterschiede sollten eigentlich nur entstehen wenn irgendwelcher 
unbekannter Code das absichtlich oder unabsichtlich verändert...

Ich hab das jetzt nochmal ausgelesen (die ursprüngliche pmem-Datei ist 
schon etwas älter gewesen und da könnte tatsächlich noch ein Fehler im 
Kerneltreiber gewesen sein). Angehängt sind die 8192 bytes, die auch zur 
abe_firmware.c passen.

>
> Edit: Der Disassembler macht seltsame Sachen. Ich versteh nicht, wie er
> auf dieses kommt:
> 5234 81000801 .word 0x04d3f961
> 5238 82000801 .word 0x04e33ba1
> Die "81000801" sind die Rohdaten, richtig? Dann ist zum "82000801" nur
> ein Bit verschoben. Die Werte hinten sind aber deutlich
> unterschiedlicher.

Ok, danke! Das ist mir noch gar nicht aufgefallen. Da war in dem Script, 
das den dis6x aufruft beim o= ein 0x zu wenig. Also hat der dis6x das 
81000801 dezimal interpretiert und disassembliert. Die Ausgabe 5234 
81000801 kommt aus dem Script.

>
> Edit 2: Die pmem ist nur ca. 11kByte groß. Es ist nicht klar, woher der
> Disassembler die Adresse 0x5234 etc nimmt. Weil das wären ja über
> 20kByte.

Ja, auch richtig! Danke für den Hinweis.

Hintergrund ist dass das Script nicht direkt auf der pmem-Datei arbeitet 
sondern auf abe_firmware.c und die Hexwerte in 4 Byte-Stücke zerlegt und 
dann dem dis6x übergibt.

Ah, ich denke ich hab die Lösung erkannt: abe_firmware.c enthält Daten 
für pmem UND cmem. Daher gibt es Offset 0x5234 aber das ist kein 
Programm-Code.

Hier neu (ohne Byte-Swap) und ein Beispiel aus dem echten 
pmem-Adressbereich:

0328 0x01000004 LDHU.D1T1 *-A0[0],A2
032c 0x9d140550 .word 0x9d140550
0330 0x0a800950 .word 0x0a800950
0334 0x0a000bf0 .word 0x0a000bf0
0338 0x048006ff STW.D2T2 B9,*+B15[6]
033c 0x013ffafb .word 0x013ffafb
0340 0x013ffcfc STW.D2T1 A2,*+B15[16380]
0344 0x413ffefe [ B1] STW.D2T2 B2,*+B15[16382]
0348 0x04a0020b EXTU.S2 B8,0,2,B9
034c 0x004002bc STB.D2T1 A0,*+B15[16386]
0350 0x0600000c LDHU.D2T1 *+B14[0],A12
0354 0x4a800d90 [ B1] B.S1 0xffffffffffd4006c
0358 0x1601538d .word 0x1601538d
035c 0x0a200720 .word 0x0a200720
0360 0x0a000d30 .word 0x0a000d30
0364 0x003ffefe STW.D2T2 B0,*+B15[16382]
0368 0x003ffcfc STW.D2T1 A0,*+B15[16380]
036c 0x003ffafb .word 0x003ffafb
0370 0x048ffaff STW.D2T2 B9,*+B15[4090]
0374 0x08200000 NOP
0378 0x07800000 NOP

Hier mit Byte-Swap:

0328 04000001
032c 5005149d STH.D2T1 A0,*+B14[19551]
0330 5009800a .word 0x004c7188
0334 f00b000a NOP
0338 ff068004 NOP
033c fbfa3f01 NOP
0340 fcfc3f01 NOP
0344 fefe3f41 NOP
0348 0b02a004
034c bc024000 NOP
0350 0c000006
0354 900d804a .word 0x00000384
0358 8d530116 EXTU.S1 A0,0,0,A0
035c 2007200a .word 0x001ea0a0
0360 300d000a LDB.D2T1 *+B14[1],A0
0364 fefe3f00 NOP
0368 fcfc3f00 NOP
036c fbfa3f00 NOP
0370 fffa8f04 NOP
0374 00002008
0378 00008007

Anscheinend gibt es bei byte-swap einige Codes mit denen der dis6x 
nichts anfangen kann. Daher neige ich dazu, dass es ohne Byteswap eher 
passen sollte.

Aber die vielen .word zwischen den Befehlen sind nicht gerade 
ermutigend...
Oder sind je 16 bit geswappt zu interpretieren?

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Dieter S. schrieb:
> Mit der "pmem" Datei von weiter oben stimmt wohl etwas nicht. Wenn man
> die Bytes entsprechend anordnet bekommt man das (20 Bytes aus "pmem" je
> Zeile):
>
> Das sind also 4 Bytes Offset und dann 16 Bytes Daten, die Daten
> entsprechen dem Inhalt aus "abe_firmware.c", die Reihenfolge der Bytes
> in den 32-Bit Werten ist allerdings vertauscht.

Das liegt vermutlich an der Übersetzung aus C-Konstanten bis man es aus 
dem /sys/kernel/debug wieder ausliest.

> Seltsam ist dass der Header (Versionsnummer und die Längen) auch
> enthalten sind.
>
> Ausserdem taucht an ein paar Stellen noch ein zusätzliches "0x0C" auf,
> dessen Bedeutung unklar ist:
>
>
>

> ...
> ...
> 00001080: 30 43 A0 0A 0B 00 00 06 A0 42 80 0A 0D 00 00 06  - 0C
> 00001090: 30 43 A0 0A 80 44 04 9D 80 47 04 9D 80 04 10 9C  - 0C
> 000010A0: 00 07 10 9C 90 44 04 9D 90 47 04 9D 80 46 04 9D
> 000010B0: 80 84 10 9D 00 87 10 9D B0 43 00 0A D0 00 80 05
> 000010C0: 30 43 A0 0A 90 44 04 9D 00 07 10 9C 90 47 04 9D  - 0C
> 000010D0: 80 84 10 9D 00 87 10 9D 80 44 04 9D 80 47 04 9D
> ...
> ...
>

Hm. Das könnte ein Artefakt des Hexdumpers sein.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Dieter S. schrieb:
> Ich gehe inzwischen davon aus dass der DSP des ABE (im Prinzip wohl der
> mit "AE" bezeichnete "Audio Engine") ein eher kleiner DSP ist und ein
> anderer Typ als der Haupt-DSP des OMAP ist.

Ja, das würde ich auch vermuten. Massgeschneidert auf den doch recht 
festgelegten Anwendungsfall um Transistoren zu sparen.

>> Die ABE Header Dateien geben ja ein paar Einblicke, insbesondere die
> Adressen in "abe_cm_addr.h", "abe_dm_addr.h" und "abe_sm_addr.h".
>
> Die Firmware besteht wohl aus verschiedenen Tasks, siehe "abe_taskid.h".

Wobei da einiges im Hauptprozessor läuft. Und die cm_addr usw. 
beschreiben wie der AE-DSP aus dem Adressraum erreichbar ist und welche 
Werte die Firmware wo ablegt. Man müsste diese Kontakten eigentlich 
irgendwie in der Firmware wiederfinden.

>
> Interessant wäre der DMEM Bereich wenn die Firmware läuft, speziell der
> Stack (der liegt im DMEM) würde eventuell ein paar mehr Rückschlüsse zum
> verwendeten DSP ermöglichen.

Sehr gute Idee. Hier angehängt ein Dump von 
/sys/kernel/debug/omap-aess/dmem Viel scheint da aber nicht drin zu sein 
(nachdem ein Sound abgespielt wurde).

> Und ein Blick in die "ABE Subsystem and ABE HAL addendums" wäre schön,
> die es laut einem Beitrag im TI Forum gegen NDA gibt. Die öffentliche
> Version davon enthält ja nur einen Teil des Ganzen.

Da habe ich leider auch nur die öffentliche Version.

Im OMAP5-TRM gibts weitere indirekte Hinweise und zwar ist das 
DSP-Subsystem ein separater "TMS320DM64TM 32-bit fixed DSP core for 
audio processing and general-purpose imaging and video processing. It is 
backward compatible with existing C64xTM video codecs."

Für den AE-DSP (der auch im Blockschaltbild separat ist) gibt es leider 
keinen Hinweis was das ist, nur dass er fürs Filtern u.a. zuständig ist.

[Dieter S. (ds1)]

Könntest Du eventuell noch die zur "dmem" Datei passende "abe_dm_addr.h" 
Datei hochladen? Ich weiss nicht ob sich die Adressen je nach Firmware 
Version ändern, nicht dass ich in die falsche Datei schaue. Danke.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Dieter S. schrieb:
> Könntest Du eventuell noch die zur "dmem" Datei passende "abe_dm_addr.h"
> Datei hochladen? Ich weiss nicht ob sich die Adressen je nach Firmware
> Version ändern, nicht dass ich in die falsche Datei schaue. Danke.

Gerne!

Es müsste diese hier sein (für die anderen FW-Versionen gibt es 
anscheinend keine): 
https://github.com/omap-audio/abefw/blob/master/include/009590/abe_dm_addr.h

[Dieter S. (ds1)]

Wenn man sich die Daten im Stack Bereich ansieht

Adresse: 0x0200 Länge: 0x0070 Name: stack

 A1 00 86 00 05 00 9B 05 60 06 08 06 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ...

dann wächst der Stack wohl nach oben und es handelt sich um 16-Bit 
Adressen.

Und das hier aus "abe_typedef.h"

typedef struct abetaskTag {
  /* 0 ... Index of called function */
  u16 iF;
  /* 2 ... for INITPTR of A0 */
  u16 A0;
  /* 4 ... for INITPTR of A1 */
  u16 A1;
  /* 6 ... for INITPTR of A2 & A3 */
  u16 A2_3;
  /* 8 ... for INITPTR of A4 & A5 */
  u16 A4_5;
  /* 10 ... for INITREG of R0, R1, R2, R3 */
  u16 R;
  /* 12 */
  u16 misc0;
  /* 14 */
  u16 misc1;
} ABE_STask;

deutet von den Kommentaren wohl darauf hin dass der DSP die Register A0 
bis A5 und R0 bis R3 hat, jeweils 16-Bit groß.

TI hat/hatte ja auch mal den "cDSP" (customizable DSP, TEC320 Familie) 
zu denen man wenig Details findet. Eventuell ist der "Audio Engine" ja 
so etwas.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Dieter S. schrieb:
> Wenn man sich die Daten im Stack Bereich ansieht
>
...
>
> deutet von den Kommentaren wohl darauf hin dass der DSP die Register A0
> bis A5 und R0 bis R3 hat, jeweils 16-Bit groß.

Wow, cool! Damit kann man auf Suche gehen!

>
> TI hat/hatte ja auch mal den "cDSP" (customizable DSP, TEC320 Familie)
> zu denen man wenig Details findet. Eventuell ist der "Audio Engine" ja
> so etwas.

Das hat schon sehr geholfen. Daher scheiterten bisher alle Versuche das 
als TMS320C6xx zu deuten.

ChatGPT meint zu wissen: The Texas Instruments TMS320C1x/C2x series of 
16-bit Digital Signal Processors (DSPs) features registers A0–A5 and 
R0–R3, matching your description.

Das kann man ja mal prüfen! 
https://www.ti.com/lit/ug/spru018d/spru018d.pdf?ts=1748181432238&ref_url=https%253A%252F%252Fwww.google.com%252F

Wobei es da wohl keinen Disassembler gibt.

Danke vielmals für diese neue Idee.

EDIT: also dass es Register A0..A5 und R0..3 gäbe konnte ich noch nicht 
bestätigen. Und auch die Aufteilung auf pram, cram, dram, sram scheint 
nicht recht zu passen. Eher in Richtung 
https://www.ti.com/lit/ug/sleu067a/sleu067a.pdf

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Neue Erkenntnisse:

1) Hypothese: es handelt sich nicht um einen C64x, sondern um einen 
C5xx.
Diese waren zur Markteinführung des OMAP4/5 ebenfalls weit verbreitet.

Zunächst: es gibt einen dis55: 
https://www.ti.com/lit/ug/spru280i/spru280i.pdf und 
https://software-dl.ti.com/codegen/non-esd/downloads/download_archive.htm#C5500

Leider erwartet er kein einfaches Binary (pmem) und hat keine Option -o= 
um einzelne Hexcodes zu disassemblieren.

Nach weiterer Studie der C5xx-Dokumentation zeigt sich, dass der wohl 
eine variable Befehlscodierung hat. Daher scheidet das aus.

2) Spektralanalyse auf den Bytestrom des pmem um die Befehlslänge 
abzuschätzen.
Die Hypothese ist, dass es einen Peak gibt wenn die Befehlslänge 
konstant ist. Bei variabler Befehlslänge gibt es keine regelmäßigen 
Muster.

Zum Vergleich für eine variable Befehlslänge dient ein 
CP/M-Programm-Binary von http://www.cpm.z80.de/binary.html#applications 
(APPS for CP/M-86 und dort TERMINAL.CMD und dann viele 0x00 gestrichen).

Das Ergebnis zeigt eindeutig einen Peak bei 0.25, also alle 4 Bytes. Der 
Z80-Code zeigt nur Rauschen (siehe PDF). Demnach sind es wohl 32-Bit 
Instruction-Words.

3) Firmware-Binaries von Version 9530, 9560 und 9590 vergleichen.
Wo sich etwas im pmem Code geändert hat sind ziemlich sicher Befehle 
anzutreffen.

z.B.:

git diff --no-index 009530\ abe_firmware.c 009560\ abe_firmware.c 
@@ -426,14 +426,15 @@
 0x9d0c8108,
 0x98801670,
 0x08200000,
-0x9c080048,
+0x9c080040,
+0x9c1e0008,
 0x9f1d0010,
 0x07800000,
 0x07800000,
-0x9d0c8158,
+0x9d0c8108,
 0x07800000,
 0x07800000,
-0x9d0c8108,
+0x9d0c8158,
 0x988016e0,
 0x08200000,
 0x160004a4,

Einfügungen/Tauschungen betreffen immer 32 bit => bestätigt 32-Bit 
Instruction-Word.

Da wird 0x9c080048 -> 0x9c080040 und ein 0x9c1e0008 eingefügt
Und 0x9d0c8108 wird vor die beiden 0x07800000 gezogen und 0x9d0c8158 
dahinter.

Wir haben aber keine C64x-Disassemblierung hingebracht. Könnte es sein, 
dass da einzelne Bits getauscht/verwürfelt sind, um den Code zu 
verschleiern?

4) Was wissen wir bisher über den AE-DSP?

- stammt ziemlich sicher von TI (warum sollten sie als Marktführer für 
DSPs ausgerechnet beim OMAP ein fremdes Design eingekauft haben)
- war, als der OMAP4 angekündigt wurde (Feb 2009, OMAP5 im Feb 2011) 
bereits eindesignt und getestet (also ab ca. 2007 entwickelt), und wohl 
eher ein deutlich älterer Standard-Baublock
- da die OMAP zunächst für Nokia entwickelt wurden und dann auf den 
freien Markt kamen, war Nokia vielleicht an der Architektur und Firmware 
beteiligt
- der "offizielle" DSP im OMAP5 ist definitiv ein C64x (lt. 
Datenblättern und Blockdiagrammen, 32-bit fixed-point, dynamically mixed 
32-bit and 16-bit instruction sets, lt. Wikipedia ein C64T)
- der AE-DSP hat smem, pmem, cmem (samples, program, coefficients) und 
dmem (data) genannte Speicherbereiche die auch vom Hauptprozessor aus 
ansprechbar sind
- Speichergrößen anscheinend: cmem 6KiB, dmem 64KiB, pmem 8KiB, smem 
18KiB
- ob diese Aufteilung nur für die Host-Seite gilt oder auch chip-intern 
oder nur durch die Firmware definiert wird, ist unbekannt
- Wortbreite 16 oder 32 bit? DMEM wird per 32-bit-access zugegriffen. 
Daher vermutl. auch Wortbreite des DSP.

Es ist also vermutlich ein 32-bit-Fixed-Point DSP von TI mit 
32-bit-Befehlsbreite und 96 KiB RAM. Ca. 2000 - 2007 entwickelt.

Vielleicht hat da einer der Mitleser weitere Tips. Danke.

[Dieter S. (ds1)]

Dass die Befehle 4 Bytes lang sind hat schon jemand herausgefunden und 
auch Befehle mit darin enthaltenen Sprungadressen identifiziert (den 
Link habe ich weiter oben bereits erwähnt):

https://github.com/mvduin/abefw-omap4plus/blob/master/fw/histogram.txt

Wenn man das auf die Firmware anwendet und genauer hinschaut kann man 
noch ein paar mehr mögliche Befehle identifizieren:

08 20 00 00 -> Return from Subroutine
0A 2x xx x0 -> Call Subroutine (Address xxxx)
0A 0x xx x0 -> Jump always (Address xxxx)

Die Adressen zählen dabei jeweils 4 Bytes (ein Befehl), "PMEM" geht also 
von Adresse 0x000 bis 0x7FF.

Das Ganze bringt etwas Struktur in die "PMEM" Firmware, die halbwegs 
stimmig ist und auch zu den "Function" Einsprüngen passt.

Allerdings wird es schwer die anderen Befehle zu analysieren wenn man 
keine Möglichkeit hat z.B. Veränderungen in den Registern zu beobachten.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Dieter S. schrieb:
> Dass die Befehle 4 Bytes lang sind hat schon jemand herausgefunden und
> auch Befehle mit darin enthaltenen Sprungadressen identifiziert (den
> Link habe ich weiter oben bereits erwähnt):
>
> https://github.com/mvduin/abefw-omap4plus/blob/master/fw/histogram.txt

Ah, das habe ich übersehen, weil ich bisher immer auf dem Original

https://github.com/omap-audio/abefw/tree/master/fw

gearbeitet habe. Da gibt es das Histogramm nicht. Gut aber dass alles 
das bestätigt.

>
> Wenn man das auf die Firmware anwendet und genauer hinschaut kann man
> noch ein paar mehr mögliche Befehle identifizieren:
>
>
>

> 08 20 00 00 -> Return from Subroutine
> 0A 2x xx x0 -> Call Subroutine (Address xxxx)
> 0A 0x xx x0 -> Jump always (Address xxxx)
>

Sehr guter Tip! Nach sowas habe ich gesucht.

Demnach stimmt etwas an meinem Disassembler (Aufruf?) nicht:

0124 0x08200000 NOP
0280 0x0a200720 .word 0x0a200720
0334 0x0a000bf0 .word 0x0a000bf0

Das kommt von ($A = Adresse, $HEX=0x08200000):

echo $A $HEX $(/Applications/ti/ti-cgt-c6000_8.3.14/bin/dis6x -o="$HEX")

Oder ist das einfach der falsche Disassembler (TMS320C6x Disassembler 
v8.3.14)?

> Die Adressen zählen dabei jeweils 4 Bytes (ein Befehl), "PMEM" geht also
> von Adresse 0x000 bis 0x7FF.
>
> Das Ganze bringt etwas Struktur in die "PMEM" Firmware, die halbwegs
> stimmig ist und auch zu den "Function" Einsprüngen passt.
>
> Allerdings wird es schwer die anderen Befehle zu analysieren wenn man
> keine Möglichkeit hat z.B. Veränderungen in den Registern zu beobachten.

Mit korrekt disassembliertem Code kann man immerhin versuchen, zu 
verstehen was da passieren könnte.

Danke!

[Dieter S. (ds1)]

Nikolaus S. schrieb:
>
> Mit korrekt disassembliertem Code kann man immerhin versuchen, zu
> verstehen was da passieren könnte.

Ja, wenn Du für diesen mit relativ großer Wahrscheinlichkeit nicht 
öffentlich dokumentierten Befehlssatz einer unbekannten CPU einen 
Disassembler hast.

Das ist ziemlich sicher keiner der von TI dokumentierten DSPs. Und dass 
das Teil auch relativ sicher keine 32-Bit CPU ist sondern 16-Bit habe 
ich weiter oben bereits erwähnt. Das muss noch nicht mal ein DSP sein, 
TI hat diverse "Spezial" CPUs, z.B. die PRU (wobei diese gut 
dokumentiert ist).

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Dieter S. schrieb:
> Nikolaus S. schrieb:
>>
>> Mit korrekt disassembliertem Code kann man immerhin versuchen, zu
>> verstehen was da passieren könnte.
>
> Ja, wenn Du für diesen mit relativ großer Wahrscheinlichkeit nicht
> öffentlich dokumentierten Befehlssatz einer unbekannten CPU einen
> Disassembler hast.

Ok, da es weder C5xx noch C6xx ist, ist das tatsächlich ziemlich 
unbekannt.

> Das ist ziemlich sicher keiner der von TI dokumentierten DSPs.

Danke für die Einschätzung. Ich kenne die alle zu wenig, um das ohne 
große Recherchen selbst beurteilen zu können.

> Und dass
> das Teil auch relativ sicher keine 32-Bit CPU ist sondern 16-Bit habe
> ich weiter oben bereits erwähnt.

Dagegen spricht ein bisschen dass der DMEM als 32 bit eingerichtet ist 
und dass es 96 KiB RAM gibt. Das wäre für einen 16-Bitter nicht ganz 
naheliegend.

> Das muss noch nicht mal ein DSP sein,
> TI hat diverse "Spezial" CPUs,

Bzw. Kombis aus 8051 und einem DSP: TAS3108 
(https://www.ti.com/lit/ug/sleu067a/sleu067a.pdf)
Den gab es schon, als der OMAP erschienen ist. Der DSP-Teil hat aber 48 
bit Datenbreite und  54-bit Instruktionen (quasi VLIW). Call/Return und 
Stack scheint es auch nicht zu geben. Also auch Sackgasse...

Zum schon mal von Dir erwähnten cDSP hab ich nur diesen Hinweis: "1991: 
... TI ist das erste Unternehmen, das ein Core-basiertes DSP-Design mit 
anpassbarem DSP (cDSP) bietet. cDSP bietet eine weitergehende 
DSP-Systemintegration und sorgt für schnellere Marktreife."
(https://www.elektronikpraxis.de/meilensteine-digitaler-signalprozessoren-von-texas-instruments-a-376473/?p=2)

Wenn davon einfach eine Variante drin ist (was naheliegend wäre), dann 
wird das nicht einfach.

> z.B. die PRU (wobei diese gut
> dokumentiert ist).

Die PRU kam erst im Okt 2011 mit den Sitara AM335x. Als 
Industrievariante des OMAP3, also später als der OMAP4. Könnte aber 
dennoch verwandt sein.

Die Befehlscodierung scheint nirgends dokumentiert zu sein. D.h. ich 
werde mal den (dis)assembler installieren und vergleichen.

Ah doch ein bisschen: https://www.ti.com/lit/ug/spruhv6b/spruhv6b.pdf
Demnach gibt es 32 oder 64bit-Befehle.

[Dieter S. (ds1)]

Nikolaus S. schrieb:
>
> Dagegen spricht ein bisschen dass der DMEM als 32 bit eingerichtet ist
> und dass es 96 KiB RAM gibt. Das wäre für einen 16-Bitter nicht ganz
> naheliegend.

Für was sind die 96 KByte RAM? Wenn das die Summe von PMEM, SMEM und 
CMEM ist und jeder davon kleiner als 64 KByte passt es doch.

Und da die Adressen für PMEN jeweils 4 Byte adressieren kann PMEM 
alleine schon 256 KByte groß sein.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Dieter S. schrieb:
> Nikolaus S. schrieb:
>>
>> Dagegen spricht ein bisschen dass der DMEM als 32 bit eingerichtet ist
>> und dass es 96 KiB RAM gibt. Das wäre für einen 16-Bitter nicht ganz
>> naheliegend.
>
> Für was sind die 96 KByte RAM? Wenn das die Summe von PMEM, SMEM und
> CMEM ist und jeder davon kleiner als 64 KByte passt es doch.

Ja:

- Speichergrößen anscheinend: cmem 6KiB, dmem 64KiB, pmem 8KiB, smem
18KiB

Ah, Du meinst Harvard- und nicht von-Neumann-Architektur und irgendein 
Bank-Switching. Ja, wäre auch möglich.

> Und da die Adressen für PMEN jeweils 4 Byte adressieren kann PMEM
> alleine schon 256 KByte groß sein.

Das ist auch eine wichtige Überlegung, da eine solche Optimierung die 
bei "normalen" von-Neumann-Prozessoren ja üblicherweise nicht gemacht 
wird. Dann reichen 16 Bit für die 96K mehr als aus.

Jetzt fehlt "nur" irgendein dokumentierter Prozessor, der dem wenigstens 
ähnelt...

[Rbx (rcx)]

Nikolaus S. schrieb:
> Seit Jahren versucht ein kleiner Kreis Interessierter den im OMAP4/OMAP5
> von TI (https://www.ti.com/lit/po/swpt034b/swpt034b.pdf) eingebetteten
> Audio-Signalprozessor zu verstehen. Sehr wahrscheinlich handelt es sich
> um einen TMS320C64x oder C66x oder ein Derivat aber das ist nicht ganz
> klar und nirgends verlässlich dokumentiert.

Kann man denn überhaupt davon ausgehen, dass sich da ein realer 
Hardware-Chip um den Sound kümmert?

(https://www.elektronikpraxis.de/anspruchsvolle-dsp-anwendungen-auf-cortex-m4-entwickeln-a-332809/?p=3
https://developer.arm.com/documentation/ddi0409/latest/)

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Rbx schrieb:
> Nikolaus S. schrieb:
>> Seit Jahren versucht ein kleiner Kreis Interessierter den im OMAP4/OMAP5
>> von TI (https://www.ti.com/lit/po/swpt034b/swpt034b.pdf) eingebetteten
>> Audio-Signalprozessor zu verstehen. Sehr wahrscheinlich handelt es sich
>> um einen TMS320C64x oder C66x oder ein Derivat aber das ist nicht ganz
>> klar und nirgends verlässlich dokumentiert.
>
> Kann man denn überhaupt davon ausgehen, dass sich da ein realer
> Hardware-Chip um den Sound kümmert?
>
> 
(https://www.elektronikpraxis.de/anspruchsvolle-dsp-anwendungen-auf-cortex-m4-entwickeln-a-332809/?p=3
> https://developer.arm.com/documentation/ddi0409/latest/)

Ja, das ist lt. Beschreibung eindeutig. Es gibt ein als "AE" 
bezeichnetesn Teil auf dem Chip der eine Firmware eingespeist bekommt 
und dann Datenströme filtert, in der Sample-Rate umwandelt und mischt 
und das Ergebnis über einen Port auf den Audio-DAC gibt usw. Also ein 
spezieller Sound-Coprozessor auf dem SoC.

Unklar ist nur völlig, welche Architektur das ist, wie der Befehlssatz 
und welche Filteralgorithmen implementiert sind.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

> 08 20 00 00 -> Return from Subroutine
> 0A 2x xx x0 -> Call Subroutine (Address xxxx)
> 0A 0x xx x0 -> Jump always (Address xxxx)

konnte ich inzwischen nachvollziehen (Danke!) und ich hab einen 
primitiven Disassembler angefangen (Ergebnis angehängt)...

Im Prinzip könnten das von der Wortbreite 32 bit auch ARM-Befehle sein. 
Aber es passt nicht.

Bei ARM wäre zu erwarten:
e5 9f d0 14 -> MOV PC, LR: Retudn from Subroutine
eb xx xx xx -> BL: Branch&Link always mit relativem Offset
ea xx xx xx -> B: Branch always mit relativem Offset

Damit können wir ausschließen:
- TMS320C64x
- TMS320C5xx
- PRU
- TAS3108
- ARM

[Stefan (Gast)]

Nikolaus S. schrieb:
> ChatGPT meint zu glauben

Als Mensch trau ich meinem echten Hirn, Du aber mehr der Katz?

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Nikolaus S. schrieb:
> Dieter S. schrieb:

08 20 00 00 -> Return from Subroutine
0A 2x xx x0 -> Call Subroutine (Address xxxx)
0A 0x xx x0 -> Jump always (Address xxxx)

> konnte ich inzwischen nachvollziehen (Danke!) und ich hab einen
> primitiven Disassembler angefangen (Ergebnis angehängt)...

Es gibt Neuigkeiten. Inzwischen konnte ich Anhand der Konstanten in 
abe_dm_linux.h schlüssig den Befehl identifizieren, der Konstanten in 
Register lädt.

16 0x xx xr -> load constant xxxx to register r (R0..R15)

R15 scheint der Stackpointer zu sein, denn der allererste Befehl unter 
Adresse 0x0000 initialisiert den exakt auf OMAP_ABE_STACK_ADDR

0000: 1600200f    const 0x0200,r15      # OMAP_ABE_STACK_ADDR[112]
0004: 0a000910    jmp 0x0244

Weitere solche im Code verstreute ld-Befehle laden die Adressen von 
anderen Parametern aus abe_dm_linux.h und machen anschließend einen 
unidentifizierten Befehl, der dasselbe Register r referenziert.

Z.B. beim Code der nach dem ersten jmp 0x0244 ausgeführt wird:

0244: 16006906    const 0x0690,r6       # OMAP_ABE_D_MAXTASKBYTESINSLOT_ADDR[2]
0248: 40000068    .word 0x40000068      # referenziert auch r6
024c: 16008c05    const 0x08c0,r5       # OMAP_ABE_D_MAXTASKBYTESINSLOT_SAVED_ADDR[4]
0250: 01000058    .word 0x01000058      # referenziert auch r5
0254: 160069ca    const 0x069c,r10      # OMAP_ABE_D_PPCURRENTTASK_ADDR[2]
0258: 400000a9    .word 0x400000a9      # referenziert auch r10
025c: 16008c06    const 0x08c0,r6       # OMAP_ABE_D_MAXTASKBYTESINSLOT_SAVED_ADDR[4]
0260: 00000068    .word 0x00000068      # referenziert auch r6
0264: 0400089b    .word 0x0400089b
0268: 4000009c    .word 0x4000009c
026c: 1600694e    const 0x0694,r14      # OMAP_ABE_D_PCURRENTTASK_ADDR[2]
0270: 410000ec    .word 0x410000ec      # referenziert auch r14
0274: 0600000c    .word 0x0600000c
0278: 1601538d    const 0x1538,r13
027c: 0a800a10    .word 0x0a800a10
0280: 0a200720    call 0x01c8

So wie es aussieht hat dieser (von mir "const" getaufte) Befehl einen 
16-bit-Parameter mit der Konstante, der auch mal 0x0001 oder 0xffff für 
+1 oder -1 sein kann. Ob deshalb die Register 16 oder 32 bit breit sind 
(und andere Werte irgendeinen Shift-Mechanismus brauchen) habe ich noch 
nicht herauslesen können. Es könnte also ein 16bit-Prozessor sein der 
32bit-Instruktionen hat. Oder ein 32-bit-Prozessor der Konstanten mit 
Sign-Extend lädt. Eher für 32 bit spricht, dass die meisten Variablen in 
abe_dm_linux.h eine SIZE von 4 haben, also auch einen 
32-bit-Wertebereich aus Sicht des OMAP-Prozessors erlauben.

Und eine wichtige Erkenntnis: es scheint 16 Register zu geben und R15 
ist der Stackpointer. Dessen Wert jedoch bei call/ret als 16-bit-Wert 
geschrieben/gelesen wird.

[Rbx (rcx)]

Könnte es sein, dass die Hexwerte da oben etwas vertauscht sind? 02080A 
z.B. müffelt doch geradezu nach ARM (32).

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Rbx schrieb:
> Könnte es sein, dass die Hexwerte da oben etwas vertauscht sind? 02080A
> z.B. müffelt doch geradezu nach ARM (32).

Danke für die Anregung!

Sowas hatte ich auch schon spekuliert, insbesondere da ARM ja auch 
32bit-Befehle hat (außer Thumb) und 16 Register. Seit ARMv6T2 kann der 
MOV auch 16 bit-Konstanten (siehe z.B.: 
https://developer.arm.com/documentation/dui0473/c/writing-arm-assembly-language/load-immediate-values-using-mov-and-mvn).

Aber es passt vorne und hinten nicht. Ein Load für eine Konstante ist 
bei ARM z.B. ein MOV R6,#0xffff (entspräche meinem "const 0xffff,r6") 
und das wird je nach Endian übersetzt 
(https://shell-storm.org/online/Online-Assembler-and-Disassembler/?inst=mov+r6%2C%230xffff%0D%0A%0D%0A&arch=arm&as_format=hex#assembly) 
als

ff 6f 0f e3 - little endian
e3 0f 6f ff - big endian

aber das hat mit 16 0f ff f6 wenig gemeinsam. Außer die Bits wären noch 
innerhalb der Bytes gedreht und einige invertiert.

Und auch dass es einen eigenen Stackpointer gibt der bei call/rts 
automatisch genutzt wir scheint nicht zu ARM zu passen.

Ich habe aber noch eine andere DSP-Architektur gefunden, die sowohl vom 
Konzept als auch Einsatzzweck (Audio Processing) und dem Zeitpunkt wann 
sie bzw. der OMAP4 auf den Markt kamen ganz gut passen könnte: CEVA 
TeakLite 3.

Möglicherweise ein TL321x von 2007: 
https://www.eetimes.com/signal-processing-dual-multiplier-32-bit-dsp-core-targets-3g/

Leider gibt es dazu kaum öffentliche Information (außer allgemeinen 
Beschreibungen). Es wäre zwar recht ungewöhnlich, dass auf dem OMAP4/5 
hier ein fremder Teil als DSP drauf wäre, wo ja TI den DSP mehr doer 
weniger erfunden hat. Aber die OMAP wurde in enger Kooperation mit Nokia 
entwickelt und vielleicht gab es da einfach eine Vorgabe.

Der CEVA TeakLite 2 scheint in der Nintendo DS drin zu sein und da gibt 
ein bisschen Reverse-Engineering der Gaming-Community, aber ganz schlau 
bin ich daraus noch nicht geworden und es passt auch nicht zu den bisher 
erkannten Befehlen: 
https://problemkaputt.de/gbatek-dsi-teaklite-ii-instruction-set-encoding.htm 
Immerhin hätte der offenbar einen eingebauten Stack und call/ret.

Jedenfalls scheinen diese DSPs sehr verbreitet zu sein (4 Milliarden 
Chips sollen den DSP enthalten: 
https://www.eetimes.com/4-billion-ceva-powered-chips-and-counting/) aber 
dennoch weitgehend unbekannt.

Daher kann ich nicht prüfen ob diese Idee stimmt.

Denbar wäre aber auch dass es ein MIPS oder PowerPC ist... Oder jeder 
auf dieser Liste: https://encyclopedia.pub/entry/32933 oder etwas 
proprietäres.

Wobei man MIPS schon ausschließen kann denn der hat 32 Register: 
https://en.wikibooks.org/wiki/MIPS_Assembly/Register_File und der 
Stackpointer ist $29 und nicht r15.