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.
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.
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.
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.
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.
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.
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.
>Ich möchte keine Diskussion über eine Kopierschutz anfangen, ich will >ihn haben und damit gut. ist der S3an denn überhaupt sicher ?
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.
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.
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?
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.