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.
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?
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)"
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...
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.
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?
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.
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.
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:
1
520c 0x0041008A .word 0x0041008a
2
5210 0x003300D3 ADDK.S2 26113,B0
3
5214 0x003600D8 SUB.L1 -16,A13,A0
4
5218 0x003900D9 SUB.L1 8,A14,A0
5
521c 0x010500DA SUB.L2 8,B1,B2
6
5220 0x0105007D STW.D2T1 A2,*+B14[1280]
7
5224 0x0060007E STW.D2T2 B0,*+B14[24576]
8
5228 0x0060007E STW.D2T2 B0,*+B14[24576]
9
522c 0x010B007D STW.D2T1 A2,*+B14[2816]
10
5230 0x010B0082 .word 0x010b0082
11
5234 0x01080081 MPYH.M1 A0,A2,A2
12
5238 0x01080082 MPYH.M2 B0,B2,B2
13
523c 0x00030081 .word 0x00030081
14
5240 0x00030134 .word 0x00030134
15
5244 0x00030079 .word 0x00030079
16
5248 0x0024007A ADD.L2 B0,B9,B0
17
524c 0x00240134 .word 0x00240134
18
5250 0x00240079 ADD.L1 A0,A9,A0
19
5254 0x0107007A .word 0x0107007a
20
5258 0x01090085 LDHU.D2T1 *-B2[8],A2
21
525c 0x01070085 LDHU.D2T1 *-B1[24],A2
22
5260 0x0107013C STB.D2T1 A2,*+B14[1793]
23
5264 0x01090086 LDHU.D2T2 *-B2[8],B2
24
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):
1
520c 8a004100 EXTU.S1 A0,0,0,A0
2
5210 d3003300 NOP
3
5214 d8003600 NOP
4
5218 d9003900 NOP
5
521c da000501 NOP
6
5220 7d000501 LDHU.D1T2 *-A0[0],B0
7
5224 7e006000 LDHU.D1T2 *-A0[0],B0
8
5228 7e006000 LDHU.D1T2 *-A0[0],B0
9
522c 7d000b01 LDHU.D1T2 *-A0[0],B0
10
5230 82000b01 ADDK.S1 640,A0
11
5234 81000801 .word 0x04d3f961
12
5238 82000801 .word 0x04e33ba1
13
523c 81000300 LDW.D2T1 *+B14[21495],A9
14
5240 34010300 STB.D2T1 A4,*+B15[1780]
15
5244 79000300 LDW.D2T1 *+B15[13682],A9
16
5248 7a002400 LDHU.D1T2 *-A0[0],B0
17
524c 34012400 .word 0x0206fcf0
18
5250 79002400 .word 0x04b57b20
19
5254 7a000701 LDHU.D1T2 *-A0[0],B0
20
5258 85000901 LDH.D2T1 *+B4[8],A10
21
525c 85000701 STW.D2T1 A10,*+B15[4353]
22
5260 3c010701 NOP
23
5264 86000901 .word 0x05204505
24
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?
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.
00000050: EC 00 40 01 ED 00 40 01 EF 00 40 01 EF 00 40 01
7
00000060: E4 00 40 14 00 00 00 9E E0 0D 20 0A 40 00 00 9E
8
...
9
...
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:
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.
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:
1
0328 0x01000004 LDHU.D1T1 *-A0[0],A2
2
032c 0x9d140550 .word 0x9d140550
3
0330 0x0a800950 .word 0x0a800950
4
0334 0x0a000bf0 .word 0x0a000bf0
5
0338 0x048006ff STW.D2T2 B9,*+B15[6]
6
033c 0x013ffafb .word 0x013ffafb
7
0340 0x013ffcfc STW.D2T1 A2,*+B15[16380]
8
0344 0x413ffefe [ B1] STW.D2T2 B2,*+B15[16382]
9
0348 0x04a0020b EXTU.S2 B8,0,2,B9
10
034c 0x004002bc STB.D2T1 A0,*+B15[16386]
11
0350 0x0600000c LDHU.D2T1 *+B14[0],A12
12
0354 0x4a800d90 [ B1] B.S1 0xffffffffffd4006c
13
0358 0x1601538d .word 0x1601538d
14
035c 0x0a200720 .word 0x0a200720
15
0360 0x0a000d30 .word 0x0a000d30
16
0364 0x003ffefe STW.D2T2 B0,*+B15[16382]
17
0368 0x003ffcfc STW.D2T1 A0,*+B15[16380]
18
036c 0x003ffafb .word 0x003ffafb
19
0370 0x048ffaff STW.D2T2 B9,*+B15[4090]
20
0374 0x08200000 NOP
21
0378 0x07800000 NOP
Hier mit Byte-Swap:
1
0328 04000001
2
032c 5005149d STH.D2T1 A0,*+B14[19551]
3
0330 5009800a .word 0x004c7188
4
0334 f00b000a NOP
5
0338 ff068004 NOP
6
033c fbfa3f01 NOP
7
0340 fcfc3f01 NOP
8
0344 fefe3f41 NOP
9
0348 0b02a004
10
034c bc024000 NOP
11
0350 0c000006
12
0354 900d804a .word 0x00000384
13
0358 8d530116 EXTU.S1 A0,0,0,A0
14
035c 2007200a .word 0x001ea0a0
15
0360 300d000a LDB.D2T1 *+B14[1],A0
16
0364 fefe3f00 NOP
17
0368 fcfc3f00 NOP
18
036c fbfa3f00 NOP
19
0370 fffa8f04 NOP
20
0374 00002008
21
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?
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:
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.
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.
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.
dann wächst der Stack wohl nach oben und es handelt sich um 16-Bit Adressen.
Und das hier aus "abe_typedef.h"
1
typedef struct abetaskTag {
2
/* 0 ... Index of called function */
3
u16 iF;
4
/* 2 ... for INITPTR of A0 */
5
u16 A0;
6
/* 4 ... for INITPTR of A1 */
7
u16 A1;
8
/* 6 ... for INITPTR of A2 & A3 */
9
u16 A2_3;
10
/* 8 ... for INITPTR of A4 & A5 */
11
u16 A4_5;
12
/* 10 ... for INITREG of R0, R1, R2, R3 */
13
u16 R;
14
/* 12 */
15
u16 misc0;
16
/* 14 */
17
u16 misc1;
18
} 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.
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.
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
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.
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.
Firmware-Binaries von Version 9530, 9560 und 9590 vergleichen.
Wo sich etwas im pmem Code geändert hat sind ziemlich sicher Befehle anzutreffen.
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?
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
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):
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):
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).
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...
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.
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.
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...
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?
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?
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.
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
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.
1
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
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:
0270: 410000ec .word 0x410000ec # referenziert auch r14
13
0274: 0600000c .word 0x0600000c
14
0278: 1601538d const 0x1538,r13
15
027c: 0a800a10 .word 0x0a800a10
16
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.
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.
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.
