2016-10-06 2 views
0

J'ai un problème sur celui-ci. J'utilise ARM Cortex-A9 avec DS-5 pour créer un firmware baremetal. J'ai modifié mon fichier linker pour placer intentionnellement la section .data LMA à côté des sections text et rodata, car son VMA par défaut est situé à 1 Mo et l'image .bin à environ 1 Mo mais contenant 90% de zéros. Et donc j'ai intentionnellement fait LMA! = VMA pour gagner de la place. J'ai également ajouté un code dans start.S qui déplace la section .data de son lma à vma.chargement ELF lorsque VMA! = LMA

Cependant, lors du chargement du fichier elf résultant dans DS-5, il charge déjà toutes les sections sur leur VMA. Par conséquent, mon code start.S qui est censé déplacer les données, copié à partir du LMA avec le contenu de la poubelle à la VMA déjà correcte, et peu de temps après, ces déchets ont abouti à la faute.

J'ai eu l'expérience avec VMA et LMA inégaux en binaire dans Cortex-M4 et utilisé gdb pour son débogage elf, et il n'y avait pas de problèmes là-bas, mais c'était microcontrôleur. Dans mon application de processeur d'armement actuelle, comment puis-je simuler dans Elf débogage le scénario de la copie correcte des données de son LMA à VMA. Très probablement lors du démarrage autonome en utilisant le format binaire, il n'y aura pas de problèmes, mais pour le moment, nous sommes toujours dans le débogage elf, donc je dois résoudre ce problème.

+0

Je ne sais pas DS-5, mais vérifiez si vous pouvez déplacer les sections sur un script lors du chargement de votre fichier ELF. Au moins c'est possible avec T32. – juansolsona

+0

ARM DS-5 est l'IDE que nous utilisons pour développer le firmware fonctionnant sur ARM. Il est construit sur Eclipse. C'est celui qui charge le fichier elf directement à partir de SDRAM et nous permet de déboguer. – ubermensch

+0

J'ai regardé les commandes du débogueur dans DS5 (https://static.docs.arm.com/dui0452/y/DUI0452Y_debugger_command_reference.pdf) et il me semble que si vous pouvez appliquer un offset à la commande load, jetez un oeil à page 1.3.85. DS5 prend également en charge la syntaxe de commande T32 (CMM), mais semble être seulement partielle, néanmoins vous pouvez vérifier "data.load.elf FileName.AXF reloc .text à 0xaddress" (http://www2.lauterbach.com/pdf /general_ref_d.pdf) J'espère que ça aide. – juansolsona

Répondre

1

Problème résolu ... Je voudrais partager la solution qui m'a été donnée:

Il aide à se rendre compte que « VMA » et « LMA » sont la terminologie utilitaire GNU et non dans la spécification ELF. Une fois que vous aurez fini de le voir en interprétant un fichier exécutable ELF, vous verrez qu'il y a un champ d'en-tête de programme appelé "p_paddr" et un autre appelé "p_vaddr" - qui facilite la recherche! L'option dont vous avez besoin dans DS-5 utiliser p_paddr est:

ARM DS-5 Debugger Commande Référence: 1.3.138 fixés Elf charge segments-à-p_paddr

Par défaut, DS-5 utilise p_vaddr, ce qui est la norme. L'utilisation de p_paddr est une qualité d'implémentation, et est laissée très vaguement définie dans la spécification. Le compilateur ARM, Linker et la bibliothèque C ne génèrent pas cette information car le processus de relocalisation est géré en interne (chargement par dispersion). Certains environnements utilisent p_paddr non pas comme une adresse physique, mais comme l'adresse de chargement (d'où «LMA»), et certains l'utilisent comme une adresse pour résoudre les symboles avant et après que MMU soit activée ..