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.
Chargement…
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.
JTAG permet de charger un ELF pendant le développement. Pour démarrer sans le poste, préparez une image sur une source non volatile compatible avec la carte, comme SD ou QSPI.
Après le Power On Reset, la BootROM lit le mode de boot et prépare le chargement initial. Ce code interne n'est pas votre application.
Le FSBL est la première étape modifiable du flux classique Zynq. Il applique l'initialisation issue du matériel, prépare notamment horloges et DDR, puis charge les partitions et transmet l'exécution. Il peut également configurer la PL.
Sur MPSoC, les fonctions de gestion et de sécurité ajoutent notamment PMU et CSU. Un système Linux utilise généralement plusieurs composants :
| 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 |
Les sources et l'ordre exact diffèrent selon génération, image et mode choisi. Le PMU firmware n'est pas une application ARM ordinaire.
Bootgen lit un BIF décrivant les partitions et leurs attributs :
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
}Ce BIF illustre un flux MPSoC vers U-Boot, pas une image Linux complète. Un standalone Zynq-7000 demande généralement FSBL et ELF, avec bitstream si la PL est utilisée.
Configurez la PL avant qu'une application accède à ses IP. Les destinations et niveaux d'exception doivent correspondre à chaque binaire et au processeur choisi.
Un programme affichant un message sur l'UART permet de contrôler les étapes de base :
int main(void)
{
Xil_DCacheDisable();
delay(1U);
xil_printf("Boot application started\r\n");
return 0;
}Ce fragment suppose les en-têtes BSP, une sortie UART configurée et une fonction delay définie dans le projet. L'attente ne configure pas l'UART. La désactivation du cache sert ici au diagnostic ; elle n'est pas une exigence générale de boot.
Le FSBL travaille avec une mémoire locale limitée. U-Boot ajoute pilotes, commandes, fichiers, réseau et choix d'image, utiles à Linux et aux stratégies de mise à jour. Une petite application standalone peut s'en passer.
Pour un échec, commencez par l'image minimale et la console série. Vérifiez mode, support, ordre des partitions, destinations et cohérence entre XSA, FSBL, bitstream et application. Une absence de message peut aussi venir du port UART ; elle ne prouve pas que la BootROM est bloquée.
Authentification et chiffrement dépendent de la famille et de la politique choisie. Racine de confiance, clés, mises à jour et récupération doivent former une chaîne cohérente avant la production.
Le guide UG1137 décrit le flux MPSoC ; Boot Device Initialization détaille les sources.
Tester mes connaissances - Quiz du chapitre