mikrocontroller.net

Forum: FPGA, VHDL & Co. Hilfe mit Altera Cyclone II (bzw. III)


Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe hier zwei TFT-Treiber Boards, eines hat einen Cyclone II vom 
Typ "EP2C8F256I8" drauf, im BGA-Gehäuse und das andere einen Cyclone III 
"EP3C25F324A7N", ebenfalls im BGA.

Beide Chips haben wohl von hause aus eine JTAG-Schnittstelle. Bei den 
vielfältigen Datenblättern und zig Versions- und Gehäusevarianten blicke 
ich aber überhaupt nicht mehr durch.

Wie könnte ich die Signalleitungen dafür lokalisieren? Ich glaube schon 
das die irgendwie rausgeführt sind, aber wie finden?

Beide Teile sind umsäht von SMD Widerstandsnetzwerken. Vermutlich wird 
jeder I/O-Port darüber laufen.

Datenblätter habe ich mir schon besorgt, aber wie gesagt finde ich da 
kein echtes Pinout. Da so ein Teil aber locker mal 250 und mehr Pins 
hat, gibts das so vielleicht auch nicht..?

Zudem ist es ja ein FPGA, also irgendwie doch frei programmierbar alles. 
Könnte es sein das die JTAG-Signale garnicht auf festen Pins liegen?

Ein wenig Schützenhilfe würde mich freuen. Hab mir schon die Finger 
wundgegoogled und Datenblätter mit hunderten Seiten durchforstet, aber 
im Moment ist es eher "Information-Overkill" und ich seh vor lauter 
Bäumen den Wald nicht ?! ;-)

Danke im Voraus,

Oliver

: Verschoben durch Moderator
Autor: Der Mitleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das ist in der Tat nicht einfach.

https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/dp/cyclone3/ep3c25.pdf

Die Pins, die mit "TMS", "TDI", etc. bezeichnet sind, das sind die 
JTAG-Balls. Du hast den F324.

Autor: Teekanne (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ob das etwas bringen wird ? Ein FPGA programmieren zu wollen, von dem 
man nicht mal das Datenblatt findet, und das JTAG Konzept nicht kennt ?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Peinlich), die PDF kannte ich, aber irgendwie kam ich mit den 
Bezeichnungen des Typs nicht klar. Dabei stehen die ja gleich auf der 
ersten Seite...

Das Konzept von JTAG ist mir grundsätzlich schon klar. Auch will ich den 
erstmal garnicht programmieren, sondern debuggen und lernen.

Der JTAG TAP auf dem Chip ist ja erstmal passiv, daher ist es praktisch 
nicht möglich die Pins mittels Oszi zu lokalisieren, denn die sind ja 
einfach nur statisch HIGH oder LOW.

Ich suche immer nach 10poligen Testpunkt Anordnungen. Meist ein guter 
Indikator für JTAG.

: Bearbeitet durch User
Autor: Teekanne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Testpunkte/Programmierschnittstelle bezieht auch das flash ein, 
und kann auch irgendwo sein und per Nadeladapter angesteuert werden.

Was ueblich sein kann .. es wird nur eine kleiner Kernel geladen, 
welcher einen Adresszaehler (Statemachine) fuer das Flash enthaelt plus 
einen Verschluesseler, der dann verschluesselten Code vom Flash laedt.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, Flash ist drauf. Darin vermute ich auch die Konfiguration des FPGA, 
denn ohne wäre dieser ja "dumm". Auf dem Board ist noch ein 4-Mbit 
EEPROM vom Typ EPCS4N. Das könnte sicher dazu gehören. Für den 
Arbeitsspeicher ist ein 128 MB SDRAM mit drauf.

Auf der Altera Homepage habe ich auch etwas zur JTAG-Konfiguration 
gefunden: 
https://www.altera.com/support/support-resources/support-centers/devices/cfg-index/cfg-jtag.html

Das werde ich mir mal zu Gemüte führen...

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Olli Z. schrieb:
> Auf dem Board ist noch ein 4-Mbit
> EEPROM vom Typ EPCS4N. Das könnte sicher dazu gehören. F

Ja, das hoert sich nach einem Config-Device fuers FPGA an.
Wenn du die JTAG Pins lokalisiert hast, dir einen USB-Blaster oder wie 
auch immer die Altera/Intel-Programmieradapter oder deren 
Low-Budget-Clone derweilen heissen, besorgt und richtig angeschlossen 
hast, dann wirst du bestenfalls hauptsaechlich das machen koennen:
A.) Das EPCS auslesen.
B.) das EPCS neu flashen ( z.B. mit was eigenem).
C.) das FPGA mit was eigenem konfigurieren, ohne was am EPCS zu aendern. 
(Ist nach dem naechsten Reset des FPGA wieder weg)

Mit dem ausgelesenen Inhalt des EPCS kannst du wahrscheinlich noch 
weniger was anfangen, wie wenn du in einem .exe file hoffst, irgendwas 
sinnvolles am Programm veraendern zu wollen.

Die Entwicklungsumgebung sollte es fuer umme geben, aber ich weiss nicht 
wie derweilen die Preise fuer den nackerten USB-Blaster vs. "Billig-FPGA 
Board mit eingebauter Programmierschnittstelle sind"

Teekanne schrieb:
> Was ueblich sein kann .. es wird nur eine kleiner Kernel geladen,
> welcher einen Adresszaehler (Statemachine) fuer das Flash enthaelt plus
> einen Verschluesseler, der dann verschluesselten Code vom Flash laedt.

Da wuerd' ich mir erstmal wenig Sorgen machen. iirc sind die Cyclone II 
und III ja die "Billig"-Schiene bei Altera, da wird's so'n Schweinkram 
nicht vom Hersteller geben, d.h. man muesst' es selbst programmieren und 
ob bei einem TFT-Treiber so hochgeheime Raketenwissenschaft 
dahintersteckt, dass sich das lohnt...?

Gruss
WK

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie finde ich denn nun die JTAG-Pins J1 (TCK), J2 (TMS), J5 (TDO) und J6 
(TDI) auf der Platine? Beim FPGA ist der Pin A-1 links oben bei der 
Markierung am Chip. Aber ohne den runterzulöten weiss ich nicht wo die 
Signale hinlaufen. Könnten per via auf die Unterseite gehen, aber auch 
an der Oberfläche laufen. Oder gar in den Layern dazwischen (falls es 
mehr als zwei sind...)

Autor: Felix U. (ubfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Mit dem ausgelesenen Inhalt des EPCS kannst du wahrscheinlich noch
> weniger was anfangen, wie wenn du in einem .exe file hoffst, irgendwas
> sinnvolles am Programm veraendern zu wollen.

Mit dem Unterschied, dass die Instruktionen für PC-Architekturen 
dokumentiert sind und FPGA-Bitstreams im Allgemeinen nicht.

: Bearbeitet durch User
Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:

> Ich suche immer nach 10poligen Testpunkt Anordnungen. Meist ein guter
> Indikator für JTAG.

Wieso zwingend 10-polig? für JTAG brauchts keine 10 leitungen. Ich würd 
mir mal die Testpunkte zwischen 15 und 16 anschauen. Gut möglich das da 
der Nadelbettadaptor zum Programmieren aufsetzt.

Autor: +++ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen "EP2C5" zusammen mit Configflash, Taktgenerator und
dokumentierten Anschluessen kannst du bei Ibei fuer ca.
12 - 15 Eu fertig zusammengeloetet kaufen.
Und den Altera USB-Blaster dazu auch.

Vielleicht solltest damit erstmal probieren ob dir die
Dinger ueberhaupt zusagen...

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Wie könnte ich die Signalleitungen dafür lokalisieren? Ich glaube schon
> das die irgendwie rausgeführt sind, aber wie finden?

wenn da ein EPCS4 drauf ist, der für's in-device programming per AS 
vorgesehen ist, dann müssen dessen Anschlüsse irgendwie nach aussen 
geführt sein.

Wenn nicht, ist's halt nicht vorgesehen.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> wenn da ein EPCS4 drauf ist, der für's in-device programming per AS
> vorgesehen ist, dann müssen dessen Anschlüsse irgendwie nach aussen
> geführt sein.
Gute Hinweis! Ja, es ist ein EPCS4 drauf, was mich eigentlich etwas 
wundert, denn laut Datenblatt 
https://www.altera.com/en_US/pdfs/literature/hb/cyc/cyc_c51014.pdf 
müsste beim EP3C25 ein EPCS16 verbaut werden, da dieser Chip 5 Mbit 
Configdata braucht. Für den EP2C8 hingegen würds stimmen. Vielleicht 
unwichtig...

Wenn ich die Active Serial configuration (AS) soweit richtig verstanden 
habe wird diese über 4 Signale realisiert DATA, DCLK, ASDI, nCS, welche 
zwischen Cyclone und dem EPCS4 verlaufen. Hierüber "zieht" sich der 
Cyclone beim Systemstart seine Konfiguration.

Was steht nun da drin? Ist das nur ein Bootloader, damit das eigentliche 
Programm des FPGA dann vom Flash-Speicher gelesen wird?

Wenn ich die Funktion des USB-Blaster hierbei richtig verstehe, dann 
kann man über diesen eine Reconfiguration aktivieren/forcieren und das 
Programm kommt vom PC über den USB-Blaster, anstelle vom EPCS4. Und hier 
könnte ich dann alles tun um den Flash auszulesen und neu zu 
beschreiben, richtig?

Die vier Signale sind in der Tat "rausgeführt" auf Testpunkte 
jedenfalls.

: Bearbeitet durch User
Autor: Der Zahn der Zeit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich grübele etwas, was das Ziel deiner Aktivität ist. Du schreibst:
> Wie könnte ich die Signalleitungen dafür lokalisieren? Ich glaube schon
> das die irgendwie rausgeführt sind, aber wie finden?
Ist es nur das Finden und nicht mehr? Als Selbstzweck wäre es etwas 
dünn.

Wenn doch, meinst du die vielen Signalleitungen, die über die 
R-Netzwerke laufen oder die wenigen Programmierpins, also JTAG und 
Config-ROM (EPCS4)? Geht es darum, welche Pins bzw. Balls wo extern 
angeschlossen sind?

Bei JTAG und Config-ROM liegen sie fest und stehen im Datenblatt. (Ja, 
sie liegen und stehen...)

Bei den Signalleitungen stellt sich die Frage, was du damit bezweckst. 
Willst du etwas "umprogrammieren"? Es wurde schon geschrieben, dass das 
nicht geht. Willst du etwas neu programmieren? FPGA lernen? Dann nimm 
auf keinen Fall dieses Board. Schon gar nicht, um ein TFT zum Leben zu 
erwecken. Es wird dir gelingen, aber erst nach einer langen Lernphase 
und nur theoretisch mit der Hardware, die du da hast.

Prinzipiell: Ich sehe zwei Möglichkeiten, heraus zu bekommen, an welchen 
Balls die Signalleitungen enden: 1. Mit Röntgen und 2. Das FPGA so zu 
programmieren, dass es nach einem bekannten Muster Signale auf 
definierten Pins (Balls) ausgibt und so nachzuvollziehen, auf welcher 
Leiterbahn welches Signal heraus kommt. Dafür würde das Config-ROM nicht 
gelöscht, die Programmierung über JTAG wäre immer nur temporär. D. h., 
dass das Board weiterhin voll funktionsfähig bleiben würde. Und so ein 
Test wäre durchaus auch als Anfängerprojekt geeignet.

> Wenn ich die Funktion des USB-Blaster hierbei richtig verstehe, dann
> kann man über diesen eine Reconfiguration aktivieren/forcieren und das
> Programm kommt vom PC über den USB-Blaster, anstelle vom EPCS4. Und hier
> könnte ich dann alles tun um den Flash auszulesen und neu zu
> beschreiben, richtig?
Man spricht nicht von Programm, sondern von Konfiguration. Die wird in 
ein RAM im FPGA geschrieben. Entweder direkt über JTAG (in der 
Entwicklung) oder das FPGA holt sich die Konfiguration aus dem 
Config-ROM. (Es gibt noch einige Möglichkeiten mehr.) Um das EPCS4 über 
JTAG zu programmieren, wird ein Umweg über das FPGA genommen. Und es 
gibt eine Möglichkeit, mit komprimierten Konfiguratitionsdaten zu 
arbeiten. Das könnte erklären, dass ein EPCS4 reicht. Mit ausgelesenen 
Config-ROM-Daten kannst du gar nichts anfangen, außer das Produkt 
abzukupfen.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Verstehe. Mein "Ziel" (wenn man überhaupt davon sprechen kann) ist es 
die Konfiguration von einem Board auf ein anderes zu übertragen. Eines 
hat nämlich einen Fehler und das andere Klappt einwandfrei. Der Fehler 
besteht darin das bestimmte Teile der Grafik am TFT nicht zu sehen sind. 
Andere Teile sind einfach nur weiß. Das sei aber nur am Rande erwähnt.

Eigentlich möchte ich einfach mehr über die Funktionsweise in Erfahrung 
bringen und da ist es immer gut wenn man nicht nur liest und liest 
sondern auch mal ganz praktisch was machen kann. Dafür habe ich eben 
zwei solcher "Spielboards". Damit ich da nicht versehentlich was 
überschreibe und es, wenn ich es denn je verstehen sollte, später wieder 
seiner ursprünglichen Bestimmung zuführen möchte, wieder mit der 
eigentlichen Programmierung, sorry Konfiguration, zu versehen :-)

