Flash Fpgas und Selbstprogrammierung

Ich denke nicht das das geht, die Spartan3 reihe kann man nicht 
teilweise beschreiben. Entweder ganz oder gar nicht. Ich hatte auch mal 
mit den 3an geliebäugelt. Leider gibt es den nur als bga

Spartan-3A(N) kann Multiboot. Aber der Begriff Bootloader passt nicht. 
Du speicherts 2 Bitstreams im Flash, die beide die Updatefunktionalitaet 
haben. Stream 1 ist das Arbeitspferd und wird bei Bedarf neu 
geschrieben. Wenn dabei etwas schief geht, dann faellt der FPGA beim 
Booten auf das "Golden Image" zurueck und erlaubt trotzdem das 
Arbeitsimage  neu zu flashen. Im Prinzip kann der Updatemechanismus auch 
das "golden image" erneuern, wenn da was schiefgeht waere ja noch das 
Arbeitsmage da, aber das beschreibt Xilinx nicht.

Christian R. schrieb:
> Uwe Bonnes schrieb:
>> Im Prinzip kann der Updatemechanismus auch
>> das "golden image" erneuern, wenn da was schiefgeht waere ja noch das
>> Arbeitsmage da, aber das beschreibt Xilinx nicht.
>
> Das sollte man eher nicht machen. Denn soweit ich das verstanden habe,
> kennt die Fallback-Logik nur den Weg zurück auf das Image an Adresse 0,
> nicht aber an die Startadresse des 2. Images. Das ginge höchstens, wenn
> man den Anfang des Golden-Image Bitstreams entweder nicht überschreibt,
> oder wenn der trotz Panne beim Flashen noch unverändert drin ist.

Man kann das Golden Image schon updaten, sollte es nur nicht zusammen 
mit dem Primary in einem Rutsch tun.

Folgende Regeln sind dafür sinvoll:
1. Der Updater darf nur ein Image gleichzeitig updaten.
2. Das Golden Image darf nur upgedated werden wenn sichergestellt ist 
dass das Primary Image das aktive ist (wie ist Applikationsspezifisch, 
z.B. ein Versionsregister).

Ich habe gerade an einem Updater für mein Design und versuche da im Kopf 
allerlei Katastrophenscenarien durchzuspielen.

Christian R. schrieb:
> Lattice User schrieb:
>> Das Golden Image darf nur upgedated werden wenn sichergestellt ist
>> dass das Primary Image das aktive ist (wie ist Applikationsspezifisch,
>> z.B. ein Versionsregister).
>
> Genau das ist kaum machbar. Höchstens bei BPI Flash mit den RS Bits am
> FPGA. So gehts jedenfalls beim Virtex 5. Beim SPI Flash aber bestimmt
> der Inhalt im Golden Image, das auf Adresse 0 im Flash ist, welches
> Image gebootet werden soll. Da steht dann die Startadresse und ein
> Sprungbefehl drin. Wird das Image gleich da vorn beschädigt beim
> Transfer oder beim Flashen geht nix mehr. Ich mach mir da für den Virtex
> 5 auch gerade das Konzept. Allerdings werden wir wohl das golden Image
> nicht antasten, und wenn dann nur im Labor, nicht im Feld.

Zu Erkennen welches Image aktiv ist sollte kein Problem sein, z.B. 
Versionsregister IM Design.

Dein Problem ist dass du das Goldenimage im Spartan3 nicht ohne 
Restrisiko updaten kannst, da es den Sprungbefehl auf das primäre Image 
enthält. Das Problem habe ich mit dem ECP3 von Lattice zum Glück nicht, 
da wird das Goldenimage wirklich nur gebraucht wenn das Primärimage 
kaput ist.

Vielleicht kannst du ja sicherstellen, dass der erste Block des 
Goldenimages sich nie ändert. Mal das Imageformat genau anschauen, ob es 
da sowas wie nops gibt die man Einfügen könnte.

Das stimmt glaube ich so nicht, im Datenblatt stehen safe Methoden die 
ein erneutes Auslesen abschalten und nur eine Neubeschreibung zulassen. 
Beim AN.
Zudem kann ein Code 1 mal eingeschrieben werden, den das Programm 
überprüft dann läuft oder nicht. Also ein Schutz das der Code nicht auf 
einen Typgleichen FPGA läuft.
Wer aber das Basisprogram entschlüsseln kann macht aber alle diese 
Methoden uninteressant, sofern man beim Updaten mitloggt.

Beim AN ist der Flash quasi doppelt vorhanden. Man könnte also (so 
stelle ich mir das  vor wenn es geht) erst ein ein Programm aufladen, 
welches sich im nächsten Schritt das eigendliche Programm einläd über 
eine Schnittstelle. Das wird dekodiert, in den zweiten Flash geschrieben 
und danach wird umgeschaltet. Statt der Decodierlogic und der 
Schnittstelle ist das das eigendliche Programm vorhanden.
Sollte relativ sicher sein. Und wirtschaftlich vertretbar als einfacher 
Schutz gegen die einfachen Atacken.