Forum: FPGA, VHDL & Co. EPCS4 flash auslesen


von Olli Z. (z80freak)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Markus F. (mfro)


Lesenswert?

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.

von Olli Z. (z80freak)


Lesenswert?

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?

von Olli Z. (z80freak)


Angehängte Dateien:

Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

Olli Z. schrieb:
> Könnte man das nicht für einen Simulator nutzen oder
> gar zu einer Konfiguration decompilieren?

Viel Spaß dabei.

von Olli Z. (z80freak)


Angehängte Dateien:

Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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/

von Fitzebutze (Gast)


Lesenswert?

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.

von Olli Z. (z80freak)


Lesenswert?

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 :-|

von Olli Z. (z80freak)


Lesenswert?

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
von Markus F. (mfro)


Lesenswert?

Olli Z. schrieb:
> von dem Chip

Welchem?

Beitrag #5868285 wurde vom Autor gelöscht.
von Olli Z. (z80freak)


Lesenswert?

Sorry, falscher Thread!

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
Noch kein Account? Hier anmelden.