Ein Mini-Programm drauf zu laden welches die IO-Pins nach einem Muster 
"blinken" lässt, wär schonmal ein Anfang. Vermutlich werde ich damit auf 
dem Board etwas Chaos auslösen, denn der FPGA steuert ja noch ein wenig 
Elektronik darauf, aber das sollte erstmal nicht stören. Auch werd ich 
das TFT erstmal ablassen.

Interessant finde ich, das es neben dem EPCS4 ja auch noch einen 8 MByte 
Flash Speicher gibt. Ich frage mich warum man beides verbaut hat, der 
Flash ansich hätte doch ausgereicht?

Das ich mit den Daten des EPCS4 nix anfangen kann ist mir schon klar. 
Will ich auch garnicht. Nur wegsichern, falls ich den mit meinen 
Versuchen überschreibe. Im Datenblatt zum JTAG steht nämlich das 
bestimmte Befehle diesen löschen.

Auf dem Bild ist das EPCS4 zu sehen, die Signale hab ich markiert. Der 
USB-Blaster benötigt aber noch ein paar Pins mehr (insgesamt einen 
10poligen Header... da sind sie wieder die 10 Pins ;-).

Die verwaisten durchkontaktierungen lassen für mich auf eine 
Multilayerplatine schließen, was bei so hochpoligen BGAs ja auch 
durchaus Sinn macht. Eine Röntgenapparatur habe ich selbstverständlich 
nicht zur Verfügung.

: Bearbeitet durch User
Autor: Der Zahn der Zeit (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Also das Ziel ist plausibel und erreichbar. Ich habe auf diese Weise 
auch schon einmal ein Gerät zum Leben erweckt, in dem ein µC (MSP430) 
das Zeitliche gesegnet hatte. Und im Moment habe zufällig wieder so 
einen Fall (PIC) auf dem Tisch...

2 Möglichkeiten, an die Daten im Config-ROM zu kommen: Über das FPGA 
könnte es gehen, wenn die IDE (der Programmer) so eine Funktion zur 
Verfügung stellt. Das weiß ich im Moment nicht, und gebraucht habe ich 
so etwas noch nie. Wenn allerdings keine JTAG-Anschlüsse herausgeführt 
bzw. erkennbar sind, entfällt das sowieso. Natürlich werden nur 4 
JTAG-Anschlüsse gebraucht (die 4 Test-Pads auf dem Foto rechts? Ganz 
schlecht nachzuprüfen). Nebenbei: Auf dem 10-poligen 
Standard-JTAG-Stecker sind noch 2 Massen, eine Spannungsversorgung, ein 
Pin, der mit Pull-up high gezogen wird, der Rest ist frei. Die Doku wird 
es genauer beschreiben können.

Ohne JTAG-Anschluss müsste das Config-ROM vorprogrammiert eingelötet 
worden sein. Dann bleibt nur noch, das Config-ROM direkt auszulesen. Der 
Algorithmus ist dokumentiert. Mit einem µC oder irgendwas anderem, was 
Pins wackeln lassen und lesen kann, sollte es gehen. Dafür könnte man 
das Config-ROM auslöten oder man müsste das FPGA davon abhalten, selber 
lesen zu wollen. Über die JTAG-Pins, aber wenn man die nicht kennt? Also 
auslöten.

Theoretisch kann man den Ladeprozess beim Einschalten des Gerätes 
aufzeichnen, aber dann muss man viele MBit mit 10 MHz Takt (glaube ich) 
in einen Speicher laufen lassen. Es könnte sein, dass ein guter Oszi das 
kann.

Jetzt geht mir noch durch den Kopf, dass es vielleicht auch möglich ist, 
mit einem USB-Blaster Config-ROMs direkt zu lesen und schreiben, aber 
auch dafür müsste es ausgelötet werden.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Olli Z. schrieb:
> Interessant finde ich, das es neben dem EPCS4 ja auch noch einen 8 MByte
> Flash Speicher gibt. Ich frage mich warum man beides verbaut hat, der
> Flash ansich hätte doch ausgereicht?

Das macht man aus Gruenden. Ich hatte mal zB. sowas gebaut, da war im 
EPCS die FPGA-config und ein Bootloader; in dem "anderen" Flash ein 
rootfs. Im FPGA hat dann eine NIOS-CPU sich an einem uclinux 
abgearbeitet

> Auf dem Bild ist das EPCS4 zu sehen, die Signale hab ich markiert.
Glueckwunsch, da hast du jetzt wohl die Standardpinbelegung so gut wie 
aller 8 fuessiger SPI-Flashes rausgefunden ;-) Dein "unteres" nCS ist 
ein DO.

Die 4 Testpunkte uebereinander unten rechts im Bild sehen mir irgendwie 
doch recht verdaechtig aus. Koennten das nicht die JTAG Signale sein?
Auf welchen Balls sollen die denn liegen?

Gruss
WK

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Der Zahn der Zeit schrieb:
> aber
> auch dafür müsste es ausgelötet werden.

Wuerd' mich wundern. Muesst' man mal im Datenblatt des FPGA nachgucken, 
aber ich koennt' mir gut vorstellen, dass das seine Hufe hochreisst 
(IO-Pins hochohmig), wenn man es im Dauerreset haelt. Solange kann man 
dann mit dem Configdevice seinen Schabernack treiben.

Gruss
WK

Autor: Der Zahn der Zeit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Olli Z. schrieb:
>> Interessant finde ich, das es neben dem EPCS4 ja auch noch einen 8 MByte
>> Flash Speicher gibt. Ich frage mich warum man beides verbaut hat, der
>> Flash ansich hätte doch ausgereicht?

Ist es nicht eher so, dass das FPGA seine Konfiguration nicht aus dem 
Flash auslesen kann, zumindest nicht, wenn der AP (active parallel) Mode 
nicht zum Flash passt? Und dann muss das Flash ja auch irgendwie 
programmiert werden - ginge das per JIC-File? Bin ich zu dumm zu... :-(

>> Auf dem Bild ist das EPCS4 zu sehen, die Signale hab ich markiert.
> Glueckwunsch, da hast du jetzt wohl die Standardpinbelegung so gut wie
> aller 8 fuessiger SPI-Flashes rausgefunden ;-) Dein "unteres" nCS ist
> ein DO.

Ist es wirklich so, dass die EPCS durch Standard-SPI-Flashs ersetzt 
werden können? Ist da nicht ein Unterschied? Ich weiß es nicht, ich habe 
mich das schon öfter gefragt.

Dergute W. schrieb:
> Wuerd' mich wundern. Muesst' man mal im Datenblatt des FPGA nachgucken,
> aber ich koennt' mir gut vorstellen, dass das seine Hufe hochreisst
> (IO-Pins hochohmig), wenn man es im Dauerreset haelt. Solange kann man
> dann mit dem Configdevice seinen Schabernack treiben.
Ja, nur müsste man dazu wissen, wo z. B. TMS, DEV_CLR oder MSEL liegt, 
und das ist dem Olli sein Problem... (Hallo Sebastian Sick!)

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Der Zahn der Zeit schrieb:
> ginge das per JIC-File?

Ich glaub' eher nicht. Ist bei mir aber schon ca. 10 Jahre her, dass ich 
damit gearbeitet hab'. iirc war da JIC das Mittel der Wahl, um eben in 
ein EPCS eine Kombi aus FPGA-config und Bootloader (oder andere 
Software) fuer den NIOS zu stopfen.
Das parallele Flash kann viel mehr Kopfzerbrechen bereiten. Beim 
Configdevice ist man ja an bestimmte Pins gebunden, bei einem Flash, was 
"einfach so" irgendwie am FPGA haengt, ist man kaum noch an irgendwas 
gebunden. Sollte man so ein Flash auslesen wollen, braucht man einen 
Schaltplan oder sonst irgendwelche Zusatzinfos.

Der Zahn der Zeit schrieb:
> Ist es wirklich so, dass die EPCS durch Standard-SPI-Flashs ersetzt
> werden können?

