Hallo, für mein Praktikum benötige ich ein „fallback“ rekonfigurations Design für ein Spartan 6. Auf dem Board ist ein externes SPI Flash von Micron M25P16 verbaut. Ein externer Trigger soll mir den Fallback auslösen und ein „Golden Image“ starten. Leider bin ich etwas erschlagen wie ich das anpacken soll. Ich habe mir im Xilinx User Guide UG380 den Abschnitt „Reconfiguration and MultiBoot“ durchgelesen. Wenn ich das recht verstehe brauche ich ein „header image“ die Startkonfiguartion als auch ein „golden Image“, das bei einem bestimmten Triggerimpuls ausgelöst werden soll. Wie erstelle ich ein solches file? Folgendes hab ich noch gefunden: http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/pim_p_creating_prom_file_spi_multiboot.htm Kann mir jemand der das schon mal gemacht hat schrittweise in der richtigen Reihenfolge erklären wie ich so ein File für den Flash Speicher erstelle. Größten Dank.
Du musst lediglich bei Bitgen die Optionen für MultiBoot setzen. Bitgen erzeugt dann den Header. Aber Fallback auf externen Trigger hin benötigt das Icap Modul im Design denn normalerweise macht der Fallback nur wenn das "Update Image" nicht geladen werden kann. Die genauen Einstellungen für BitGen kann ich morgen mal posten...
Hallo, schomal vielen Dank für die Antwort. Also bitgen finde ich im Impact? Wenn du mir die Einstellungen posten oder eine Anleitung könntest wäre super :-) Vielen vielen Dank.
Angehängte Dateien:
-
Golden.png
62 KB -
Update.png
63 KB
Nee, bitgen ist in ISE: Generate Programming File. Dann dort auf Process properties und dann advanved erst mal einschalten und bei Configuration options kannst du das dann einstellen. Du musst auch das ganze zwei mal machen, einmal für das "Golden Image" was den Header beinhaltet und einmal für das "Update Image" und die Images dann in Impact beim Prom File erstellen zusammen führen. Das 0x0B an der Start Adresse für das Update Image ist der SPI Read Befehl (siehe Configuration User Guide). Achso, beim Update Image musst du noch "-g next_config_register_write:Disable" bei "other bitgen command line options" einstellen, sonst macht der sofort einen Fallback auf das Golden Image.
Angehängte Dateien:
-
update_image.png
40 KB
Hallo, vielen Dank für deine Antwort, das hat mir schon sehr weitergeholfen. Das golden image habe ich erzeugt, jedoch lässt sich in "other bitgen command line options" nichts einstellen, siehe Anhang. Oder in ich ggf. im falschen Menü? Danke für die Hilfe.
noch ein Nachtrag, passt die Adresse für das golden image 0x00000000 unter -g golden_config_addr: MultiBoot: Starting Address for Golden Configuration, kann ich die nicht auch beliebig wählen? Danke.
christian m. schrieb: > jedoch lässt sich in "other bitgen > command line options" nichts einstellen, siehe Anhang. Rechts neben dem Feld, also unter den Checkboxen geht das bei mir. Die Startadresse für das Golden Image kannst frei wählen, ebenso die für das Update Image. Wenn das Golden an die 0 kommen soll, addiert BitGen sogar automatisch die 0x44 Byte sfür das Header Image drauf.
Hallo, vielen Dank für dein super Teaching. Das golden image habe ich erstellt, jetzt wollte ich das update_image erstellen, jedoch lässt sich die bit file mit der Einstellung "-g next_config_register_write:Disable" s. Anhang nur mit einem Warning Sign vor "Generate Programming File" erstellen. Ich denke die option "-g next_config_register_write" müsste doch an einer festen Stelle stehen wo ich das Disable einstellen kann, aber ich wüsste nicht wo ich es sonst eintragen kann. Könntest du mir auch noch kurz bei der Prom file Erstellung helfen. Wie bekomme ich die bit files zusammen. Mache ich das über den PROM File formater? Vielen vielen Dank
Ich habe das folgende Tutorial gefunden: http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pim_p_creating_prom_file_bpi_multiboot.htm Ich probiere es jetzt mal aus.
Ok, soweit so gut SPI Flah Mutiboot ausgewählt,nur wie würde ich die beiden image files golden und update einbinden. Auch lässt sich unter File Format nur MCS auswählen kein hex Format?
Also bei mir steht das an der Stelle, das klappt dann auch. MCS ist übrigens Intel Hex. Wenn du andere Formate wie bin brauchst, musst du PromGen in der Kommandozeile nutzen. dann kannst du mit -p das Format auswählen. Gerade für solche Sachen wie die MultiBoot Images nutzt man besser die Command Line, da kann man eien Batch Datei machen, die die beiden Bit-Files erzeugt und dann zu einem Flash File zusammen fügt. Das sieht dann etwa so aus:
1 | promgen -w -p mcs -u 0 golden.bit -u 400000 update.bit -spi -s 65536 -o FlashFile.mcs |
Ansonsten halt über Impact, MultiBoot, dann 2 Revisions einstellen und dann beide Files hinzufügen, beim 2. halt die richtige Adresse eingeben. Achja, die Warnung ist richtig so, denn genau das willst du ja erreichen. Denn beim Update Image darf natürlich keine Startadresse für das nächste Image drin stehen und auch kein IPROG Kommando.
:
Bearbeitet durch User
Super, hat alles soweit geklappt , danke nochmals :-) So, nun wollte ich zu meinem bestehenden xilinx.ipf Project noch die erstellte mcs prom File hinzufügen, jedoch wird in dem Menü nicht mein verwendetes SPI Flash M25P16 angezeigt...?
Da musst du im Boundary Scan Modus erst mal die JTAG Kette erkennen lassen und dann erscheint über dem Spartan so ein kleines blaues Schild (Add SPI/BPI Flash), da doppelklicken und das MCS File hinzufügen und dann den Flash aus der Liste auswählen.
Angehängte Dateien:
-
update_image_general.png
140 KB -
update_image_configuration.png
52 KB -
golden_image_configuration.png
52 KB -
golden_image_general.png
34 KB
Hallo, ich habe heute alles nochmals durchprobiert, jedoch funktioniert das ganze noch nicht. Die Bitfiles sind alle funktionsfähig, d.h. der FPGA lässt sich mit den bit files konfigurieren. Auch lässt ich eine promfile durch den Kommandozeilenbefehl promgen -w -p mcs -u 0 golden.bit -u 400000 update.bit -spi -s 65536 -o Flash.mcs generieren. Habe meine ISE Einstellungen geposted, ggf. hier etwas nicht richtig. Jedoch wird der FPGA nicht aus dem Flash konfiguriert. Vielen Dank.
Also das müsste klappen, so hab ichs doch auch. Bootet der überhaupt aus dem Flash? Hast du mal SingleBoot probiert? UNd ist der Flash denn 64MBit groß? Das war ja als Beispiel nur bei mir... Achso, gib mal als Startadresse für das Golden Image die 0 ein, das korrigiert der selber...
:
Bearbeitet durch User
Hallo, danke für deine schnelle Antwort. Ich habe versucht ein anderes funktionierendes Image auf den Flash zu packen, das läuft einwandfrei (allerdings kein multiboot Image ;-) ). Das neue Flash ist 32 Mb groß. Habs mit: promgen -w -p mcs -u 0 golden.bit -u 400000 update.bit -spi -s 32768 -o FlashFile.mcs probiert, FPGA wird nicht konfiguriert. Der FPGA soll sich bei einem CRC Fehler aus den Flash neu laden. Vielen Dank.
Irgendetwas muss falsch gesetzt sein, die Testfile wird ja auch vom Flash in den FPGA geladen (single boot). Ich bin ratlos.
Ich schau morgen auf Arbeit nochmal, bei uns klappt das. Nur zur Sicherheit: Encryption ist aus, oder? Das schließt sich nämlich gegenseitig aus. Bei einem 32 Mbit Flash wäre die Mitte aber bei 0x200000 oder? Passt denn das beides überhaupt rein?
Also außer dass die Startadresse 0x400000 nicht zu einem 32 MBit Flash passt, sollte der Rest stimmen.
Hallo, habs grad nochmals kontrolliert Encryption ist aus. Als Startadresse für das golden Image habe ich das im -g next_config_addr: 0xB200000 gesetzt. Reinpassen tut es auch. Vielen Dank für die Hilfe.
Du meinst das Update Image? Das Golden Image muss an Adresse 0 stehen. Und im Promgen muss dann die 200000 auch auftauchen, damit das Update File an der richtigen Stelle steht. Eventuell nochmal hier schauen: http://www.xilinx.com/support/documentation/boards_and_kits/xtp059.pdf oder im Xilinx Forum, da gibts einige Threads.
Vielen Dank für deine Antworten und super Hilfe. Ich kanns mir auch nicht erklären, werd in letzter Konsequenz mal den Flash austauschen.
So, hab mein Flash getauscht und siehe da es läuft...super,super, hätte ich gleich machen sollen. Zumindest wird jetzt das golden image angezeigt. Kann man das irgendwie testen, um zu sehen wie update und golden Image abwechselnd bootet?
Hm, aber eigentlich sollte doch das Update Image starten und das Golden nur wenn das Update Image defekt ist. Da stimmt doch was nicht. Ich hab das dann getestet indem ich das Firmware Update abgebrochen habe, dann bootet beim nächsten Mal das Golden Image. Sieht man auch am längeren Boot-Vorgang. Ansonsten kannst du auch per JTAG die Status-Register auslesen über Impact, dann kannst du das sehen.
Die Reihenfolge stimmt auch promgen -w -p mcs -u 0 golden.bit -u 200000 update.bit -spi -s 32768 -o FlashFile.mcs, also golden an 0 und update an 2. Komisch das immer das golden image gebootet wird? Wie hast du das firmware update abgebrochen...Progstecker ziehen?
Wenn das Golden sofort gebootet wird, stimmt was am Golden Image nicht. Wenn der Fallback sofort erfolgt, stimmt was am Update Image nicht. Kannst du wie gesagt über Impact durch Auslesen der Statusregister herausfinden. Für den einfachsten Test hab ich beim Programmieren den Strom ausgeschaltet. Dazu hab ich mir ein MCS File gemacht, was nur das Update Image enthält. Wir haben das ja drin, um im Feld gefahrlos Updates machen zu können, mit der Nutzersoftware lässt sich dann natürlich ein Fallback besser herbeiführen.
Das klappt, wenn ich das externe konfigurieren des FPGAs über Jtag mache und unterbreche, wird das golden Image geladen. Eigentlich würde es so auch reichen quasi externe Konfiguration schlägt fehl, dann golden Image laden. Dann müsste ich ja nur eine File wie das Update Image erstellen und mit promgen -w -p mcs -u 0 golden.bit -spi -s 65536 -o FlashFile.mcs eine mcs generieren.
Hm, was soll das ganze dann für einen Sinn haben? Multiboot mit Fallback ist dochnur bei Flash-Boot mit Firmware Update im Feld sinnvoll. Das Golden Image fasst man nicht an, nur das Update Image wird aktualisiert. Wenn beim Update was schief läuft, startet das Golden Image durch den CRC Reboot Trigger und das Gerät ist wieder ansprechbar. Wenn du externe konfig machst, brauchst du den ganzen Quatsch ja nicht, denn dann hast du doch sowieso alles selbst in der Hand.
Das stimmt wohl, da hast du recht. > Wenn das Golden sofort gebootet wird, stimmt was am Golden Image nicht. Also wie gesagt, dass konfigurieren und während dessen abbrechen funktioniert mit dem golden image, d.h. es wird geladen. Nur wenn ich die Versorgung des FPGAs aus- und einschalte wird gleich das golden image gebootet.
Sicher sofort? Das heißt am Header Image ist was falsch, dass er das Iprog Kommando überspringt...schau doch mal in das Bit File, ob das laut Config User Guide richtig drin steht.
Hallo, hier der Auszug aus dem Flash file. 02000000ffffffffffffffffffffffffffffffffaa99556631e1ffff3261000032810b20 32a1004432c10b0032e1000030a10000330121003201005f30a1000e2000200020002000 Das IPROG Kommando wird gesetzt 000E im Anschluss erfolgt NOP 2000. Nach 3261 folgt die Multiboot Start Adresse 000032810b2032a. Ich dachte das wär die Adresse 0x00000000 + 0x44.
Das sollte so stimmen. Laut Tabelle 7.1 im User Guide wird mit 3261 das Low-Word der MultiBoot Adresse geschrieben (0000) und mit 3281 das High-Byte und der SPI Op Code (0B20). Die Reihenfolge ist hier nur anders. Die Startadresse für das Golden Image kommt nach 32A1 da ist auch die 0044 korrekt, weil ja der Header übersprungen wird beim Fallback. Mein Golden Image sieht da genauso aus, bis auf die 400000 als Start-Adresse für das Update Image. Was sagen denn die Status-Register nach dem Booten bei dir?
Angehängte Dateien:
Hallo, bin jetzt mal mit der config_rate auf 16 MB runter. Anbei nochmals meine Einstellungen, ggf. hab ich da was falsch eingestellt. Ach ja, auf dem Board ist ein Spansion Flash S25FL032P verbaut. Die Status-Register kann ich mit Impact nicht auslesen da wir die mcs files nicht mit Impact auf den flash schreiben. Der Spansion (32M) ist in Impact im PROM File Menü nicht auswählbar. Die Reihenfolge: promgen -w -p mcs -u 0 golden.bit -u 200000 update.bit -spi -s 32768 -o FlashFile.mcs stimmt ja auch, oder? Vielen Dank.
Nachtrag: im golden_configuration_options habe ich folgendes falsch eingetragen: golden configuration options: MultiBoot: Starting Address for Next Configuration 0x0B200000. Hab ich ausgebessert.
Die Status-Register des Spartan meine ich, nicht die des Flash. Hast du denn gar keine JTAG Verbindung zum Spartan? Und auf den Screenshots fehlt das SPI Lese Kommando im Update Image, da muss in die Bits 31:24 der nex-confi-addr der Lesebefehl rein, 0x03 oder 0x0B, je nach Flash. Und wieso steht jetzt für da im Update die Startadresse 0x200000 für das Golden Image? Das muss doch 0 oder 0x44 sein. Hier nochmal die Inhalte meiner *.ut Files, wir arbeiten hauptsächlich mit den command line tools. Edit: Achso, hatte schon eher angefangen zu tippen...
:
Bearbeitet durch User
Hallo, danke für deine Antwort. Ich hab exakt die gleichen Einstellungen. Sorry für das durcheinander. Jtag ist mit Spartan 6 verbunden. mcs file generiere über die Kommandozeile promgen...und im Anschluss programmiere ich den Flash mit einem externen Tool via SPI den Flash. Der startet auch, aber halt gleich vom Golden Image. Wenn ich eine bitfile aus meiner mcs file generieren könnte, kann ich versuchen den Flash uber Jtag zu programmieren und dann die Status-Register auslesen. Ggf. liegt es auch am Flash?
Nee, du verstehst mich nicht. Du sollst den JTAG einfach mal dran lassen und normal aus dem Flash Booten lassen. Dann kannst du in Impact die Status-Register des Spartan 6 auslesen. In den BOOTSTS, Status_0 und Status_1 findest du dann Infos über den Bootvorgang, ob CRC Error war, ob Fallback erfolgt ist. usw. Vollkommen unabhängig vom Flash, und das geht auch wenn der FPGA gebootet ist. Einfach im Impact Boundary Scan Modus den Spartan markieren und dann Debug->Read Device Status. Edit: Hast du ICQ? Vielleicht sollten wir dort weiter machen, das ufert ja aus hier...wenn ja, schreib mir mal eine Nachricht hier.
:
Bearbeitet durch User
Hallo, ich hab jetzt das Status Register ausgelesen und die Ausgabe gepostet. Hab leider kein ICQ oder skype müsste ich mir erst einrichten...
Hm, komisch, ich krieg sowohl nach erfolgreichem Boot des Update Image als auch nach dem Fallback das hier:
1 | '1': Reading bootsts register contents... |
2 | [0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED : 1 |
3 | [1] FALLBACK_0 - FALLBACK RECONFIGURATION ATTEMPT DETECTED : 1 |
4 | [2] RESERVED : 1 |
5 | [3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR : 1 |
6 | [4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR : 0 |
7 | [5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR : 1 |
8 | [6] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED : 1 |
9 | [7] FALLBACK_1 - FALLBACK RECONFIGURATION ATTEMPT DETECTED : 1 |
10 | [8] RESERVED : 0 |
11 | [9] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR : 1 |
12 | [10] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR : 1 |
13 | [11] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR : 1 |
14 | [12] STRIKE CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 1 |
15 | [13] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 1 |
16 | [14] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 0 |
17 | [15] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 1 |
18 | '1': Reading status register contents... |
19 | [0] CRC ERROR : 1 |
20 | [1] IDCODE ERROR : 1 |
21 | [2] DCM LOCK STATUS : 1 |
22 | [3] GTS_CFG_B STATUS : 1 |
23 | [4] GWE STATUS : 0 |
24 | [5] GHIGH STATUS : 1 |
25 | [6] DECRYPTION ERROR : 1 |
26 | [7] DECRYPTOR ENABLE : 1 |
27 | [8] HSWAPEN PIN : 0 |
28 | [9] MODE PIN M[0] : 1 |
29 | [10] MODE PIN M[1] : 1 |
30 | [11] RESERVED : 1 |
31 | [12] INIT_B PIN : 1 |
32 | [13] DONE PIN : 1 |
33 | [14] SUSPEND STATUS : 0 |
34 | [15] FALLBACK STATUS : 1 |
Obwohl das nicht mit dem Config User Guide übereinstimmt. Sehr seltsam. FPGA hat aber definitiv von 400000 gebootet, hab extra nochmal schnell ein FW-Update gemacht. Beim zweiten Test dann während Update Strom ausgeschaltet, dann bootet die alte Firmware Version. Komisch, dass die Status-Register nicht stimmen. Langsam gehen mir die Ideen aus. Da musst du wohl mal im Xilinx Forum anfragen.
:
Bearbeitet durch User
Hallo, also, das geht bei mir auch wenn ich den Programmiervorgang unterbreche bootet der spartan mit dem golden image, das würde ja passen, nur das update image wird nie gebootet, das müsste ja der default boot sein. Na ja, ich weiß auch nicht mehr weiter...ich wende mich mal an Xilinx. Ich hoffe die können mir weiter helfen ;-) Poste einfach die Lösung wenn ich sie hab. Tausend Dank für deinen super Support.
@christian m.: Ich weiß ja nicht, ob sich Dein Problem inzwischen gelöst hat. Ich habe mich auch gerade mit dem Fallback-Boot per SPI rumgeplagt. Bei mir wird generell ein Header erzeugt, auch für das Multiboot/Update-Image. Und das, obwohl ich die Option "-g next_config_register_write:Disable" zum Generieren benutze. Wenn ich die Startadresse im Fallback-Header um 0x44 erhöhe, klappt es. Damit wird der 'falsche' Header übersprungen. Das Lesekommando für den SPI-Flash (bei mir 0x6b für fast quad read) wird inzwischen automatisch ergänzt. In älteren ISE-Versionen gab es da wohl noch Probleme. Ich verwende die Version 14.6. Duke
Ich möchte auch sowas implementieren. Kann man davon ausgehen, dass das zuverlässig funktioniert?
Bei uns funktioniert das zuverlässig, wenn man alles richtig einstellt.
Ok, das klingt ja zufriedenstellend. Darf ich Dich zu gegebener Zeit mal ansprechen, wenn ich damit soweit bin?
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.