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?
:
Bearbeitet durch User
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...
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...
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.
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
:
Bearbeitet durch User
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.
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:
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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):
1 | 00000000: 90 95 00 00 00 20 00 00 AC 1E 00 00 00 40 00 00 |
2 | 00000010: 60 54 00 00 0F 20 00 16 10 09 00 0A 00 00 20 08 |
3 | 00000020: 00 00 20 08 00 00 80 07 CE 75 00 16 E0 0D 20 0A |
4 | 00000030: E4 00 40 01 E5 00 40 01 E6 00 40 01 E7 00 40 01 |
5 | 00000040: E8 00 40 01 E9 00 40 01 EA 00 40 01 EB 00 40 01 |
6 | 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:
1 | ... |
2 | ... |
3 | 00001080: 30 43 A0 0A 0B 00 00 06 A0 42 80 0A 0D 00 00 06 - 0C |
4 | 00001090: 30 43 A0 0A 80 44 04 9D 80 47 04 9D 80 04 10 9C - 0C |
5 | 000010A0: 00 07 10 9C 90 44 04 9D 90 47 04 9D 80 46 04 9D |
6 | 000010B0: 80 84 10 9D 00 87 10 9D B0 43 00 0A D0 00 80 05 |
7 | 000010C0: 30 43 A0 0A 90 44 04 9D 00 07 10 9C 90 47 04 9D - 0C |
8 | 000010D0: 80 84 10 9D 00 87 10 9D 80 44 04 9D 80 47 04 9D |
9 | ... |
10 | ... |
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.