iirc haben die EPCS eine andere Device Signatur als die entsprechenden 
"billig"-Flashes. Frueher hat die Quartus-SW die dann nicht erkannt; da 
musste man die entsprechenden Signaturen der "Nicht-EPCS-Flashes" 
irgendwo noch eintragen, um diese Flashes dann von Quartus aus 
programmieren zu koennen. Bin mir aber nicht mehr sicher.

Der Zahn der Zeit schrieb:
> Ja, nur müsste man dazu wissen, wo z. B. TMS, DEV_CLR oder MSEL liegt,
> und das ist dem Olli sein Problem... (Hallo Sebastian Sick!)

Naja, muss man halt bissl forschen; mit Serienwiderstaenden arbeiten, 
damit mans schoen sehen kann, wenn 2 Outputs aufeinander prallen, etc.
4! = 24 Moeglichkeiten; das sollte man noch ausprobieren koennen, wenn 
man arg engagiert ist...

Gruss
WK

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Mein "Ziel" (wenn man überhaupt davon sprechen kann) ist es
> die Konfiguration von einem Board auf ein anderes zu übertragen. Eines
> hat nämlich einen Fehler und das andere Klappt einwandfrei.

Wenn die beiden Boards exakt dasselbe FPGA haben, müsste das gehen. 
Zwischen Cyclone II und Cyclone III geht das aber sicher nicht.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Verstehe. Mein "Ziel" (wenn man überhaupt davon sprechen kann) ist es
> die Konfiguration von einem Board auf ein anderes zu übertragen

Deine Beschreibung des "Problems" mit der Grafik lässt drauf schliessen, 
dass nicht die FPGA-Konfig futsch ist (sonst täte wohl gar nix), sondern 
der Inhalt des NOR-Flash.
Auch wenn du den Zugang zum JTAG findest, brauchst du immer noch die 
BSCAN-Tools, um das Flash auszulesen und die Pins durchzuklingeln, um 
überhaupt erst mal die Verkabelung FPGA<->Flash zu kennen.
Ich würde mich da mal etwas fokussieren, bevor hier die allgemeine 
Verzettelung ausbricht.
Insofern würde ich da zu kleineren Schritten raten, gerade, wenn du dir 
das Ding als Challenge suchst, oder ganz pragmatisch: Drähte ans Flash 
und mit einer bekannten Referenz auslesen. Schon probiert, den 
Schaltplan zum Gerät zu finden?

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe aus den Datenblättern für den Cyclone III das BGA-Pinout der 
Rückansicht für den EP3C25F324 auf ein Foto der Platinenrückseite 
montiert und die JTAG-Pins laut Datenblatt-Pinout dazu gezeichnet.

Leider ist nur ein einziger Pin davon auf der Unterseite mittels 
Durchkontaktierung erreichbar (TMS). Dafür liegt der Testpunkt schräg 
oberhalb. Die anderen Pins sind nicht durchkontaktiert, verlaufen also 
irgendwo auf der Platinenoberseite unterhalb des Chips. Ich wüsste nicht 
wie ich die finden sollte.

BGA hab ich noch nie gelötet, aber da muss ich wohl ran. Sonst werde ich 
nie herausfinden wo diese Pins auf dem Board landen.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Olli Z. schrieb:
> BGA hab ich noch nie gelötet, aber da muss ich wohl ran. Sonst werde ich
> nie herausfinden wo diese Pins auf dem Board landen.

Das wird wenig helfen. Die Oberseite der Platine wird in dem Bereich, wo 
das BGA war, hauptsaechlich kurze, diagonale Verbindungen zwischen den 
BGA-Balls und der naechsten Durchkontaktierung aufweisen. D.h., solltest 
du tatsaechlich das BGA sauber ausgeloetet bekommen, siehst du nur das 
Pad fuer den Ball, ca. 0.707mm Leitung und die Durchkontaktierung (auf 
eine Innenlage).
Schnapp' dir lieber ein Ohmmeter/Piepser mit spitzen Pruefspitzen und 
guck' doch mal, ob du nicht Verbindung(en) messen kannst zwischen einem 
der 4 Pruefpunkte in einer Reihe unten rechts und einer der 
"verdaechtigen" Durchkontaktierungen in der Naehe der von dir vemuteten 
Anschluesse.

Gruss
WK

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Weil alles Rätselraten nichts bringt, habe ich mich entschlossen eine 
der Platinen zu "opfern" und den FPGA runterzulöten. Nur so wissen wir 
was wirklich drunter steckt und nur so kann ich auch "durchklingeln" und 
mögliche Testpunkte finden.

Runterlöten ging leicht, einfach mit dem SMD-Fön warm machen bis er sich 
bewegen lässt. Umgekehrt hab ich noch keine echte Vorstellung wie ich 
den "Reballe" und wieder funktionsfähig drauf bekomme. Das wird ein 
interessantes Übungsprojekt ;-) Vor BGA hab ich bis jetzt immer einen 
Bogen gemacht. Bislang habe ich weder einen Pizzaofen noch einen 
IR-Preheater zur Verfügung. Auch spezielle niedrigschmelzende Lote hätte 
ich noch nicht da...

Anbei aber erstmal die Bilder nach dem ablöten, entzinnen und reinigen.

Anschließend habe ich die Pins laut Datenblatt ermittelt:
 * TMS => G1
 * TDO => G2
 * TCK => F2
 * TDI => H5

Die Signale habe ich auf die Pads des abgelöteten FPGA aufgezeichnet 
(cyclone_ii_pads_topview_jtags.jpg)
Diese laufen direkt auf eine Durchkontaktierung und wie WK schon 
vermutet hatte sind die auf der Unterseite des Platine nicht 
weitergeführt (cyclone_ii_pads_bottomview_jtag.jpg) sondern gehen in 
einer der inneren Layer weiter.

Da ich jetzt die richtigen Pins kannte, habe ich einfach mal alle 
Testpunkte durchgeklingelt und bin fündig geworden. Das Ergebnis ist im 
Bild "navi-fx_displayboard_jtag.jpg" zu sehen. Das ganze sieht aus als 
könnte dort sogar mal ein Steckadapter geplant gewesen sein.

Damit ist erstmal enträtselt ob und wo sich der JTAG-Connector auf dem 
Board befindet. Was mich persönlich schonmal einen guten Schritt weiter 
bringt! :-)

Als nächstes werde ich mir dort mal ein Connectorkabel für den 
JTAG-Adapter anlöten und mal schaun ob ich beim Segger-Interface was zu 
dem EP2C8 finde.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Als nächstes werde ich mir dort mal ein Connectorkabel für den
> JTAG-Adapter anlöten und mal schaun ob ich beim Segger-Interface was zu
> dem EP2C8 finde.
Wen der Segger nur mit ARM reden will, gibt gibt es beim Chinamann 
"Altera Mini Usb Blaster Cable For CPLD FPGA NIOS JTAG Altera 
Programmer" (langsam) oder in Taiwan einen passenden Programmer: 
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=&No=46

Duke

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut zu wissen! Einen USB-Blaster hab ich, zwar nicht exakt den von dir 
verlinkten... welche Software empfiehlst Du dafür?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Moin,

Wie waers' mit der Software - anscheinend die letzte, die Cyclone II und 
III unterstuetzt:

http://dl.altera.com/13.0sp1/?edition=web

Gruss
WK

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das war mir noch gar nicht im Bewusstsein, dass die neueren Altera 
Versionen die C2 und C3 rausgenommen haben. Intel-Dikat nehme Ich an?

Der C3 war ein ausgesprochen zuverlässiger Chip. In nicht wenigen Dingen 
besser als der Spartan6!

Beitrag "Re: Speichergrenze spartan6"

Beitrag #5335962 wurde von einem Moderator gelöscht.
Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe mir dieses "Quartus" Monster mal gezogen und installiert (ca. 5GB). 
Zum Glück ist das Billig-China-USB-Blaster-Teil was ich mir gekauft 
hatte soweit kompatibel das die Hardware mit dem Quartus-Eigenen 
USB-Treiber auch als Adapter erkannt wird :-)

Zu meiner großen Freude habe ich in der Toolchain den "JTAG Chain 
Debugger" entdeckt. Den werd ich mir mal näher ansehen! Sowas kann mir 
bei meinen Low-Level-Studien recht hilfreich sein.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn das hier langsam zum Monolog zu werden droht (scheinbar 
befassen sich nicht so viele Leute mit dem Thema..?!) möchte ich nochmal 
die Frage stellen wie der Startup und die Konfiguration eines solchen 
Systems aussieht, bzw. wie ich das ermittle?

Folgende Daten sind über das mir zur Verfügung stehenden Testboard 
(Displayboard mit TFT) bekannt:
 - Cyclone II EP2C8
 - 128 MByte SDRAM (MT48LC4M32B2)
 - 8 MByte Flash (S29GL064N)
 - 0,5 MByte Serial Configuration Device (EPCS4)

Wenn ich die Doku von Altera richtig verstanden habe (bitte berichtigen 
oder ergänzen wenns nicht stimm), ist der FPGA beim Starten 
unkonfiguriert. Um zu funktionieren benötigt der Chip seine 
Konfiguration im SRAM (intern? extern?). Dazu muss die Programmierung 
von einem externen Flash geladen werden. Hier kommen wohl die Modi AS 
(Active Serial) und PS (Passive Serial) ins Spiel und ab da blick ich 
nicht mehr recht durch.

Sitzt das "Programm" des FPGA denn wirklich auf diesem kleinen seriellen 
EPCS4? Oder ist da nur eine Art bootstrap-loader drin, der dann das 
eigentliche Programm aus dem Spansion flash nachlädt?

Ich habe auch was über einen PFL (Parallel Flash Loader) gelesen. Oder 
hat der mit dem Startup nichts zu tun?

Welchen Configmodus der FPGA verwendet ist wohl abhängig vom Logikleven 
an den MSEL-Pins. Da ich ja auch einem Spenderboard den FPGA 
runtergelötet habe, könnte ich die ja mal messen ob die gegen GND oder 
VCCIO gehen. MSEL0 liegt bei dem EP2C8 BGA wohl auf J13 und MSEL1 auf 
K12.

Der Flash ist sicher parallel an den FPGA angebunden, hat aber auch eine 
SPI-Schnittstelle. Ich vermute einfach mal das die Konfig parallel 
geladen wird und SPI nur zu Servicezwecken genutzt wird, evtl. sogar 
garnicht verbunden ist (habs noch nicht gemessen).

Die Konfigurationsdaten können laut dem EPCS4 Datenblatt auch 
"komprimiert" sein. Ist das dann nur "intern" im Chip um Speicherplatz 
zu sparen? Oder liefert der komprimiert aus und der FPGA dekomprimiert 
das?

