Wie erschließt man einen Chip von der Software aus ohne daß man Dokumentation zum Chip besitzt?

Das ist echt schade.
Dann werde ich das wohl sein lassen.

pointercrash() schrieb:

FSM-Freak schrieb:

und ich dachte immer die arbeiten mit 'finite' state machines.

dann denkst Du nur, daß Du denkst. Typisches Beispiel sind illegal Opcodes...Da hilft Dir kein FSM- Gefasel, echt nich ...

illegale opcodes verhalten sich auch deterministisch, wie eigentlich alles in einem digitalen system. solange z.b. die versorgungsspannung stimmt, also so, das das teil noch 'digital' arbeitet, gibt's nur eine endliche menge von möglichen zuständen.

~fricky schrieb:

pointercrash() schrieb:

FSM-Freak schrieb:

und ich dachte immer die arbeiten mit 'finite' state machines.

dann denkst Du nur, daß Du denkst. Typisches Beispiel sind illegal Opcodes...Da hilft Dir kein FSM- Gefasel, echt nich ...

illegale opcodes verhalten sich auch deterministisch, wie eigentlich alles in einem digitalen system. solange z.b. die versorgungsspannung stimmt, also so, das das teil noch 'digital' arbeitet, gibt's nur eine endliche menge von möglichen zuständen.

Ja und da alles in der Realität endlich ist laufen ja auch alle Algorithmen in O(1)

ohmannficky schrieb:

Ja und da alles in der Realität endlich ist laufen ja auch alle Algorithmen in O(1)

mit diesen O-dingens (laufzeit von algorithmen) hat das doch garnichts zu tun, menno.

Tachyon

~fricky schrieb:

pointercrash() schrieb:

FSM-Freak schrieb:

und ich dachte immer die arbeiten mit 'finite' state machines.

dann denkst Du nur, daß Du denkst. Typisches Beispiel sind illegal Opcodes...Da hilft Dir kein FSM- Gefasel, echt nich ...

illegale opcodes verhalten sich auch deterministisch, wie eigentlich alles in einem digitalen system. solange z.b. die versorgungsspannung stimmt, also so, das das teil noch 'digital' arbeitet, gibt's nur eine endliche menge von möglichen zuständen.

Das ist ja toll. Dann hat man ja echt deterministisch nicht auswertbaren Schrott generiert...

Tachyon schrieb:

Das ist ja toll. Dann hat man ja echt deterministisch nicht auswertbaren Schrott generiert...

würd ich nicht sagen. mit viel zeit, eifer, 'nem speicheroszilloskop (oder besser noch: einem logic-analyzer, wie pointercrah vorgeschlagen hat) kann man über einen unbekannten digitalchip sicherlich viel rauskriegen, z.b. das protokoll entschlüsseln, mit dem der kommuniziert usw.

pointercrash**

~fricky schrieb:

illegale opcodes verhalten sich auch deterministisch, wie eigentlich alles in einem digitalen system. solange z.b. die versorgungsspannung stimmt, also so, das das teil noch 'digital' arbeitet, gibt's nur eine endliche menge von möglichen zuständen.

Hab' ja nicht in Zweifel gezogen, daß das prinzipiell deterministisch bleibt. Ich habe mir den Hinweis erlaubt, daß man keinen Rückschluß auf den inneren Zustand der FSMs treffen kann.

Wenn man einer CPU z.B. den Takt verweigert, kannst Du am Rest Patterns einprägen, bis Du schwarz wirst, es wird sich aller wahrscheinlichkeit nach nichts rühren.
Desgleichen hast Du bei einigen CPUs den sofortigen Absturz, wenn Du ihnen den Reset verweigerst oder sie mit illegal opcodes fütterst.

Wie lange muß man eine CPU mit Patterns füttern, bis man eine korrekte Reset- Sequenz samt Wartezeit hat?

Als nächstes kommt der Zeitfaktor dazu, wenn Du nicht weißt, welche Zeiten zwischen welchen Patternfolgen liegen müssen. Nimm' einen Flashbaustein, Du erwischst wirklich den Opcode, eine Adresse zu beschreiben; normalerweise müßtest Du dann eine Adresse pollen, an der Dir ein Bit erzählt, wann der FSM- Automat sein Werk beendet hat. Dummerweise weißt Du nichts davon und löst einen weiteren Schreibbefehl aus. Egal, ob die FSM ihr altes Werk beendet und den neuen Befehl ignoriert oder abbricht und sich dem neuen Befehl zuwendet, nach Außen wirken die Ergebnisse wie zufällig.

Auch lustig: Der Chip hat 'ne PLL an Bord und man beschreibt die dafür zuständigen Register, macht jedoch weiter, ohne die nötige Wartezeit (für's Einrasten der PLL) mit nops zu stopfen. Ich kann dadurch tatsächlich mit etwa 50/50 - Wahrscheinlichkeit bei einem bestimmten Controller für die Blockade eines Timers sorgen (bis zum nächsten Reset). FSM hin, FSM her.

Egal, was Du für einen Baustein nimmst und wie sehr Du darauf beharrst, daß da innen FSMs tuckern, Du hast "von Außen" definitiv keine Chance auf eine vollständige Zustandstabelle des Innenlebens, zumindest nicht mit vertretbarem Zeitaufwand :p

^^@pc(): ich glaube, wir gehen von unterschiedlichen voraussetzungen aus. du findest einen chip in der bastelkiste, mit möglichst vielen pins, ohne beschriftung und willst rauskriegen was das ist, ne? sowas ist natürlich fast unmöglich. ich gehe davon aus, dass das ding schon in einer schaltung sitzt und man das verhalten am 'lebenden objekt' studieren kann.

