Compréhension de uboot.lds

Question

J'essaie de comprendre comment le portage d'uboot est fait sur la carte basée sur le processeur powerpc mpc8313. Au cours de cette procédure, je suis tombé sur le fichier appelé uboot.lds, fichier script de l'éditeur de liens.

J'ai besoin de comprendre ce fichier. Je veux dire la signification du contenu mentionné et où les adresses réelles sont définies dans le paquet uboot. Par exemple,

; dans les sections où je peux trouver la signification des informations suivantes:

/* Read-only sections, merged into text segment: */ 
. = + SIZEOF_HEADERS; 
.interp : { *(.interp) } 
.hash   : { *(.hash) } 
.dynsym  : { *(.dynsym) } 
.dynstr  : { *(.dynstr) } 
.rel.text  : { *(.rel.text) } 
.rela.text  : { *(.rela.text) } 
.rel.data  : { *(.rel.data) } 
.rela.data  : { *(.rela.data) } 
.rel.rodata : { *(.rel.rodata) } 
.rela.rodata : { *(.rela.rodata) } 
.rel.got  : { *(.rel.got) } 
.rela.got  : { *(.rela.got) } 
.rel.ctors  : { *(.rel.ctors) } 
.rela.ctors : { *(.rela.ctors) } 
.rel.dtors  : { *(.rel.dtors) } 
.rela.dtors : { *(.rela.dtors) } 
.rel.bss  : { *(.rel.bss) } 
.rela.bss  : { *(.rela.bss) } 
.rel.plt  : { *(.rel.plt) } 
.rela.plt  : { *(.rela.plt) } 
.init   : { *(.init) } 
.plt : { *(.plt) } 
.text  : 
{ 
    cpu/mpc83xx/start.o (.text) 
    *(.text) 
    *(.fixup) 
    *(.got1) 
    . = ALIGN(16); 
    *(.rodata) 
    *(.rodata1) 
    *(.rodata.str1.4) 
    *(.eh_frame) 
} 
.fini  : { *(.fini) } =0 
.ctors  : { *(.ctors) } 
.dtors  : { *(.dtors) } 

/* Read-write section, merged into data segment: */ 
. = (. + 0x0FFF) & 0xFFFFF000; 
_erotext = .; 
PROVIDE (erotext = .); 
.reloc : 
{ 
    *(.got) 
    _GOT2_TABLE_ = .; 
    *(.got2) 
    _FIXUP_TABLE_ = .; 
    *(.fixup) 
} 
__got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2; 
__fixup_entries = (. - _FIXUP_TABLE_) >> 2; 

.data : 
{ 
    *(.data) 
    *(.data1) 
    *(.sdata) 
    *(.sdata2) 
    *(.dynamic) 
    CONSTRUCTORS 
} 
_edata = .; 
PROVIDE (edata = .); 

. = .; 
__u_boot_cmd_start = .; 
.u_boot_cmd : { *(.u_boot_cmd) } 
__u_boot_cmd_end = .; 


. = .; 
__start___ex_table = .; 
__ex_table : { *(__ex_table) } 
__stop___ex_table = .; 

. = ALIGN(4096); 
__init_begin = .; 
.text.init : { *(.text.init) } 
.data.init : { *(.data.init) } 
. = ALIGN(4096); 
__init_end = .; 

__bss_start = .; 
.bss  : 
{ 
*(.sbss) *(.scommon) 
*(.dynbss) 
*(.bss) 
*(COMMON) 
} 
_end = . ; 
PROVIDE (end = .); 
} 

où chercher ces informations et comment identifier les changements à faire dans le fichier lds?

S'il vous plaît reconnaître ou de donner atleast quelques conseils pour lire les informations, merci

Regads, Vijay

Answer 1

Pour le port u-boot, les u-boot.lds peuvent probablement être utilisés à partir du répertoire cpu et pas le répertoire du forum. En d'autres termes, il n'est probablement pas nécessaire de porter ce fichier. Cependant, s'il y a alors ici un aperçu. Vous pouvez trouver beaucoup d'informations dans LD documentation.

En général, ce que les scripts LD vous permettent de faire est de remplacer les emplacements par défaut que la chaîne d'outils GCC place des éléments en mémoire lors de l'exécution. Lorsque vous compilez une application, le code source est traité et des fichiers de code objet contenant du code machine sont créés. Lors de la liaison, les différents fichiers objet sont combinés en un fichier, ELF exécutable par exemple, et un en-tête est placé sur le fichier pour indiquer au système d'exploitation où chaque fichier objet doit être placé en mémoire afin de pouvoir le trouver (globals, function appels, etc.)

Un script personnalisé est nécessaire si vous souhaitez placer le code dans un emplacement spécifique que vous ne pouvez pas attendre du compilateur/éditeur de liens. Il y a beaucoup de raisons de le faire, car je vais essayer d'énumérer.

1. Constantes peuvent être placés dans la mémoire en lecture seule si la RAM est clairsemée
2. mémoire qui est accessible beaucoup peut-être besoin d'être placé dans plus rapide RAM si disponible
3. Certaines données peuvent devoir être alignées sur une certaines limites, telles que 64K
4. Certains code (.TEXT) doit être placé au vecteur de réinitialisation afin qu'il soit exécuté à la réinitialisation
5. même pour les vecteurs code ISR

En outre, il peut être un moyen d'accéder facilement aux pointeurs de mémoire au moment du couplage. Par exemple, __init_begin est défini comme un symbole ayant l'adresse mémoire de tout code compilé sous la forme * .text.init. Vous pouvez maintenant appeler cette mémoire en définissant le compteur de programme sur la valeur __init_begin sans avoir un environnement C complet configuré.

La documentation du compilateur + Makefiles u-boot doivent expliquer comment et quand le compilateur génère des fichiers d'objets de chaque type (ex., Txt .data, .bss, .fini, .ctors, etc.)