Ich hab da ein kleines Verständnisproblem beim Fallback Multiboot am Virtex 5. Und zwar entwickeln wir gerade eine Hardware mit dem V5, und der soll aus einem SPI Flash booten. Neue Firmware soll dann über das Design selbst in den SPI Flash kommen. Nun gibts ja das an sich nette Feature des Fallback, falls das Konfig-Image defekt ist, wird ein "save bitstream" geladen. Aber irgendwie geht aus dem Configuration User Guide für mich nicht hervor, wie man das beim SPI Flash automatisiert. Im Abschnitt "IPROG embedded in the bitstream" steht, man soll im 1. (save) Bitstream, der auf Adresse 0 sitzt, die Warm Boot Start Adresse des 2. Bitstream eintragen und dahinter das IPROG Kommando. Der FPGA würde dann den 2. Bitstream laden, und falls das nicht klappt, wieder zum 1. Bitstream zurück fallen. Hm, aber dann hängt der doch in einer Endlosschleife, oder? Wenn der wie im "Fallback Example" beschrieben, die Startadresse wieder auf 0 setzt, ist doch nichts erreicht, denn dann kommt der ja wieder an die Warm Boot Start Adresse und das IPROG Kommando. Irgendwie scheint das seltsam. Hat das schon mal jemand gemacht? Oder hat jemand ein ML501 oder ähnliches und könnte das mal testen?
Steht die Antwort auf deine Frage nicht unter "Fallback Multiboot"? Die Pins RS0,RS1 bestimmen ja den gewünschten (und evtl. defekten) Bitstream. Wird bei dessen Konfiguration ein Fehler festgestellt, dann wird doch RS0,RS1 neu gesetzt (d.h. gelöscht)!? Ich hab dieses Feature nur mal zum Spass probiert und es lief ohne Probleme wie beschrieben (glaube unter ISE 11.?). Viel Spass
Prinzipiell ja, aber im SPI Modus sind die RS Pins nicht benutzt, steht da mehrfach drin. Ich habe aber eben den entscheidenden Satz auf Seite 154 gefunden:
1 | "Embedded IPROG (see “IPROG Embedded in the Bitstream”) is ignored during fallback reconfiguration." |
Das hab ich ganz übersehen in den letzten Tagen. Schlimm. Aber damit wird die Sache logisch. Was ich noch nicht gefunden habe, ist eine Möglichkeit, die Startadresse des 2. Images automatisch durch BitGen in das 1. Image eintragen zu lassen. Das geht irgendwie nur beim Spartan 3A und Spartan 6 über -g next_config_addr. Beim Virtex 5 muss man das offernbar wie im UG auf Seite 161 beschrieben selbst in den (safe) BitStream eintragen. Die beiden 32 Bit Felder sind im MCS-File vorhanden aber leer.
Noch schlimmer: Mein Board hat ja BPI-Flash, aber ich habe damit schon seit Monaten nicht mehr gespielt; konnte mich nur noch grob an RS0/RS1 erinnert. Unter SPI funktionierts ja ein wenig anders. Invariant ist aber, dass der Erste Bitstream selektiert wird (BPI: RS0/RS1, SPI: IPROG-Command) und im Fehlerfall auf den sicheren umgeschaltet wird (BPI: RS0,RS1=0, IPROG-Command ignorieren). Was mich aber noch interessiert: Warum Schreibst du den zweiten Bitstream nicht immer an die selbe Stelle. Das würde dir das Ändern der IPROG-Sequenz ersparen.
Ich werde den 2. BitStream dann schon immer an die selbe Stelle schreiben, klar. Aber gerade in der Entwicklungsphase ändert sich das "Golden Image" bestimmt auch öfters, da muss man jedes Mal im Bit-File die Adresse setzen und den IPROG Befehl reinfummeln. Geht schon, schöner wäre aber eine BitGen Option wie beim Spartan. Aber prinzipiell ist es erst mal klar jetzt. Beim Power-On wird immer der 1. Bitstream ab Adresse 0 im Flash geladen. Ist dort eine WBSTAR Adresse und das IPROG Kommando eingetragen, springt der Virtex an die Adresse und versucht das 2. Image zu laden. Wenn das nicht klappt, wird wieder bei 0 angefangen und das IPROG ignoriert. Somit sollte die Sache ja klappen und ein sicheres Update im Feld möglich sein. Sehr schön.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.