Démarrage et images de boot
Suivre les étapes depuis la BootROM, construire une image BOOT.BIN et choisir le rôle du FSBL, de l'ATF, de U-Boot et du bitstream.
Du JTAG au démarrage autonome
Pendant le développement, l'ingénieur peut utiliser Vitis pour initialiser la carte et charger un fichier ELF par JTAG. Une mémoire non volatile, comme une carte SD ou une Flash QSPI, conserve au contraire les données hors tension et permet un démarrage sans poste de développement.
Le démarrage commence après le Power On Reset. Le mode de boot sélectionne la source, par exemple QSPI, carte SD, eMMC ou JTAG selon la famille et la carte.
Les étapes du démarrage
La BootROM est un petit programme gravé dans le composant. Exécutée à l'étape 0, elle initialise le minimum nécessaire, lit l'en-tête de l'image puis charge le premier chargeur dans une mémoire locale.
Sur Zynq-7000, le First Stage Boot Loader, ou FSBL, est le premier programme modifiable. Il initialise le PS à partir des données générées par Vivado, peut configurer la PL et charge les partitions suivantes.
Sur Zynq UltraScale+ MPSoC, le flot ajoute les fonctions de la Platform Management Unit et de la Configuration Security Unit. Une pile Linux utilise généralement plusieurs partitions.

| Partition | Rôle courant |
|---|---|
| FSBL | Initialisation du PS et premier chargement |
| PMU firmware | Gestion de plateforme sur ZynqMP |
| Bitstream | Configuration de la PL |
| Arm Trusted Firmware | Passage vers les niveaux d'exception adaptés |
| U-Boot | Second Stage Boot Loader et choix de la source système |
| Image Linux | Noyau, arbre de périphériques et système de fichiers |
| Application ELF | Programme standalone |
Construire BOOT.BIN
Bootgen assemble les partitions selon un fichier BIF. L'ordre doit correspondre au flot de la cible.
the_ROM_image:
{
[bootloader] fsbl.elf
[pmufw_image] pmufw.elf
[destination_device=pl] design.bit
[destination_cpu=a53-0, exception_level=el-3] bl31.elf
[destination_cpu=a53-0, exception_level=el-2] u-boot.elf
}Un Zynq-7000 standalone utilise une description plus courte. Il contient typiquement le FSBL, le bitstream et l'ELF de l'application.
Le bitstream n'est nécessaire que si l'application utilise la PL. Son placement doit précéder l'application si celle-ci accède immédiatement à une IP AXI de la PL.
Ce que fait réellement le FSBL
Le FSBL exécute les séquences d'initialisation produites à partir de la plateforme matérielle. Elles configurent les PLL, les horloges, la DDR, les MIO et certains resets. Il copie ensuite les partitions vers leur destination et transmet l'exécution.
Un programme de validation simple désactive le cache de données, attend l'initialisation de l'UART puis affiche un message. Ce test confirme le démarrage avant d'ajouter un système plus complexe.
int main(void)
{
Xil_DCacheDisable();
delay(1U);
xil_printf("Boot application started\r\n");
return 0;
}Le rôle de U-Boot
Le FSBL s'exécute dans une mémoire locale limitée. U-Boot apporte des pilotes et des commandes plus riches. Il peut lire un système de fichiers, charger depuis le réseau, modifier les arguments du noyau et choisir une image de secours.
Un SSBL n'est pas obligatoire pour une petite application standalone. Il devient normal pour Linux et pour une stratégie de mise à jour robuste.
Diagnostiquer un échec de boot
Commencer avec l'image minimale. Observer le port série dès le reset. Vérifier le mode de boot et le support utilisé. Vérifier ensuite l'ordre des partitions, leurs adresses de destination et la compatibilité entre le XSA, le FSBL, le bitstream et l'application.
Une absence totale de message peut venir de la BootROM, de la source de boot, de l'UART ou du FSBL. Un message du FSBL suivi d'un arrêt pointe plutôt vers une partition suivante, une DDR non initialisée ou une adresse incorrecte.
Sécurité et production
Les composants Zynq peuvent authentifier et chiffrer des partitions selon la famille. Une chaîne de démarrage sécurisée repose sur une racine de confiance et une politique de clés. Elle doit être conçue avant la production. Ajouter une signature à la fin du projet ne corrige pas une architecture de mise à jour incomplète.
Références officielles
Le Software Developers Guide UG1137 décrit le processus de démarrage Zynq UltraScale+ MPSoC. La page Boot Device Initialization précise l'initialisation de la source choisie.
À retenir
La BootROM charge le premier chargeur. Le FSBL initialise la plateforme et charge les partitions. U-Boot apporte les fonctions nécessaires au démarrage d'un système riche. BOOT.BIN est un conteneur ordonné dont chaque partition possède un rôle et une destination.
Tester mes connaissances - Quiz du chapitre