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
Angehängte Dateien:
-
71rpI33DRBL._SL1500_.jpg
190 KB -
cyclone_iii.jpg
240 KB -
cyclone_ii.jpg
150 KB -
cyclone_ii_pcbrear.jpg
96 KB
:
Verschoben durch User
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.
Ob das etwas bringen wird ? Ein FPGA programmieren zu wollen, von dem man nicht mal das Datenblatt findet, und das JTAG Konzept nicht kennt ?
(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
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.
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...
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
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...)
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
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.
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...
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.
Angehängte Dateien:
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
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.
Angehängte Dateien:
-
epcs4_pcb-backside.jpg
180 KB
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
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.
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
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
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!)
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
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.
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?
Angehängte Dateien:
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.
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
Angehängte Dateien:
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.
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
Gut zu wissen! Einen USB-Blaster hab ich, zwar nicht exakt den von dir verlinkten... welche Software empfiehlst Du dafür?
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
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.
Angehängte Dateien:
-
02-03-_2018_17-39-11.jpg
58 KB -
02-03-_2018_17-39-50.jpg
140 KB
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.
Angehängte Dateien:
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
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
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.
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?!
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
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
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...
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
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
Angehängte Dateien:
-
14-03-_2018_19-19-39.jpg
160 KB
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
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
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
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.
Angehängte Dateien:
-
14-03-_2018_20-13-50.jpg
79 KB
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.
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
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
Angehängte Dateien:
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
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
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
Ich würde mich nicht wundern, wenn in dem parallelen Flash "nur" die Daten für einen "Bootsplash"-Screen drin wären.
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
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!
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
Angehängte Dateien:
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
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.
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
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
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.
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.
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?
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.
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:
1 | Details zum Telefonbucheintrag |
2 | Mr. Perfect |
3 | +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
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?!
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.
Angehängte Dateien:
-
26-03-_2018_20-26-33.jpg
29 KB -
26-03-_2018_20-31-47.jpg
120 KB -
26-03-_2018_20-34-48.jpg
180 KB
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! :-)
Angehängte Dateien:
-
26-03-_2018_21-14-23.jpg
69 KB
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?!
Angehängte Dateien:
-
26-03-_2018_21-29-04.jpg
120 KB
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
Angehängte Dateien:
-
empty.png
2,4 KB
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
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.
... für NIOS wahrscheinlicher ist allerdings ein Zip-Filesystem. Das kommt mit dem Altera BSP schon mit.
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
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:
1 | . |
2 | 930: dfc01317 ldw ra,76(sp) |
3 | 934: dc001217 ldw r16,72(sp) |
4 | 938: dc401117 ldw r17,68(sp) |
5 | 93c: dc801017 ldw r18,64(sp) |
6 | 940: dcc00f17 ldw r19,60(sp) |
7 | 944: dec01404 addi sp,sp,80 |
8 | 948: f800283a ret |
9 | 94c: d0a02903 ldbu r2,-32604(gp) |
10 | 950: defff504 addi sp,sp,-44 |
11 | 954: df000915 stw fp,36(sp) |
12 | 958: dc400715 stw r17,28(sp) |
13 | 95c: dd000415 stw r20,16(sp) |
14 | 960: dd800215 stw r22,8(sp) |
15 | 964: ddc00115 stw r23,4(sp) |
16 | 968: dfc00a15 stw ra,40(sp) |
17 | 96c: dc000815 stw r16,32(sp) |
18 | 970: dc800615 stw r18,24(sp) |
19 | 974: dcc00515 stw r19,20(sp) |
20 | 978: dd400315 stw r21,12(sp) |
21 | 97c: 2039883a mov fp,r4 |
22 | 980: d8000015 stw zero,0(sp) |
23 | 984: 05800044 movi r22,1 |
24 | 988: 0029883a mov r20,zero |
25 | 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
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?
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
Danke WK. Leider kann ich beim MiniPro die "Taktrate" nicht beeinflussen. Der macht wie er lustig ist :-/
Angehängte Dateien:
-
altera_adv.jpg
80 KB
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?
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.