: Bearbeitet durch User
Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Sitzt das "Programm" des FPGA denn wirklich auf diesem kleinen seriellen
> EPCS4?

Ja, sehr wahrscheinlich ist da die Konfiguration des FPGA drin, sonst 
wäre es ziemlich überflüssig.
Diese Konfiguration wird wohl einen Softcore (tippe mal auf NIOS2) 
enthalten, und das Programm für diesen wird im 8 MB Flash sein.

Andi

Autor: mmm (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Sitzt das "Programm" des FPGA denn wirklich auf diesem kleinen seriellen
> EPCS4?
Ja, denn für andere Zwecke nimmt man die Flashes vom eigentlichen 
Hersteller zu einem Bruchteil der Kosten. Der EPCS ist nichts anderes 
als ein von Altera (mittlerweile Intel) zugekaufter Flash, der 
umgelabelt wird und für den zehnfachen Preis wieder verkauft wird.

Olli Z. schrieb:
> Wenn ich die Doku von Altera richtig verstanden habe (bitte berichtigen
> oder ergänzen wenns nicht stimm), ist der FPGA beim Starten
> unkonfiguriert. Um zu funktionieren benötigt der Chip seine
> Konfiguration im SRAM (intern? extern?). Dazu muss die Programmierung
> von einem externen Flash geladen werden. Hier kommen wohl die Modi AS
> (Active Serial) und PS (Passive Serial) ins Spiel und ab da blick ich
> nicht mehr recht durch.

Der FPGA wird nicht "umkonfiguriert", das würde ja heißen, er hätte 
schon eine Konfiguration. Das FPGA besteht im wesentlichen aus vielen 
kleinen SRAM-Look-Up-Tabellen, die erstmal befüllt werden müssen. Dafür 
gibt es die verschiedenen Modi AS, PS,... Die Active Modi bedeuten, dass 
der FPGA die "treibende Kraft" ist und den Takt erzeugt, bei den Passive 
Modi werden die Daten mit einem externen Takt in das FPGA "gedrückt".
Da ein EPCS vorhanden ist, wird Active Serial verwendet.

> Der Flash ist sicher parallel an den FPGA angebunden, hat aber auch eine
> SPI-Schnittstelle. Ich vermute einfach mal das die Konfig parallel
> geladen wird und SPI nur zu Servicezwecken genutzt wird, evtl. sogar
> garnicht verbunden ist (habs noch nicht gemessen).
Welchen Flash meinst Du jetzt? Der EPCS kann nur SPI und das wird auch 
genutzt.
Der S29GL064N ist ein paralleles Flash ohne SPI, der mit der 
FPGA-Konfiguration höchstwahrscheinlich nichts zu tun hat. Parallel 
konfigurieren geht nur "passive", braucht also zusätzliche Bauteile 
(z.B. µC).
Im S29GL064N wird die Software für einen im FPGA implementierten 
Softcore-Prozessor (wahrscheinlich NIOS-II) sein.

> Die Konfigurationsdaten können laut dem EPCS4 Datenblatt auch
> "komprimiert" sein. Ist das dann nur "intern" im Chip um Speicherplatz
> zu sparen? Oder liefert der komprimiert aus und der FPGA dekomprimiert
> das?
Mit der Kompression hat der EPCS nix zu tun. Der ist nur ein doofes 
SPI-Flash. Quartus kann die FPGA-Konfig komprimieren und der FPGA kann 
diese wenn er sie einliest wieder "on-the-fly" dekomprimieren.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andi schrieb:
> Olli Z. schrieb:
>> Sitzt das "Programm" des FPGA denn wirklich auf diesem kleinen seriellen
>> EPCS4?
> Ja, sehr wahrscheinlich ist da die Konfiguration des FPGA drin, sonst
> wäre es ziemlich überflüssig.

Eben, das denke ich auch. Ansonsten könnte der doch gleich das Programm 
vom Flash laden, oder ist sowas garnicht vorgesehen? (Stichwort "PFL"). 
Warum sonst dieser Doppelsprung. Oder steckt in dem EPCS noch was zum 
Schutz gegen auslesen/manipulation? Ich mein, das ist ein Displaytreiber 
und keine Geldautomatensteuerung. So viel Aufwand würde da doch keiner 
machen?!

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank "mmm" für die Infos, das war gut zu verstehen und jetzt 
blicke ich schon etwas mehr durch!

mmm schrieb:
> Da ein EPCS vorhanden ist, wird Active Serial verwendet.
Dann müssten ja die MSEL-Pins so eingestellt sein:
MSEL0 = GND (LOW)
MSEL1 = GND (LOW)
oder für "Fast AS":
MSEL0 = GND (LOW)
MSEL1 = VCCIO3 (HIGH)

> FPGA-Konfiguration höchstwahrscheinlich nichts zu tun hat. Parallel
> konfigurieren geht nur "passive", braucht also zusätzliche Bauteile
> (z.B. µC).
Danke, jetzt verstehe ich das auch...!
Das sind die Signale "DCLK", "ASDI" und "nCS" die der Cyclone an den 
Flash bereitstellt und "DATA" die er liest.

> Im S29GL064N wird die Software für einen im FPGA implementierten
> Softcore-Prozessor (wahrscheinlich NIOS-II) sein.

> Mit der Kompression hat der EPCS nix zu tun. Der ist nur ein doofes
> SPI-Flash. Quartus kann die FPGA-Konfig komprimieren und der FPGA kann
> diese wenn er sie einliest wieder "on-the-fly" dekomprimieren.
Stimmt, steht ja auch so im Handbuch: "Cyclone II devices support 
configuration data decompression .... transmit this compressed bitstream 
to Cyclone II devices. During configuration, the Cyclone II device 
decompresses the bitstream in real time and programs its SRAM cells."

Laut Datenblatt braucht der EP2C8 ca. 2 MBit an Konfigdaten (größe des 
rohen, unkomprimierten binärfiles) um alle SRAM-Zellen einzustellen. Das 
heißt also das in diesem Chip die gesamte "Einstellung" des FPGA drin 
ist. Diese "Einstellung" bewirkt das der FPGA sich dann plötzlich wie 
eine CPU verhält und die auszuführende Software vom Flash ins SDRAM 
lädt?

> wahrscheinlich NIOS-II
Das hab ich schon paarmal was von gelesen. Was ist das denn? Klingt ja 
eher nach einem BIOS als nach einer CPU. Welcher Befehlssatz wird damit 
geladen? Im Flash muss ja praktisch eine Art Maschinensprache drin 
stecken und wenn man wüsste was das für eine CPU-Art/Emulation ist, 
könnte man die ja auch decompilieren.

: Bearbeitet durch User
Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Olli Z. schrieb:
> Diese "Einstellung" bewirkt das der FPGA sich dann plötzlich wie
> eine CPU verhält und die auszuführende Software vom Flash ins SDRAM
> lädt?

Ja.

Olli Z. schrieb:
> Das hab ich schon paarmal was von gelesen. Was ist das denn? Klingt ja
> eher nach einem BIOS als nach einer CPU. Welcher Befehlssatz wird damit
> geladen? Im Flash muss ja praktisch eine Art Maschinensprache drin
> stecken und wenn man wüsste was das für eine CPU-Art/Emulation ist,
> könnte man die ja auch decompilieren.

NIOS ist die CPU. So wie halt ein Z80 oder ARM5 oder x86. Da gibts ne 
(GNU)Toolchain dafuer.
In der FPGA-Entwicklungsumgebung kannst du dir dann je nach 
Performancewunsch und Gatter/Blockramverbrauch verschiedene NIOS-CPUs 
zusammenklicken, z.b. mit/ohne Caches, HW-Divider, etc. Kannst auch noch 
selbstgebastelte Befehlserweiterungen anflanschen,etc. bla. Ist schon 
ein schoenes Spielzeug.
iirc wird da auch der Resetvector festgelegt, also wo der NIOS dann 
anfaengt zu werkeln.

Aber das ist bei deinem Displaydingens alles nur Vermutung, weil da noch 
ein Parallelflash dranhaengt. Das muss nicht so sein, in dem Flash 
koennte z.B. auch nur ein Riesenbootlogo fuer das Display stehen, was 
voellig ohne NIOS auskommt.
Die Booterei ueber das EPCS duerfte dagegen ziemlich sicher so ablaufen.


Gruss
WK

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Ausführungen. Habs grad noch auf Wikipedia nachgelesen. 
Womöglich reden wir selbst bei diesem alteb Radio (ab 2007) schon von 
NIOS II. Die Architektur ist 32 Bit, Little Endian und bildet einen RISC 
Prozessor nach. Auf der kann dann, wie Du schon sagst eine normal in C 
geschriebene Applikation laufen.
Davon gehe ich auch aus.

Die Seggertools wollen vermutlich die CPU kennen um entsprechende 
Befehle via JTAG von dieser ausführen zu lassen, um diese z.b. 
anzuhalten, oder was weiss ich noch alles.

Womöglich läuft auf dieser CPU nicht nur einfach eine einzige 
Applikation, sondern ein Betriebssystem wie RTOS oder ein spezielles 
Linux!

Dann müsste es doch für diese Soft-CPU auch eine JTAG Schnittstelle 
geben...

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Olli Z. schrieb:
> Die Seggertools wollen vermutlich die CPU kennen um entsprechende
> Befehle via JTAG von dieser ausführen zu lassen, um diese z.b.
> anzuhalten, oder was weiss ich noch alles.

Ich weiss nicht, ob die halt den Alterakrempel unterstuetzen.

> Womöglich läuft auf dieser CPU nicht nur einfach eine einzige
> Applikation, sondern ein Betriebssystem wie RTOS oder ein spezielles
> Linux!

Ich glaub' ich schub's schonmal; ja das konnte man auch schon 2007 
machen. Da konnte man z.B. ein uclinux laufen lassen. uboot war im EPCS, 
hinter der FPGA Konfiguration; rootfs im Parallelflash. Da ist alles 
moegliche moeglich.
Man kann den NIOS auch bare-metal programmieren oder ohne externen 
Speicher, nur mit FPGA-internen BlockRAMs betreiben (wenn man sparsam 
mit dem Speicherplatz umgeht).

> Dann müsste es doch für diese Soft-CPU auch eine JTAG Schnittstelle
> geben...

Das laeuft dann alles ueber die JTAG -> USB-Blaster Verbindung. Da geht 
iirc sogar noch eine "serielle" Terminalverbindung mit drueber.
Das sollte eigentlich alles ootb mit der Quartus-SW unterstuetzt werden.

Gruss
WK

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich seh schon, an Quartus werde ich nicht vorbei kommen...
Das Problem wird sein, das solche Entwicklungsumgebungeb eher darauf 
ausgelegt sind, vorhandenen Code auf die Cores zu bekommen, als damit 
reverse-engineering zu betreiben.

: Bearbeitet durch User
Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also ich komme im Quartus in den Flash-Programmer bis zur gezeigten 
Stelle. Der Programmer erkennt per"Auto detect" den Cyclone, aber keine 
Peripherie daran. Weder den EPCS noch den NOR-Flash. Ich kann dann über 
den Chip einen CFI-Flash hinzufügen, dessen Größe ich auf 64 Mb (damit 
ist wohl Megabit gemeint) aus einer kleinen Liste auswählen kann.

Dann muss man den CFI-Flash aber irgendwie konfigurieren und da weiss 
ich nicht was ich einstellen soll.

CFI-Flash ist doch richtig, oder? Damit ist doch der Spansion-Flash 
gemeint?

Interessant finde ich, das er den EPCS4 nicht auch erkennt. Der müsste 
doch eigentlich in der JTAG-Chain auftauchen oder nicht? Oder gilt das 
nur für die EPC4, also die "Enhanced" AS Config-Flashes?

: Bearbeitet durch User
Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Das Problem ist eher, dass du erstmal engineering koennen musst, bevor 
du an re-engineering denkst. Also dir erstmal reinziehen, was so ein 
FPGA prinzipiell alles kann, wie das mit dem konfigurieren so hinhaut, 
welche Signale aus den I/O-Zellen raus/reinkommen koennen, etc. Und zu 
allem (Un)glueck, was dann noch dazukommt, wenn im FPGA ein (oder 
mehrere) CPU(s) am werkeln sind.
Und wenn du nur mal versuchst, da ein bisschen durchzublicken, wird dir 
klar werden, wie hoffnungslos so ein Unterfangen sein wird, da irgendwas 
re-engineeren zu wollen.
Beim seriellen Flash ist die Pinanzahl noch sehr uebersichtlich und es 
ist auch festgelegt und bestens dokumentiert, an welchen Pins das am 
FPGA angeflanscht werden muss.
Quartus unterstuetzt logischerweise schreiben (und auch lesen) dieses 
Flashes via JTAG ootb. Aber das ist im Detail auch schon etwas tricky, 
denn dazu wird das FPGA mit einem kleinen Image konfiguriert, was eben 
den Zugriff aufs Flash via JTAG erst ermoeglicht.

Fuer dein paralleles Flash gibts kaum mehr irgendwelche oeffentlich 
dokumentierte Vorgaben. Das ist von den Logikpegeln her und der 
Geschwindigkeit so anspruchslos, dass die Busse an fast jeden Pin des 
FPGAs angeschlossen werden koenenn. Programmiert muss es auch nicht 
ueber den JTAG werden, sondern das kann dann der NIOS machen, indem er 
z.b. uboot ausfuehrt oder ein uclinux oder oder oder...

Gruss
WK

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Oops, ueberschnitten...

Olli Z. schrieb:
> CFI-Flash ist doch richtig, oder? Damit ist doch der Spansion-Flash
> gemeint?
Ja, ich wuerd' sagen, damit ist das parallele Flash gemeint. Aber das 
wirst du wahrscheinlich gerade nicht via JTAG erreichen koennen.

> Interessant finde ich, das er den EPCS4 nicht auch erkennt. Der müsste
> doch eigentlich in der JTAG-Chain auftauchen oder nicht? Oder gilt das
> nur für die EPC4, also die "Enhanced" AS Config-Flashes?

Nein, der EPCS ist nicht in der JTAG Chain. Wie ich grad schon schrub: 
Dazu wird das FPGA per JTAG mit einem kleinen Image initalisiert, was 
das FPGA dann soweit bringt, sich seinerseits mit dem EPCS via SPI zu 
unterhalten.
Also solltest du gucken, dass du der IDE noch beibringst, dass da ein 
EPCS (und welches genau) an dem FPGA haengt. Kein CFI Flash.
Ich wuerd' sagen: Vergiss das Auslesen des parallel Flashs erstmal 
voellig.

Gruss
WK

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grad nachgemessen, MSEL1 liegt definitiv fest auf GND.
MSEL0 konnte ich nicht ermitteln, scheint "offen" zu sein. Er liegt 
jedenfalls nicht auf GND. Laut Datenblatt könnte sie dann noch VCCIO der 
Bank tragen. Die MSEL-Pins befinden sich in Bank3, also suche ich 
VCCIO3. Das kuriose ist, das laut Pinout beim BGA256 die VCCIO3-Pins 
garnicht rausgeführt sind! Dort ist nur die VCC vom PLL2 rausgeführt. 
Hmm...

Im Datenblatt ist vermerkt: "The MSEL[1..0] pins have 9-kΩ internal 
pull-down
resistors that are always active.". Wenn ich also keine VCCIO3 finde und 
der Pin wirklich unbeschaltet wäre, dann müsste man GND annehmen, 
richtig?

In dem Fall wäre MSEL=00 und damit "AS (20 MHz)". Das würde ja auch zum 
EPCS4-Chip passen.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Das Problem ist eher, dass du erstmal engineering koennen musst, bevor
> du an re-engineering denkst. Also dir erstmal reinziehen, was so ein
Ja, danke fürs "erden" ;-) P.S.: Trotzdem find ich es toll, das Du mir 
das alles so fundiert und geduldig versuchst beizubringen!!!

