Zynq7, warum fsbl_flash.elf und fsbl.elf

Nachdem ich jetzt einige damit verbracht habe mich mit den Zynq7 auseinander zu setzen wollte ich mir hier jetzt einmal eine der wichtigsten Erkenntnisse der vergangen Tage notieren: Den Grund warum es fsbl_flash.elf und fsbl.elf gibt

Wer schon mal mit FPGAs gearbeitet hat, ist daran gewöhnt einen Code in VHDL oder Verilog zu schreiben, zu kompilieren und zu programmieren. Den Rest erledigt das FPGA innerhalb seiner definierten Routinen. Nicht so bei den Zynqs.

Die Zynqs von Xilinx bringen, fest integriert, Arm-Prozessoren mit. Die Besonderheit ist, dass diese das FPGA erst richtig initialisieren und die Clocks freischalten müssen. Deshalb ist es unerlässlich aus dem Kompilierten Hardware-Teil den entsprechenden Software-Teil zu kompilieren und auf das Gerät zu bringen.

Um den ARM-Core zum laufen zu bringen wird ein erster Bootloader benötigt, der FSBL (first stage boot loader). Dieser wird in der Regel von einem SPI-Flashspeicher gelesen und stößt dann, je nach Konfiguration, weitere Loader an, die dann z.B. ein OS starten oder Baremetal laufen.

Ab jetzt setze ich voraus dass zumindest schon mal ein Tutorial oder ein HowTo-Example für Zynqs als Kenntnis vorraus.

Nachdem ich mir verschiedene Boards angesehen habe und mich letztendlich für eines entschieden habe, ging es für mich darum ein TestProjekt von 0 aufzusetzen und das FPGA Standalone zum laufen zu bringen. Das Beispiel des Herstellers hat nahezu auf Anhieb geklappt, nur mit Vivado und Vitis gab es ein paar anfängliche Schwierigkeiten, die zum Großteil an meiner Unkenntnis lagen. So ist es bei Vivado wichtig dass das Board-Design letztendlich von einer Wrapper-VHDL includiert wird, da ansonsten das FPGA nicht kompiliert werden kann.

Der Anfang macht Vivado, damit wird der Prozessor des Zynqs durch dessen IP eingestellt eingestellt und mit externen Anschlüssen verbunden. Ein minimalistisches Beispiel könnt ihr hier sehen. Im Anschluss wird die Hardware exportiert und in ein Paket gepackt welches dann von Vitis weiter verarbeitet werden kann. Hier sind wir dann im Programmier-Teil des FPGAs.

Die FSBLs werden mit Vitis kompiliert und werden mit dem Platform-Projekt angelegt. Wer, wie ich, das Glück hat ein vollintegriertes Board mit JTAG und allem zu haben kann hier schnell mit den Standarteinstellungen weiter kommen. Wenn dann die erste Beispiel-Applikation kompiliert wurde, kann man mit Debug relativ einfach direkt auf der Harware debuggen, da der Debugger sich um das Bootloading kümmert. Schwieriger wird es wenn das Programm dauerhaft auf dem FPGA laufen soll, dann muss das Programm entweder in den Flashspeicher oder auf eine SD-Karte geschrieben werden.

Jetzt sind wir bei den FSBL angekommen. Eines der größten Hürden für mich im Verständnis des Ablaufs vom Flashen in Vitis war, dass es 2 FSBLs benötigt. In diesem Fall war es der fsbl_flash.elf zum flashen auf den SPI-Flash und dann den fsbl.elf um zu booten. Diese beiden unterscheiden sich ziemlich stark, da der erste (fsbl_flash) im JTAG-Modus booten muss um Daten auf das SPI schreiben zu können, und der zweite (fsbl) im gewünschten Modus, z.B. SPI oder SD-Karte, starten muss. Für den JTAG-Modus kann man einfach den Standard Bootloader von Vitis nehmen und Hardcodiert in den den JTAG-Modus schicken. Der zweite ist deutlich wichtiger, da dieser die Intelligenz zum starten besitzen muss. Allerdings müssen beide mit dem richtigen Bitstream für die Hardware (Vivado) laufen, da sonst nicht auf die jeweiligen Speicher zugegriffen werden kann.