pointercrash**

~fricky schrieb:

^^@pc(): ich glaube, wir gehen von unterschiedlichen voraussetzungen aus. du findest einen chip in der bastelkiste, mit möglichst vielen pins, ohne beschriftung und willst rauskriegen was das ist, ne? sowas ist natürlich fast unmöglich. ich gehe davon aus, dass das ding schon in einer schaltung sitzt und man das verhalten am 'lebenden objekt' studieren kann.

Liegt an der unscharfen Definition des Urposters. Er hat beschreibt zunächst das "lebende Objekt", verschärft aber nachfolgend die Fragestellung.
Gemeint habe ich, daß "brute force"- Verfahren zum Aufbau einer vollständigen Zustandstabelle scheitern würden.

Aber auch "lebende Objekte" können sich der Betrachtung ihrer "inneren Werte" weitgehend entziehen. Insofern wäre ich auch erstmal ratlos , wenn mir einer 'ne x86- CPU mit SSE2- unit hinwärfe und ich rausfinden müßte, was SSE2 tut, wie es angesprochen wird usw. - wär' ein schweiß- und tränenreicher Job, nicht wahr?

pointercrash() schrieb:

~fricky schrieb:

^^@pc(): ich glaube, wir gehen von unterschiedlichen voraussetzungen aus. du findest einen chip in der bastelkiste, mit möglichst vielen pins, ohne beschriftung und willst rauskriegen was das ist, ne? sowas ist natürlich fast unmöglich. ich gehe davon aus, dass das ding schon in einer schaltung sitzt und man das verhalten am 'lebenden objekt' studieren kann.

Liegt an der unscharfen Definition des Urposters. Er hat beschreibt zunächst das "lebende Objekt", verschärft aber nachfolgend die Fragestellung.

Oh, also um das aufzuklären ich meinte die Variante die Fricky genannt hat.
Also ich habe hier ein fertiges Gerät und da ist der Chip drauf.

Genaugenommen ist es eine OMAP 2420 CPU und von der ist zwar schon ne ganze Menge bekannt (ARM Architektur), aber nur der 2d/3d Chip (PowerVR) ist unbekannt.
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=4671&navigationId=11990&templateId=6123

Mich hätte interessiert, ob man an dessen Funktionalität rankommt.
Von mir aus auch nur als CoProzessor, also ohne das ganze des 3d Chips zu nutzen.
D.h. damit Matrizen berechnen können, das wäre schon ein Fortschritt, es muß also nicht der ganzen 3d Chip vollständig erschloßen werden.

Also ist der chip doch nicht ganz unbekannt. du kennst den typ schon mal, du weist, das da ein arm 11 drin ist, plus ein DSP und noch jede menge an kleinkruscht der einem das leben erleichtern oder auch erschweren kann.

wenn ich mal einen vergleich von dem Datenblatt eines AT91RM9200 auf den Baustein treffen darf, dann wird das ding gut und gern 1000 seiten haben, wenns reicht.

dein problem ist jetzt, das man warscheinlich an die orginal docu nur mit nda ran kommt. aber da taucht in der docu irgendwo das wort linux auf. ggf gibts da schon die passenden treiber, dann müste man nur noch abschreiben siehe http://linux.omap.com die haben sogar ne eigene seite

ich sag nur soviel, solange du nicht die passende docu dazu hast kannst du das vergessen, den wenn du nicht mal weist, welchen speicherbereich du ansprechen sollst, kannst du damit alles und garnichts anrichten. siehe oben.

Ich persönlich arbeite im embedded bereich mit etwas kleineren käfern. das was dich interresiert wird über den speicherbuss angesprochen. somit 2^32 mögliche adressen irgendwo hinzulangen und was zu finden oder nicht. Problem ist nur das wenn z.B. hinter einer Adresse nichts liegen sollte, eine exeption ausgelöst werden könnte/ sollte, je nach dem wie der hersteller lustig war.

für die 2D 3D einheit könnte ich mir vorstellen, das ein gewisser speicherbereich zum zugriff für diese funktionen vorgesehen ist, (vergleichbar mit out/in Addressen beim 80x86) das problem ist nur das so ein system zusätzlich noch ein power managment hat, an dem du je nach ausprägung so an zimlich allen takten drehen kannst, die du dir nur vorstellen kannst. und nicht alle einstellungen sinvoll sind. (selbst mit docu kann das schon ätzend sein daran rumzudrehen, wenn nur die hälfte drinnsteht) was ich sagen will solange die 2d / 3d Einheit nich den richtigen tackt vom power Mangement bekommt, tut sich da erst mal garnichts.

weiter sollten die falschen register z. B. im powermanagement verändert werden, kannst du dir den takt von z.B. dem SD-ram oder flash abklemmen oder noch besser vom Multi AHB oder sogar der CPU. Falsche zugriffe auf z.B. die PLLs die sicher in dem System existieren (irgendwoher müssen die 320MHz ja herkommen) killen dir unter garantie dein system. den ohne takt keine ausführung des programms.

einzige möglichkeit die ich sehe wäre die existierende software zu belauschen, und schauen, was die macht und wie sie es macht. wozu hat das ding ein JTAG interface. wenn nicht sogar ne trace zelle. nur ohne passende HW jeht das sicher auch nicht. denn ein Händie wird sicher nicht das Debug interface bestückt haben.

gruss

und noch viel spass beim flu....