> denn dazu wird das FPGA mit einem kleinen Image konfiguriert, was eben
> den Zugriff aufs Flash via JTAG erst ermoeglicht.
Verstehe ich. Da wird also eine Art eigener Bootloader hochgeladen, der 
dann wiederum die Kommunikation JTAG<->AS-Flash ermöglicht. In den 
Zeichnung vom Handbook sieht es so aus als wären die Datenleitungen des 
AS-Flash zusätzlich auf einen externen Programmierstecker verbunden. Ich 
muss mal messen ob die irgendwo am Board an Testpins rauskommen.

> Fuer dein paralleles Flash gibts kaum mehr irgendwelche oeffentlich
> dokumentierte Vorgaben. Das ist von den Logikpegeln her und der
Das fürchte ich inzwischen auch.

Also, neben dem das ich grad ne Menge über so'n Zeug lerne, war mein 
Ansatz ja "nur" das Flash zu kopieren um mit dem Inhalt eines intakten 
Grafikboards eines mit ner Macke möglicherweise wieder flott zu 
bekommen. Und so hat sich das ganze aufgeschaukelt. Ich hatte gehofft 
das die Schnittstelle Cyclone<->Prog-Flash genauso standardisiert ist 
wie OMAP<->Prog-Flash.

Ich denk ja immernoch das die Entwickler dieses Navis nicht vor hatten 
die Welt neu zu erfinden, sondern einfache eine PC-Artige Architektur 
nachgebaut haben, auf der in C kompilierte Applikationen laufen.

Es ist kaum anzunehmen das jemand das Betriebssystem für ein Radio/Navi 
in Assembler eines NIOS oder sonstwas schreibt.

> Also solltest du gucken, dass du der IDE noch beibringst, dass da ein
EPCS (und welches genau) an dem FPGA haengt. Kein CFI Flash.
> Ich wuerd' sagen: Vergiss das Auslesen des parallel Flashs erstmal
voellig.
Ok. Es sieht mir aber so aus als würde sich das AS-Flash nicht über JTAG 
ansprechen lassen.
In der beigefügten Grafik aus dem Handbuch wird die AS-Configuration via 
JTAG beschrieben. Ich glaube ja, damit das geht muss ich noch was tun. 
Im Moment habe ich ja praktisch nur die "nackte" Hardware des FPGA dort 
eingehangen. Vermutlich muss man noch eine Konfigurationsdatei (SOF oder 
sowas) hinzufügen, damit der Programmer weiß, was der Chip so kann, bzw. 
wo das von dir besagte Bootloader-Image drin ist.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Olli Z. schrieb:
> In den
> Zeichnung vom Handbook sieht es so aus als wären die Datenleitungen des
> AS-Flash zusätzlich auf einen externen Programmierstecker verbunden.

Ja, ich fuercht', das ist etwas irrefuehrend. Es ist wohl auch moeglich, 
mit dem USB-Blaster nicht nur JTAG sondern auch SPI zu "sprechen" und so 
auch das serielle Flash direkt anzuquaken, solange das FPGA hochohmig 
bleibt. Aber ich mein, dass das eher was exotisches ist.

Olli Z. schrieb:
> Ich hatte gehofft
> das die Schnittstelle Cyclone<->Prog-Flash genauso standardisiert ist
> wie OMAP<->Prog-Flash.

Die Hoffnung kannst du fahren lassen ;-) Standardisiert/gut dokumentiert 
ist eben nur die Schnittstelle zum Configurations-Flash. Aber es gibt 
bei FPGAs sehr oft Anwendungen, wo ueberhaupt kein weiteres 
(Parallel)flash gebraucht wird, oder wo auch keine CPU drinnen ist. 
Daher ist da dann nix mehr genormt. Mit viel Glueck kannste zaghaft 
hoffen, das die Entwickler deines Boards massiv von einem FPGA-Evalboard 
abgekupfert haben, ueber das Schaltplaene etc. im www auffindbar sind, 
aber die Chancen dafuer sind schon eher mikroskopisch klein.
Realistisch ist's imho lediglich, wenn du das mit dem (seriellen) 
Config-Flash vorhaettest. Ob das dann was bringt, um dein defektes Board 
wiederzubeleben, ist aber auch hoch fraglich. Ueber das Config-Image 
sind ueblicherweise auch Pruefsummen berechnet und wenn das FPGA merkt, 
dass die nach dem Einlesen nicht stimmt (weil da z.b. im Flash 
irgendwelche Bits gekippt sind), dann sollte es wieder von vorne mit der 
Konfiguration anfangen.

Olli Z. schrieb:
> Ok. Es sieht mir aber so aus als würde sich das AS-Flash nicht über JTAG
> ansprechen lassen.

Ja, eben nicht direkt. Aber guck mal in deinem Bild: 
14-03-_2018_19-19-39.jpg
da gibt's nen "Mode" oben in der Mitte. Der steht bei dir auf JTAG. Guck 
mal, ob du den nicht auf AS oder sowas einstellen kannst und dann so 
ueber das FPGA auf das EPCS zugreifen.

Olli Z. schrieb:
> Ja, danke fürs "erden" ;-) P.S.: Trotzdem find ich es toll, das Du mir
> das alles so fundiert und geduldig versuchst beizubringen!!!

Irgendwie ist das bei mir untergegangen, dass du da lediglich das 
Parallelflash kopieren wolltest. Pardong. Aber das kannst du definitiv 
ohne ganz tief einzusteigen knicken. Und auch mit "tief einsteigen" 
ist's alles andere als sicher, das hinzukriegen.

