Spartan 6 - Boot File Format SPI Flash

[X- R. (x-rocka)]

Moin,

ich werde demnächst ein Board mit Spartan 6, SPI Flash und Controller 
"bearbeiten".
Spartan 6 soll aus dem SPI Flash booten, das FPGA Boot File soll mit dem 
Controller ins SPI Flash geschrieben werden.
Per Impact schiebt man ein mcs-File ins SPI Flash.

Dazu die Frage:
Macht Impact (bzw das FPGA, welches zum schreiben des SPI Flash geladen 
wird) noch irgendwas mit dem mcs-File (bestimmte Zeichen weglassen, da 
sind ne Menge Doppelpunkte und Line Feeds im mcs-File), oder wird das 
1:1 ins Flash geschrieben?

Habe nichts dazu in den entsprechenden Xilinx App-Notes dazu gefunden, 
deswegen gehe ich davon aus, aber vielleicht kann mir das ja jemand 
bestätigen.
:-)

Danke,
X

[Lattice User (Gast)]

Suche nach Intel HEX Format.

[X- R. (x-rocka)]

Lattice User schrieb:
> Suche nach Intel HEX Format.

Äh ja.

Das beantwortet aber nicht die Frage:
Schmeißt man den Format-Overhead bereits beim Schreiben des SPI Flashes 
raus, oder macht der Spartan das beim Booten?

[Thosch (Gast)]

Das MCS-File wird dekodiert und nur die Nutzdaten werden ins Flash 
geschrieben!

MCS = Intel-Hex File

Das MCS-File, welches der Fitter abwirft ist ein
Intel-Hex File mit Type 04 Records für die Page-Adresse.

(Intel-HEX ohne Page-Adress-Records kann nur 64 kiB Nutzdaten)

Entsprechende Algorithmen zur Decodierung finden sich im Netz, oder man 
schreibt sich das anhand der Intel-Hex Format Dukumentation eben selbst.

Achtung: Die Dateien aus der Xilinx ISE sind es meines Wissens bislang 
zwar,
aber das Intel-Hex Format selbst muß nicht zwangsläufig linear 
adressiert sein. Da jede Zeile eine Adresse enthält, können diese auch 
in nicht-aufsteigender Reihenfolge gespeichert sein.
Das korrekte Decodieren einer solchen Datei erfordert also im worst case 
Speicher in der Größe der Nutzdaten. Entweder als random access file auf 
einem Datenträger oder als RAM.

Ein Microcontroller wäre damit ggf. schnell überfordert.

Die MCS-Files von Xilinx werden vermutlich stets linear sein, so
daß das Decodieren keine Probleme bereitet.

Relevant wird die Sache allerdings, wenn man auch noch ausfürhbaren Code 
aus einem Compiler oder Assembler speichern möchte. Die Intel-Hex-Files, 
die ein Compiler rauswirft, sind nämlich oft nichtlinear aufgebaut.
Vor allem speichert ein Compiler normalerweise keine langen Folgen von 
0xFF-Bytes im Intel-Hex File, sondern überspringt die entsprechenden 
Adreßräume.

Gruß,
Thorsten

[X- R. (x-rocka)]

Danke!

Also schiebe ich gleich das Xilinx bin-File ins SPI Flash, dann muss der 
Controller nix dekodieren.

Mich wundert's, dass Impact den Umweg über's mcs/hex File macht.

X

[X- R. (x-rocka)]

Hm, alles andere außer Rohdaten wäre Blödsinn, weiß auch nicht, wie ich 
darauf gekommen bin... aua... bin! Also bin-File, haha! ;-)

[Lattice User (Gast)]

Das .mcs file ist für 3rd Party Programmer gedacht.

[Christian R. (supachris)]

Welches Bin-File? Das FPGA Bit-File ist nicht das File, was rauskommen 
würde, wenn man das MCS mit hex2bin zurückwandelt. Im Bit-File sind auch 
jede Menge zusätzliche Informationen drin. Im Flash dagegen gibts dann 
so Sachen wie das Syncword (AA995566) am Anfang usw. Du kannst aber mit 
PromGen statt dem mcs File gleich ein Bin-File erzeugen lassen. Das ist 
aber was anderes als das Bit-File. Und das kannst du dann nach belieben 
auf den Flash schreiben.

[X- R. (x-rocka)]

Ich meine das bin File, was sich gleich in ISE mit "generate prog file" 
erzeugen läßt.
Hab's mir gerade noch mal angekuckt, bit-File hat zusätzlichen Header 
mit Infos zB zum Device.

[Christian R. (supachris)]

Das passt aber auch nicht:

Note:  This configuration file is not intended for download to a PROM. 
For more information about generating a PROM file, see Generating a 
Target PROM or ACE File.

Du musst nachher noch PromGen bemühen.

[X- R. (x-rocka)]

Christian R. schrieb:
> Das passt aber auch nicht:
>
> Note:  This configuration file is not intended for download to a PROM.
> For more information about generating a PROM file, see Generating a
> Target PROM or ACE File.
>
> Du musst nachher noch PromGen bemühen.

Ah, ja, jetzt erinnere ich mich wieder! Vor Jahren hatte ich schon mal 
ein Spartan 3 per Controller gebootet (aber eben nicht diesen Self-Boot 
aus SPI-Flash).
Der Unterschied vom PromGen BIN-File zum ISE-BIN (=bit-header) File: 
"gespiegelte" Nibbles in jedem Byte.
bit: AA (1010.1010) => bin: 55 (0101.0101)
bit: E0 (1110.0000) => bin: 07 (0000.0111)
etcpp

Danke für den Hinweis!
Ich werde aber doch nochmal nen Xilinx FAE anfunken, was denn nun ins 
SPI-Flash muss.

[ich (Gast)]

Ich hatte das ganz einfach gelöst: Ich hab in der Aplication note 
geschaut wie viele Bytes die Konfiguration genau hat und hab mit das mit 
den erzeugten Files verglichen.
Ich meinete es war dann das *.bit-File.
Aber aufpassen: Beim S3E war es so dass alle Bits innerhalb eines Bytes 
gedreht waren, also MSB wird LSB.

[X- R. (x-rocka)]

Jau, ich vermute auch, dass ein bit-swapped bit-File benötigt wird.

[X- R. (x-rocka)]

Ah, habe jetzt in xapp974 gefunden, dass für SPI Flashes die Daten nicht 
bit-swapped sein sollen.

[Christian R. (supachris)]

Naja, im Bit-File steht noch mehr drin. Im Flash dagegen wieder anderes 
am Anfang. Worin besteht das Problem, PromGen aufzurufen und ein bin 
File ausspucken zu lassen?