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.
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.
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
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:
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.
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.
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...
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.
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?
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.
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?
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...
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.
[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.
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
