Ich würde gern den Inhalt eines EPCS4 flash auslesen. Mein TL886 kann das scheinbar nicht?! zumindest finde ich besagten Chip nicht in der Liste der unterstützten Devices. Grundsätzlich sollte der sich doch wie jedes andere serielle Flash verhalten, oder? Sprich wenn es ein pinkompatibles Teil gibt, könnte ich den damit auslesen, löschen und programmieren?! Oder geht das auch mit der Quartus II Software? Ich finde Anschlußschemata in den PDFs um einen USB-Blaster mit dem AS Chip zu verbinden, aber irgendwie passt das nicht zu meinem Blaster-Clone. Da wo Pin 7 des Blaster-Headers auf DATA des Chips geht, liegt beim Clone nämlich Vsupply. Auch ist die Frage ob der Programmer im Quartus überhaupt lesen kann, oder nur zum schreiben konzipiert wurde.
Olli Z. schrieb: > Auch ist die Frage ob der Programmer im Quartus überhaupt lesen kann, > oder nur zum schreiben konzipiert wurde. Zumindest für das nach dem Schreiben sinvolle Verify ist ein Auslesen nötig... Und das Datenblatt zum Flash spricht auf Seite 32 vom "Writing and reading of ECPS device": https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cfg/cyc_c51014.pdf Und beim Handbuch zur Software SRunner ist das Lesen unter "Read back of EPCS data" ausdrücklich aufgeführt: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an418.pdf
:
Bearbeitet durch Moderator
Olli Z. schrieb: > Auch ist die Frage ob der Programmer im Quartus überhaupt lesen kann, > oder nur zum schreiben konzipiert wurde. Der kann das. Der 'Examine'-Knopf macht genau das Gewünschte (zumindest bei meinem Terasic USB Blaster). Viele Boards haben dafür einen "AS" (Active Serial) Pinheader, der direkt auf den Flash führt. Das Ergebnis ist eine .jic-Datei, die sich auch wieder flashen lässt. Nur: arg viel anfangen (außer halt als Backup) wirst Du mit dem Inhalt nicht können.
Markus F. schrieb: > Nur: arg viel anfangen (außer halt als Backup) wirst Du mit dem Inhalt nicht können. Warum glaubst Du das? Das müsste doch die Konfiguration für den FPGA in binärer Form sein. Könnte man das nicht für einen Simulator nutzen oder gar zu einer Konfiguration decompilieren?
Laut Datenblatt wird der USB-Blaster II so am 10-Pin header angeschlossen wie auf dem Bild zu sehen. Ich denke das er im JTAG und AS Mode dann einfach andere Pinouts hat, bzw. die IO-Ports anders belegt. Weil halt im JTAG-Mode der Pin 7 auf +3,3V liegt (Vsupply) obwohl er auf das DATA-Signal vom EPCS4 geht. Kann ja eigentlich nicht sein.
Olli Z. schrieb: > Könnte man das nicht für einen Simulator nutzen oder > gar zu einer Konfiguration decompilieren? Viel Spaß dabei.
Laut Datenblatt hat der EPCS4N eine Kapazität von 4 Mbit (4.194.304 bit, also 524.288 byte). Sein Pinout entspricht wohl dem "Standard" von seriellen Flash-Speichern im SOIC8 Gehäuse. Jedenfalls finde ich das bei vielen Chips dieser Art. Nachdem ich mit Quartus II irgendwie nicht an die Daten rangekommen bin, habe ich einfach mal was ausprobiert :-) Und zwar habe ich nach ATMEL Flash Speichern gesucht und der AT25F4096 kommt dem EPCS4 wohl sehr nahe. Er hat die gleiche Kapazität und Pinout und auch die Datenflußdiagramme ähneln sicht sehr. Jedenfalls habe ich mit meinem TL866 in der Einstellung des ATMEL den Flash auslesen können. Das ZIP davon habe ich angehanden. Einzig die ID die er TL866 ausliest scheint nicht zu stimmen, die ist immer 0x00 0x00. Wenn aber die Daten passen ist mir das wurscht. Im Datenblatt vom ATMEL steht: "MSB: The Most Significant Bit (MSB) is the first bit transmitted and received." und in dem vom EPCS4: "... addresses and data are shifted in and out of the device serially, with MSB first." Das sieht schon so aus, als würde es passen.
Olli Z. schrieb: > Das müsste doch die Konfiguration für den FPGA in > binärer Form sein. Ja, richtig. > Könnte man das nicht für einen Simulator nutzen oder > gar zu einer Konfiguration decompilieren? Die FPGA-Hersteller haben dafür mit Sicherheit ein internes Tool, aber da sie sich schon beim Datenformat bedeckt halten, wird man als Normalo nicht rankommen. WIMRE hat sich der Autor beim Icestorm-Projekt [1] die Mühe machen müssen, herauszufinden, welche Bedeutung welches Bit im Bitstream hat. Duke [1] http://www.clifford.at/icestorm/
Olli Z. schrieb: > Warum glaubst Du das? Das müsste doch die Konfiguration für den FPGA in > binärer Form sein. Könnte man das nicht für einen Simulator nutzen oder > gar zu einer Konfiguration decompilieren? Man könnte. Wenn du Lust auf sehr viel analytische Arbeit im Alleingang hast und es nicht publizierst. Intel, wie auch Xilinx können sonst mit ihren Fachanwälten sehr unangenehm werden und lassen hier schon mal Beiträge löschen. Aber dein Weg wird sehr lang werden, wenn es schon am Auslesen scheitert. Sollte jetzt mit einem FT2232H-basierten Adapter und flashload, flashrom, usw. nicht das Problem sein. Gibt da eine Menge auch offene Tools.
Ok, verstehe "security by obscurity". Verwunderlich das diese Methode trotz der aktuellen Zeit mit Internet noch funktioniert... Also kann ich mit dem ausgelesenen Datenstrom nichts anfangen :-|
Mal kurz zum Status meines Projektes, welches dank des Datenblattes, welches ich nun durchgearbeitet habe, deutliche Fortschritte macht: Mich interessiert zunächst der Bootmodus von dem Chip. Hier sind die externen Signale von ENV0 und ENV1 entscheident, ob vom internen ROM (16kb) oder vom externen Memory (Flash, bis zu 4MByte insgesamt über max. 2 CEs) gebootet wird. Mit ihnen wird auch der Einstiegspunkt festgelegt: ENV1 ENV0 Operating Environment Reset Vector 0 0 ROM32 mode 00FE 0000h 1 1 ERE16L mode 0040 0000h 1 0 ERE16H mode 0080 0000h Das interne ROM dient nur dazu einen zweiten Bootloader (SBL) nachzuladen, entweder über USB oder UART. In Normalfall soll mein Modul vom Flash booten. Dies tut es möglicherweise nicht mehr. Ein Update wird bei dem Modul per USB eingespielt, sprich man steckt einen entsprechend bespielten Stick ein, schaltet das Gerät und damit das Modul an und los gehts. Auch das tut es derzeit nicht. Eine Idee wäre die Pins ENV0 und ENV1 auf "0" zu setzen um das Modul zu zwingen den internen Bootloader zu starten, welcher dann per USB oder UART eine Software erwartet. Ich müsste dann noch wissen in welchem Format das vorliegen soll und natürlich die entsprechende Software besorgen. Die Mnemonic der Assemblerbefehle ist im Datenblatt vorhanden. Sie basiert auf der RISC Architektur. Ich würde dann mal versuchen was IDA dazu sagt... Um den Fehler im Modul zu finden ist natürlich Debugging eine tolle Sache. Hierfür unterstützt der Chip laut DB JTAG, Hardwarebreakpoints. Leider ist nicht beschrieben wie, also gehe ich davon aus das es einen "Standard" dafür gibt der implementiert wurde. Um die Flash-Speicher über den JTAG-Port des uC auszulesen und zu beschreiben wird eine Hilfssoftware notwendig sein, welche per JTAG ins SRAM vom Chip geladen und ausgeführt werden muss. Ich hoffe für den Chip eine Unterstützung beim Segger J-Link zu finden.
:
Bearbeitet durch User
Beitrag #5868285 wurde vom Autor gelöscht.
Bitte 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.