mikrocontroller.net

Forum: FPGA, VHDL & Co. Flash Fpgas und Selbstprogrammierung


Autor: Alfredo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hat schon mal einer mit dem Spartan 3an gearbeitet. Mich würde 
interessieren ob er in der Lage ist sozusagen als Bootloader zu arbeiten 
um Flash Updates durchzuführen. Zusätzlich interessiert mich ob man dann 
z.B. eine AES Verschlüsselung realisieren könnte, sprich ob er in der 
Lage ist sich selbst zu programmieren.

Ich möchte keine Diskussion über eine Kopierschutz anfangen, ich will 
ihn haben und damit gut.

Autor: flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versionsnummer ist eh drin. Ich hab damit sowieso kein Problem, das 
Golden Image wird nur im Labor ausgetauscht. Wozu sollte man das auch 
updaten. Was genau der Threadersteller vorhat, hab ich aber noch nicht 
so ganz kapiert, muss ich zugeben. Vielleicht sagt er mal noch was dazu.

Autor: Silvia A. (silvia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich möchte keine Diskussion über eine Kopierschutz anfangen, ich will
>ihn haben und damit gut.

ist der S3an denn überhaupt sicher ?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Silvia A. schrieb:
> ist der S3an denn überhaupt sicher ?

Nicht wirklich. Man kann höchstens die Device DNA auslesen und die 
überprüfen. Ansonsten ist das interne SPI Flash jederzeit auslesebar per 
JTAG.

Autor: Alfredo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alfredo schrieb:
> Das stimmt glaube ich so nicht, im Datenblatt stehen safe Methoden die
> ein erneutes Auslesen abschalten und nur eine Neubeschreibung zulassen.
> Beim AN.

Wo hast du das gefunden? Im Configuration User Guide finde ich nix 
derartiges. Nur die Sache mit der Device DNA. Oder meinst du das 
Dekativieren des Readback der Config aus dem FPGA selbst?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.