Irgendwie gab's da ne Moeglichkeit, bei so einem NIOS-System eine 
"serielle" Konsole ueber das JTAG -> USB-Blaster Interface zu 
realisieren. Sollten die Entwickler deiner HW das gemacht haben, und das 
auch im Produkt drinnengelassen haben, und sollte da ein uclinux drauf 
laufen, dann koennte es sein, dass du da eine Chance hast, eine shell 
aufzumachen. Und dann den Inhalt von "/dev/mtd-Gedoens" ausgeben zu 
lassen. Das koennte dann evtl. das parallel Flash sein. Aber da sind 
soviele Konjunktive drinnen - da koenntest du auch Lotto spielen und auf 
den 6er hoffen.

Gruss
WK

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Oha. Kann obigen Beitrag nicht mehr bearbeiten:

Dergute W. schrieb:
> da gibt's nen "Mode" oben in der Mitte. Der steht bei dir auf JTAG. Guck
> mal, ob du den nicht auf AS oder sowas einstellen kannst und dann so
> ueber das FPGA auf das EPCS zugreifen.

Nee, derweilen glaub' ich, dass JTAG als Einstellung schon OK ist. Aber 
irgendwie hab' ich grad den Eindruck, dass die Uebernahme von Altera 
durch Intel nicht gerade zur Uebersichtlichkeit beim Auffinden alter 
Doku beigetragen hat :-/
<rundumschlag>Das stoesst mir bei diversen anderen Halbleiterherstellern 
auch schon oefter sauer auf. Da ist Klickibunti, flashartige animierte 
Scheisse, Videos, tolle Bilder von Drohnen, Clouds, IOT und konzentriert 
guckenden Menschen oder froehlichen fernsehglotzenden Familien oder 
handytelefonierenden Asiatinnen deutlich wichtiger, als irgendeine 
Struktur, wo man sich hurtig orientieren kann und schnell findet, was 
man sucht. Womoeglich auch noch Datenblaetter oder 
AppNotes.</rundumschlag>

Gruss
WK

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So langsam wirds immer runder, WK! :-)

Das mit der AS-Programmierung hab ich auch gelesen, im USB-Blaster 
Handbuch. Hierzu werden die eigentlich als JTAG-Pins genutzten 
IO-Leitungen für die AS-Programmierung (SPI?) verwendet. Dazu muss aber 
wohl eine direkte Verbindung vom TAP zum EPCS herstellt werden. Hierfür 
habe ich noch keine Schnittstellen-Pads auf dem Board finden können. Und 
wie Du sagst steht im Handbuch das man durch umstellen von "JTAG" auf 
"AS Programming" im Quartus solche Chips lesen/programmieren kann. 
Jedoch mit dediziertem ZIF-Sockel.

JTAG bietet ja mit dem Boundary-Scan die Möglichkeit die interne Logik 
eines Chips von seinen Pins abzukoppeln (so wie Du es mit "FPGA 
hochohmig machen" beschrieben hast) und die Pins direkt anzusteuern. So 
hätte ich gedacht, könnte eine Software auch ohne direkten Zugang zu den 
AS-Flash Pins diese via JTAG nutzen und zwar bidirektional. Aber 
entweder finde ich so einen Modus im Quartus nicht, oder es gibt ihn 
dort schlichtweg nicht...

Ebenso könnte man auch mit dem Flash verfahren. Da braucht es doch keine 
Unterstützung seitens des FGPA mit einem Bootloader als Middleware. Wenn 
man die Pins am FPGA kennt, an denen der Daten-Flash angeschlossen ist, 
müsste man den auf die gleiche Weise via JTAG auslesen und programmieren 
können.

Dazu habe ich den Flash ebenfalls vom Board runterlötet und angefangen 
die Verbindungen zwischen den Flash-Pins und dem FPGA zu ermitteln. 
Einige konnte ich bereits anhand von sichtbaren Leiterbahnverläufen 
finden (siehe Foto mit den roten Linien). Den Rest muss ich 
"durchklingeln".

Dabei ist mir noch ein fataler Fehler aufgefallen! Und zwar hatte ich 
bei dem Pinout die Buchstaben und Zahlenreihen vertauscht (grrrr). Hätte 
mir schon bei den JTAG-Pins auffallen müssen das die gefundenen Pads 
nicht mit dem Datenblatt-Pinout stimmen. Nunja, jetzt hab ichs 
korrigiert und in dem Foto neben den JTAG-Pins (rote Badges) auch noch 
die für das EPSC (blaue Badges) und die bereits gefundenen Flash-Pins 
(lila) eingezeichnet.

Folgende Pins vom S29-Flash konnte ich schon finden:
S29GL   FPGA    FPGA-Signalname
A2      B11     LVDS33n
A3      A11     LVDS33p
A4      B10     LVDS31n
A5      A10     LVDS31p
A21     B4      LVDS18n
WE#     A4      LVDS18p
A19     B5      LVDS19n
A9      A7      LVDS26n
A10     B7      LVDS26p
A12     B6      LVDS23n
A13     A6      LVDS23p
A15     D6      LVDS21n
A0      A12     LVDS34p
CE#     B3      LVDS17n

Ob das irgendeinen "Sinn" ergibt, oder wie angesprochen einem 
"Musterlayout" entspricht, keine Ahnung.

Ich versuche da zweigleisig zu fahren. Einerseits finde ich es total 
spannend tiefer einzusteigen, andererseits will ich mein Primärziel 
nicht aus den Augen verlieren. In einem der zahlreichen Dokumente von 
Altera war sogar sowas wie eine Reverse-Engineering-Anleitung drin die 
beschreibt, wie man von einem AS-Bitstream ein SOF macht. Sehr 
interessant. Im Altera Forum fragen auch immer wieder User über die 
Möglichkeiten des Rev-Eng an. Die Rückmeldungen dazu sind jedoch 
ernüchternd. Aber vielleicht klappts wenn man von zwei Flanken angreift. 
Einmal die Hardware untersuchen um ein Pinout zu erhalten und andere 
Daten wie die SRAM-Konfig oder so via AS-Daten.

Ich stimme Dir zu, das im Flash am Ende etwas drin steht, was nichts mit 
dem FPGA als solches zu tun hat, sondern reine User-Software ist. Auch 
scheint die Verwendung vin NIOS II sehr wahrscheinlich. uClinux oder 
RTOS ebenfalls. Da "reinzuschauen" wär schon interessant, aber nicht 
zwingend notwendig. Ich will ja eigentlich nur den Inhalt des Flashs von 
einem Board auf ein anderes übertragen ohne dazu die Chips auslöten, 
lesen und programmieren zu müssen.

Am Ende könnten mir die Kopierschutzfunktionen des S29-Flash noch einen 
gehörigen Strich durch die Rechnung machen...

: Bearbeitet durch User
Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Auch
> scheint die Verwendung vin NIOS II sehr wahrscheinlich.
Möglich.

> uClinux oder
> RTOS ebenfalls.
Nein.

Du redest doch noch von den Display-Treiberboards, oder?
Dann schau Dir mal an, was käuflich erwerbbare TFT-Boards für 
Schnittstellen haben:
- entweder SPI (hier zu langsam) oder
- RGB+Sync in digital (hat keinen eigenen Speicher) oder
- ein paralleles Businterface wie hier z.B.: 
ftp://imall.iteadstudio.com/TFT%20LCM/IM130820001/DS_IM130820001.pdf

Und in so einem Displaycontroller läuft eher kein Linux. Wahrscheinlich 
werden die Befehle auch nur von einer State-Machine gehandelt.

Duke

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Du redest doch noch von den Display-Treiberboards, oder?
Naja, ich kann das nicht zu 100% sagen. Aber welchen Grund sollte es 
sonst haben neben einem OMAP-Prozessor (der ja eine ARM-CPU und einen 
DSP hat) noch eine weitere "CPU" zu verbauen?

> Dann schau Dir mal an, was käuflich erwerbbare TFT-Boards für
> Schnittstellen haben:
Richtig, sehe ich auch so. Ich kann ja nur mutmaßen. Der Speicher (RAM) 
könnte schlichtweg nur ein Framebuffer sein, wie ihn jede andere 
"Grafikkarte" auch hat. Das ganze Konstrukt um den FPGA herum würde nur 
Sinn machen, wenn das in Summe billiger wäre als "fertige" 
TFT-Treiberbausteine zu verwenden.
In dem Fall, wenn es wirklich nur ein "Treiber" wäre, geb ich Dir recht 
das da dann kein Betriebssystem drauf laufen muss. Da bräuchte es aber 
dann auch nicht unbedingt eine Software auf Flash, da würde so AS-Config 
doch reichen?!

Tja, ohne das was da drin steckt rückwärts zu entwickeln wird das 
vermutlich ein Rätsel bleiben. Mich würds schon interessieren, aber dazu 
bräuchte ich Hilfe von erfahrenen FPGA Anwendern. Ich teile ja schon 
alle Erkenntnisse hier und würde auch Ergebnisse, sprich Dumps oder was 
auch immer teilen.
Also wer helfen mag, bitte!
Oli

Autor: 34C3 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde mich nicht wundern, wenn in dem parallelen Flash "nur" die 
Daten für einen "Bootsplash"-Screen drin wären.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Markus F. schrieb:
> Ich würde mich nicht wundern, wenn in dem parallelen Flash "nur" die
> Daten für einen "Bootsplash"-Screen drin wären.

Ja, die Idee hatte ich auch schon...

Aber nachdem ja schon ungefaehr die Haelfte der zum Flash gehenden 
Leitungen detektivisch erfasst sind: Wenn bekannt ist, an welchen Pins 
des FPGA alle Leitungen der Flashbusse enden, und man wuerde noch 
irgendwo einen Takt finden, der ins FPGA geht und dessen Frequenz man 
kennt und man haette noch irgendwo am FPGA ein Pin frei und noch 
irgendwo einen 3.3V -> RS232 Pegelwandler und dann noch einen PC mit 
entsprechender Schnittstelle...
Dann koennte man glatt auf die Idee kommen, mittels vielleicht 50...100 
Zeilen VHDL ein Design fuer's FPGA zu schreiben, was einfach den Inhalt 
des Parallel-Flashs ausliest und per serieller Schnittstelle an einen PC 
schickt.
Und dann koennte man zumindest mal gucken, ob man in den 8MByte 
Datenglibber irgendwelche Strukturen wie Logos, uboot-Variablen, rootfs 
ausmachen koennte. Wenn man das unbedingt machen wollte.

Gruss
WK

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ICH bin da dabei! :-)
Bin gerade damit beschäftigt möglichst alle ale Verbindungen zu 
lokalisieren. Zwischen dem Flash und dem FPGA liegen zahlreiche 33 Ohm 
Widerstände (die kleinen 4fach Netzwerke im Bild). Ich denke nur eine 
Vorsichtsmaßnahme, oder doch wirklich eine "Pegelanpassung für Arme"?
Naja, wenns sein müsste würde ich die Platine auch "opfern" und 
abschleifen. Das ist ja aber eine Multilayer und die sind nicht ohne. 
Ich vermute 4 Lagen. Besonders die typischen GND-Layer machen ein 
einfaches durchleuchten unmöglich und ein Röntgengerät hab ich nicht ;-)
Mal sehen wie weit ich mit meiner "Klingelei" komme... ich werde in 
Kürze berichten!

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Olli Z. schrieb:
> Zwischen dem Flash und dem FPGA liegen zahlreiche 33 Ohm
> Widerstände (die kleinen 4fach Netzwerke im Bild). Ich denke nur eine
> Vorsichtsmaßnahme, oder doch wirklich eine "Pegelanpassung für Arme"?

