Dans ma compréhension uImage est obtenu en exécutant mkimage sur l'image
Votre compréhension est que partiellement correcte.
Un uImage peut contenir n'importe quel type de fichier et n'est pas limité au fichier Linux Image. En fait, il est peu probable que ce soit le fichier (non compressé) Image (puisque ce n'est pas une option classique make).
En revanche, le zImage est l'image compressée, il ne contient pas l'adresse de chargement et point d'entrée (ce que je pense, corrigez-moi si i'am [sic] mal)
Vous avez tort, le zImage contient l'adresse de chargement et le point d'entrée du noyau. L'adresse de chargement est nécessaire pour décompresser l'image du noyau à l'adresse RAM correcte. Le point d'entrée du noyau est nécessaire pour l'exécuter après qu'il a été décompressé.
Lors de la construction de l'image et zImage pour ARM, les Makefiles utilisent
ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)
qui devrait se traduire par le début de la mémoire physique + 0x8000.
La zImage elle-même (c'est-à-dire le programme d'auto-extraction) est PIC, code indépendant de la position. Le zImage peut être chargé n'importe où dans la RAM, et exécuté à sa première adresse, c'est-à-dire que son point d'entrée est son adresse de chargement.
Dans ce cas, pourquoi utiliser un uImage au lieu d'une zImage?
Pour les anciennes versions de U-Boot, il n'y avait pas d'autre choix depuis la commande de Bootz peut ne pas avoir été disponible pour les noyaux Linux.
De nos jours, cela peut être un choix subjectif.
Notez qu'il y a eu un certain ressentiment dans la communauté du noyau Linux envers le support de U-Boot dans le noyau. IOW si certaines personnes avaient leur chemin, j'ai l'impression que vous ne seriez pas en mesure de construire un uImage de la source principale.
Je suis curieux d'apprendre quels sont les formats d'une zImage et d'une uImage, pourriez-vous suggérer quelques références?
La disposition de zImage est essentiellement donnée par sa spécification de lieur. Pour l'ARM, voir arch/arm/boot/compressed/vmlinux.lds.S.
Notez que _magic_start contient une adresse de chargement sans signification. Ceci est également mentionné dans l'article 5 de Booting ARM Linux
The zImage has a magic number and some useful information near its beginning.
Table 2. Useful fields in zImage head code
Offset into zImage Value Description
0x24 0x016F2818 Magic number used to identify this is an ARM Linux zImage
0x28 start address The address the zImage starts at
0x2C end address The address the zImage ends at
The start and end offsets can be used to determine the length of the compressed image (size = end - start).
...
The start address is usually 0 as the zImage code is position independent.
Note de Vincent Sanders cependant que les exigences Démarrages ARM ont été remplacés par Russel King Documentation/arm/Booting
La mise en page d'un uImage est tout simplement l'en-tête U-Boot, plus le fichier image, quel qu'il soit.
(rien Si tout va bien je l'ai écrit contredit ce que Tom Rini a écrit.)
Merci, 1- « Un uImage peut contenir tout type de fichier, et ne se limite pas au fichier image Linux », pourriez-vous s'il vous plaît donner l'exemple du fichier qu'une uImage peut contenir? 2- "Vous êtes incorrect, le zImage contient l'adresse de chargement et le point d'entrée du noyau", je parlais de l'adresse de chargement du périphérique de démarrage et non de l'adresse de chargement du noyau, de toute façon je pense avoir compris; le zImage est PIC donc peu importe où il est chargé – Mouin
(1) L'en-tête a un octet qui code le type d'image. Voir http://elixir.free-electrons.com/u-boot/latest/source/include/image.h#L197 pour les plus de trente valeurs possibles. (2) Le zImage contient son adresse de chargement au décalage 0x28 (mais personne ne semble l'utiliser). – sawdust
OK, clair, merci – Mouin