Nee, wohl eher zur EMV und Daempfung von Ueber/Unterschwingern auf den 
Busleitungen.

Gruss
WK

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab fast alle Verbindungen gefunden! Nur die drei gelb 
hinterlegten Signale finde ich zum ver*** nicht. DQ11 müsste eigentlich 
da sein. Alle DQ-Leitungen gehen auch noch zum RAM-Chip auf der 
Oberseite.
Unschlüssig bin ich mir bei WP#ACC und #RESET. Die sollten eigentlich da 
sein.

Habe das FPGA-Bild mit Lila-Punkten versehen, die ich gefunden habe.

Das PCB-Bild enthält die gefundenen Leitungswege in rot (hab noch nen 
blauen Layer drunter, da ich den aber nicht sehe ist der kreuz und quer 
und ich hab ihn, der Übersichtichkeit halber weggelassen)

Achja, was ich noch vergessen hatte zu erwähnen, auf dem Displayboard 
ist auch noch ein Header für einen SD-Card Sockel dran.

: Bearbeitet durch User
Autor: 34C3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um den Flash auszulesen sind alle nötigen Anschlüsse bekannt, wenn man 
sich auf einen 8-bit-Zugriff beschränkt, werden nur die Datenleitungen 
DQ0 .. DQ7 benötigt. Für ein Beschreiben sollte der Pin WP# geprüft 
werden. Vielleicht geht der auf eine Lötbrücke. Die CS-Leitung von SDRAM 
müsste am FPGA auch noch gesucht werden, damit das RAM in jenem Fall 
deaktiviert werden kann.

Mit den gewonnenen Daten kann man in Quartus II ein neues Projekt 
anlegen, in dem eine Zustandsautomat für das Auslesen integriert wird.
LVDS steht im übrigen für "Low Voltage Differential Signaling" und ist 
nur ein möglicher IO-Standard für die Anschlüsse.
Der Flash hat einen IO Spannungsbereich +1.65V .. +3.6V.
Infrage kämen damit: 1.8V, 2,5V, 3.0V-LVCMOS oder 3.3V-LVCMOS
Versorgungsspannung der IO-Bank und des Flash prüfen.

Was man noch für den Zustandsautomaten benötigt ist eine Tacktquelle, 
die an einem der CLK-Eingänge angeschlossen ist.
Bei Altera gibt es auch die Möglichkeit über die JTAG-Schnittstelle auf 
Benutzerlogik zuzugreifen, könnte man so in den Zustandsautomaten 
integrieren, einfacher geht es aber über eine Serielle Schnittstelle.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab noch einen Pin gefunden. Der WP#/ACC geht über einen 10k auf Vio des 
Chips. Finde auch nichts wie und das das Signal noch irgendwo anders hin 
geht, keine Durchkontaktierung, einzig ein Testpunkt. Laut Datenblatt 
ist damit einer hardwareseitiger Schreibschutz des ersten und letzten 
Sektors im Flash aufgehoben. Diese könnten jedoch noch softwareseitig 
gesperrt worden sein.

Somit dürfte der Pin für unsere Betrachung keine Rolle spielen und es 
ist auch für das System ok wenn dieser per Pullup auf High liegt.

Als Taktquelle habe ich unterhalb dem FPGA einen Quarz gefunden. 
Beschriftet mit „E55. 55“, also vermutlich 55 Mhz?!

Was die Betriebsspannung des Flahs angeht gehen ich von 3.0V aus, werde 
aber nochmal nachmessen.

Es fehlt mir noch der Reset-Pin. Ich hätte erwartet das der irgendwo auf 
ein RC-Glied geht, oder an einer zentralen Resetlogik hängt.

: Bearbeitet durch User
Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Es fehlt mir noch der Reset-Pin. Ich hätte erwartet das der irgendwo auf
> ein RC-Glied geht, oder an einer zentralen Resetlogik hängt.
Ich denke beim /Reset reicht der interne Pullup. Zum Lesen muß doch im 
Flash selber nichts gemacht werden: Addresse ran, /CS auf low und nach 
ein paar ns gibt es an DQ die passenden Daten.

Duke

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo. Die Frage ist noch, ob in den geschützen Sektoren oder sonst wo noch 
Informationen liegen die man für eine Kopie in einen neuen Flash 
benötigt.

Ich habe mal etwas rumgesucht und bin, mal wieder auf OpenOCD gestossen. 
Darin gibt es auch einen Flasher, konnte jetzt beim überfliegen der 
Quellen nur nicht erkennen ob das rein via JTAG BS geht, oder ob da ein 
Flashloader in den Chip hochgeladen wird, der dann irgendwie über den 
TAP mit dem Tools auf dem PC kommuniziert.

Im moment wäre mit eine reine JTAG BS Lösung am liebsten.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Im moment wäre mit eine reine JTAG BS Lösung am liebsten.

Guck dir doch mal urjtag an. OpenOCD ist aufgrund seiner Architektur 
nicht wirklich für Boundary Scan zu brauchen.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kurzer Abstecher zum Flash-Speicher. Es ist mir inzwischen gelungen das 
darin befindliche Image auszulesen. Gepackt oder verschlüsselt 
scheint(!) das jetzt nicht zu sein, da man überall Klartexte lesen kann 
(Gerätemeldungen, auch Debug-Infos). Die Frage wäre nun ob dieser Inhalt 
in irgendeiner Weise ein Filesystem für NIOS oder so darstellt?

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und hier noch ein Textfile welches nur die Strings aus dem Binary 
enthält. Stehen viele interessante Dinge drin. Offensichtlich wurde das 
in einer cygwin Umgebung (Linux für Windows) entwickelt, man findet 
sowas hier:
"/cygdrive/c/AlteraWork/ford/di_fgs_sw/Components/FgsVdKey/src/FgsVdKey. 
c"
Irgendwas mit TCL und VD Graphic.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steckt da eigentlich noch irgendwo ein Mikrocontroller/Mikroprozessor im 
System?
Das sieht nicht nur nach FPGA-Image aus.
Da scheint auch der komplette Code für ein Navi/Multimediasystem mit 
drinzustecken.

Frag doch mal in Estland nach:
Details zum Telefonbucheintrag
Mr. Perfect
+3728971234567
Obwohl, wenn ich mir die Nummer so anschaue, stimmt da maximal die 
Vorwahl.

'/dev/jtag_uart_0' könnte der gesuchte Hinweis auf ein NIOS sein.

Hast Du mal versucht, das Image als JFFS2 zu mounten?

Duke

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein nein, das ist nur für das Grafikboard. Auf dem Mainboard ist 
nochmal so ähnliches Konstrukt, jedoch mit viermal so großem Flash.

Der Cyclone hat ja auch noch ein EPSC4 drauf, wodurch sich vermutlich 
der FPGA zur CPU macht und dann von diesem Image die Applikation(en) 
ausführt.

Der Jtag uart klingt ja nach Debugport?!

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Der Jtag uart klingt ja nach Debugport?!

das ist der Standard "JTAG-UART" von Altera. Damit kann vom FPGA Text 
auf der "JTAG-Konsole" 
(<Quartus-Installationspfad>/nios2eds/nios2-terminal) Text ausgegeben 
werden.

Wenn Du ein lauffähiges Board hast, kannst Du ja mal gucken, ob das bei 
angeschlossenem USB-Blaster (und gestartetem nios2-terminal) was 
ausspuckt.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> das ist der Standard "JTAG-UART" von Altera. Damit kann vom FPGA Text
> auf der "JTAG-Konsole"
> (<Quartus-Installationspfad>/nios2eds/nios2-terminal) Text ausgegeben
> werden.
Klingt spannend! :-)

> Wenn Du ein lauffähiges Board hast, kannst Du ja mal gucken, ob das bei
> angeschlossenem USB-Blaster (und gestartetem nios2-terminal) was
> ausspuckt.
Ich habe aktuell "nur" die Version 12.1 von Quartus installiert. 
Vielleicht sollte ich mal auf die letzte verfügbare freie (WebEdition) 
13 updaten. Jedenfalls gibt es dort diesen Pfad so nicht, er lautet 
"<Quartus-Root>/nios2eds/bin/nios2-terminal.exe". Leider kommt beim 
Start eine Fehlermeldung (siehe Screenshot).

Ich hab mal die im BIN-Ordner befindliche "eclipse-nios2.exe" gestartet 
(siehe Screenshot). Damit komme ich aber irgendwie überhaupt nicht klar. 
Über das Debug-Menü hab ich es nur geschafft die JTAG-Hardware 
hinzuzufügen und glaube das die auch was aus dem Board ermitteln konnte 
(screenshot). Ich soll aber immer ein Projekt auswählen. Naja, ich hab 
ja keine Quellen.

Interessant fand ich aber die "Nios II Command Shell.bat". Hier zeigt er 
als Prompt nämlich auch den cygdrive/... an. So wie im Flash zu lesen. 
Ich denke wir sind auf der richtigen Spur! :-)

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Laut dieser Seite 
https://www.altera.com/support/support-resources/knowledge-base/solutions/rd09142004_1190.html 
kann man das Terminal auch in der SDK Shell starten. Das habe ich 
versucht und es scheint grundsätzlich zu klappen. Leider passiert auf 
dem Schirm sonst nichts, egal was ich am Gerät auch tue.

Vermutlich bedarf es eines geheimen Kommandos um die Debugausgaben zu 
aktivieren?!

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Das sieht nicht nur nach FPGA-Image aus.
> Hast Du mal versucht, das Image als JFFS2 zu mounten?
Hab mal nachgeschaut. Es müsste dann ein "Magic" drin sein, die Bytefole 
"19 85". Die finde ich auch (screenshot). Dieses Magic steht angeblich 
an Adresse 0x00024. Ich müsste also die Bytes vor diesem Offset 
entfernen und mal schaun ob sich das unter Linux so mounten lässt: mount 
-t jffs2 mtd2 /foo

Autor: Duke Scarring (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> mal schaun ob sich das unter Linux so mounten lässt: mount
> -t jffs2 mtd2 /foo
Ne, so gehts nicht. Speziell jffs2 läßt sich auch nicht als loop-Device 
mounten.
Aber jffs2 ist es offenbar nicht, weil auch jffs2dump nix findet (siehe 
Anhang).

Eine Frage an die NIOS-Nutzer: Was ist den unter NIOS ein gängiges 
Flash-Filesystem?

Duke

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Aber jffs2 ist es offenbar nicht, weil auch jffs2dump nix findet (siehe
> Anhang).

nachdem das - wenn ich mich recht erinnere - ein 16bit Flash-Käfer war, 
könnte das durchaus auch "bytegeswaptes" jffs2 sein.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... für NIOS wahrscheinlicher ist allerdings ein Zip-Filesystem. Das 
kommt mit dem Altera BSP schon mit.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darüber hab ich auch gelesen. Was jedoch dagegen spricht ist, das im BIN 
jede menge lesbarer Text drin steht. Beim ZIP wäre das nicht der Fall. 
Zudem kann ich es mittels ZIP auf gut 1/10 der BIN-Größe packen.

Ja, es ist ein 16-bit Flash und es gehen auch 16 IO-Leitungen vom Flash 
zum Cyclone. Das könnte aber auch rein aus Performancegründen so gemacht 
worden sein. Wenn ich das Flash mit dem MiniPro auslese zeigt dieser das 
auch in Words mit gedrehten Bytes an, weil er auch mit 16 Bit ausliest.

JFFS2 Support ist ja seit 2.4 im Kernel von Linux enthalten. Aber in 
welchem Paket findet man das jffs2dump tool?
Könnte man das nicht mit Hilfe der MTD (Memory Device) mounten? 
https://www.kutukupret.com/2010/09/16/mounting-a-jffs2-filesystem-in-linux/

: Bearbeitet durch User
Autor: Dergute W. (derguteweka)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Moin,

Nachdem da ja diverse Strings lesbar sind, glaub' ich nicht so recht an 
die Existenz eines (komprimierten) Filesystems. Unkomprimierte 
Bitmapgraphiken konnt' ich auch keine so recht auf Anhieb entdecken.

Es koennte schon direkt nios-code im Flash stehen. Solche Konstrukte wie 
z.B. hier:
.
     930:       dfc01317        ldw     ra,76(sp)
     934:       dc001217        ldw     r16,72(sp)
     938:       dc401117        ldw     r17,68(sp)
     93c:       dc801017        ldw     r18,64(sp)
     940:       dcc00f17        ldw     r19,60(sp)
     944:       dec01404        addi    sp,sp,80
     948:       f800283a        ret
     94c:       d0a02903        ldbu    r2,-32604(gp)
     950:       defff504        addi    sp,sp,-44
     954:       df000915        stw     fp,36(sp)
     958:       dc400715        stw     r17,28(sp)
     95c:       dd000415        stw     r20,16(sp)
     960:       dd800215        stw     r22,8(sp)
     964:       ddc00115        stw     r23,4(sp)
     968:       dfc00a15        stw     ra,40(sp)
     96c:       dc000815        stw     r16,32(sp)
     970:       dc800615        stw     r18,24(sp)
     974:       dcc00515        stw     r19,20(sp)
     978:       dd400315        stw     r21,12(sp)
     97c:       2039883a        mov     fp,r4
     980:       d8000015        stw     zero,0(sp)
     984:       05800044        movi    r22,1
     988:       0029883a        mov     r20,zero
     98c:       05ffe004        movi    r23,-128

koennten schon aus einem c-compiler stammen. Da werden oberhalb der 
"ret" Anweisung Register wiederhergestellt und Stackpointer bereinigt; 
unterhalb werden Register aufm Stack gespeichert.
Was man halt so macht, wenn man in eine Funktion rein- und wieder 
raushuepft...
Unn nu? Komm' ich getz' in Fernsehen ;-)?

Gruss
WK

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super WK! Naja, „und nu“. Mein ursprüngliches Anliegen war ja 
herauszufinden was mit dem Grafikboard nicht stimmt, das bestimmte 
Zeichen oder Grafiken „verschluckt“.

Eine Methode sollte die Flashkopie von einem intakten Board zu dem 
defekten sein. Hier gab zwei Ansätze, ein,al intern per Jtag und einmal 
ausgelötet per Programmer. Keins von beidem konnte ich bislang 
befriedigend umsetzen.

Ein erster Versuch den Flash direkt an einem Arduino Due (wg. den 3,3V 
IO) zu betreiben schlug komplett fehl, da ging garnix. Vielleicht greif 
ich das irgendwann nochmal auf...

Beim Flash-Programmer (MiniPro mit TL866) klappt das Auslesen halbwegs 
gut. Man braucht jedoch mehrere Anläufe, warum ist unklar, vielleicht 
liegts am fliegenden Aufbau. Beschreiben klappt noch garnicht, bricht 
bei knapp der Hälfte immer mit einem Verify-Fehler ab.

Für das lesen und schreiben mittels Jtag (eigentlich mein Favorit, weil 
man da nix rumlöten muss) hab ich immer noch keine Umsetzung um CFI 
Befehle darüber zu senden und Daten zu empfangen. Keine Ahnung wie ich 
das hinbekommen soll.

Dennoch hab ich bislang, dank Euch, schon viel neues gelernt!

WK, was benutzt Du als Disassembler? Und wie ist das mit dem NIOS? Da 
wird scheinbar mit C und TCL programmiert. Ist das NIOS nun eine CPU 
oder ein OS? Oder beides in einem?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Olli Z. schrieb:
> Beim Flash-Programmer (MiniPro mit TL866) klappt das Auslesen halbwegs
> gut. Man braucht jedoch mehrere Anläufe, warum ist unklar, vielleicht
> liegts am fliegenden Aufbau. Beschreiben klappt noch garnicht, bricht
> bei knapp der Hälfte immer mit einem Verify-Fehler ab.
Hm, ja koennt' schon der Aufbau sein. Wennste kannst, kannste nur 
versuchen alle Takte runterzudrehen, dass alles halt laaaaangsam vorsich 
geht.

Olli Z. schrieb:
> hab ich immer noch keine Umsetzung um CFI
> Befehle darüber zu senden und Daten zu empfangen. Keine Ahnung wie ich
> das hinbekommen soll.
Da wird's nix fertiges geben, das musst du oder irgendwer anders selber 
schreiben. Das muss ja zu deinem Board passen. Weil ja eben der 
"parallelFlash an FPGA" Anschluss nicht genormt ist.

Olli Z. schrieb:
> WK, was benutzt Du als Disassembler? Und wie ist das mit dem NIOS? Da
> wird scheinbar mit C und TCL programmiert. Ist das NIOS nun eine CPU
> oder ein OS? Oder beides in einem?
Das ging mit nios2-elf-gedoens-objdump aus den gnu-binutils. Wenn du dir 
den ganzen Alterakrempel runtergeladen hast, wird das wohl dabei sein. 
Zur Not kann man sich's aus den binutils-sourcen auch selberbasteln.

TCL ist wohl eher zum scripten gedacht, also fuer die Entwicklung der 
FPGA-"Software". Theoretisch kann man's sicher auch aufm NIOS laufen 
lassen, aber wozu?
NIOS ist nach wie vor nur die "naggiche" CPU. Wahrscheinlich in deinem 
Fall programmiert in bare-metal-c, ohne ein Betriebssystem. Oder nur 
irgendwas ganz kleines. Anscheinend wurde das Image, was aus dem linker 
faellt, nochmal ordentlich gestrippt, also alles rausgebaut, was 
debugging und reverse-engineering erleichtert und nur Speicherplatz 
kostet ;-)

Gruss
WK

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke WK. Leider kann ich beim MiniPro die "Taktrate" nicht 
beeinflussen. Der macht wie er lustig ist :-/

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier mal ein Blockschaltbild von der Verbindung Video-ADC -> 
FPGA -> LCD-Display beigefügt.
Der FPGA steht über einen Datenbus mit dem Hauptprozessor des 
Gerätemainboards in Verbindung und erhält darüber seine Grafikdaten zum 
Anzeigen im Display. Das digitalisierte Videobild kommt vom ADV7181.

Ist ein solcher Aufbau "typisch"? Als Benutzer sehe ich entweder ein 
Videobild oder eben die "Grafik" des Radios (z.B. Navigationskarte oder 
Menüs). Im Gerät erfolgt über ein bestimmtes CAN-Bus Signal 
(Rückwärtsgang eingelegt) die Umschaltung von Radio zu Video. Das 
geschieht aber nur, wenn auch wirklich ein Videosignal (RVC_CVBS) 
anliegt, ansonsten bleibt das Radiomenü angezeigt.

Die Entscheidung, welches Bildsignal zum LCD-Display geroutet wird, wird 
wohl intern im FPGA getroffen?! Sprich ich kann nicht von aussen einen 
Signalpegel verodern und somit auf Wunsch umschalten?

/Das PWR_DOWN_V_AD dient wohl für den Stromsparmodus und /ADV_RES um 
einen definierten Ausgangszustand einzunehmen. Über den I2C-Bus wird der 
Chip wohl konfiguriert. Wozu könnte INTRQ dienen?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Olli Z. schrieb:
> Ist ein solcher Aufbau "typisch"?

Wie willst du's sonst machen? Klar, wenn aus der Kamera kein CVBS kommt, 
sondern z.b. MIPI-CSI, wirst du einen anderen Chip als den ollen ADV7181 
brauchen. Wenn du eigentlich kein Display ansteuern willst, sondern eine 
LED blinken lassen, wirds auch mit einem 555 gehen...

Olli Z. schrieb:
> Die Entscheidung, welches Bildsignal zum LCD-Display geroutet wird, wird
> wohl intern im FPGA getroffen?

Vermutlich. Wenn ich schon eine Schaltung mit FPGA entwickle, schau' 
ich, dass ich das FPGA moeglichst vollstopf', denn ich krieg kein Geld 
zurueck, wenn ich das FPGA nur zu 20% ausnutze. Alles was im FPGA 
drinnen ist, kostet schonmal keine Hardwarekomponenten mehr extra und 
keinen Platz auf dem PCB.

Olli Z. schrieb:
> Wozu könnte INTRQ dienen?

Im Datenblatt vom AV7181 seh' ich kein INTRQ; an/von welchen Pin des 
Chips geht/kommt denn das Signal?

Gruss
WK

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.