Scripts de chargeur pour ARM STR7xx

Question

J'essaie de programmer ARM avec Eclipse + CDT + yagarto (chaîne d'outils) et OpenOCD. Dans plusieurs exemples de projets (du site yagarto par exemple), j'ai trouvé des scripts de lieur (* .ld) dans lesquels de nombreuses informations de liaison étaient spécifiées (ainsi que des définitions de sections). En fait, je n'ai jamais rencontré ces fichiers auparavant (IAR n'en a pas besoin) et je les trouve un peu difficiles à comprendre du premier coup d'œil. Ma question est donc la suivante: puis-je utiliser un seul fichier de script de ce type pour mon processeur cible (STR710FZ2T6) avec tous mes projets ou dois-je me familiariser avec l'écriture de ces scripts et les écrire pour chaque projet? Si je peux utiliser un seul fichier pour tous les projets d'un processeur cible particulier, pouvez-vous indiquer où je peux en trouver un aussi universel?

Answer 1

Je suppose que chaque personne sur trois a un script ou une solution différente. Il y a un certain nombre de problèmes qui doivent être résolus, différents lieurs vont les résoudre de différentes manières. Je pense que GNU a rendu la tâche trop difficile, sinon la magie noire.

Pour un système embarqué, vous allez souvent avoir un flash, un eeprom ou une autre forme de mémoire en lecture seule à partir de laquelle démarrer. Comme les autres processeurs, l'ARM dispose d'une table vectorielle lui indiquant essentiellement l'emplacement du code de réinitialisation, des interruptions, etc. Cette table doit donc se trouver à un endroit spécifique et vous devez dire à l'éditeur de liens de le placer à cet endroit précis (en premier) .

L’un des scripts que j’aime utiliser est:

MEMORY
{
    bob (RX) : ORIGIN = 0x0000000, LENGTH = 32K
    joe (WAIL) : ORIGIN = 0x2000000, LENGTH = 256K
}

SECTIONS
{
    JANE : { startup.o } >bob
}

J'utilise généralement ram et rom comme noms au lieu de bob et joe, mais en démontrant ici que peu importe le nom, il ne s'agit que d'étiquettes.

Autre variante du thème:

MEMORY
{
    rom(RX)   : ORIGIN = 0x00000000, LENGTH = 0x8000
    ram(WAIL) : ORIGIN = 0x20000000, LENGTH = 0x2000
}

SECTIONS
{
    .text : { *(.text*) } > rom
}

Le premier vous permet de placer les fichiers sur la ligne de commande de l'éditeur de liens dans n'importe quel ordre, mais vous devez disposer du tableau des vecteurs dans le fichier startup.o. Ce dernier vous permet d'utiliser n'importe quel nom de fichier, mais le premier fichier du script de l'éditeur de liens doit contenir la table des vecteurs.

arm-thumb-elf-gcc -Wall $(COPS) vectors.o putget.o blinker2.c -T memmap -o blinker2.elf

Ou avec ld directement

arm-thumb-elf-ld vectors.o putget.o blinker2.o -T memmap -o blinker2.elf

Le RX demande à l'éditeur de liens de mettre en lecture et d'exécuter des choses dans cette section de mémoire, et WAIL correspond à tout le reste. Si vous n'avez qu'un seul ram par exemple, vous pouvez mettre tous les indicateurs RXWAIL sur la ligne qui indique où se trouve le ram. En fonction de votre chargeur, dans ce cas, vous pouvez vous fier au fichier elf pour indiquer au chargeur où créer une branche ou bien faire en sorte que le point d’entrée soit le début du fichier binaire et que le chargeur puisse être plus simple. Les bras (pas le cortex-m3) ont une instruction de branche en tant que premier vecteur pour le vecteur de réinitialisation, vous pouvez donc simplement prétendre créer un tableau de vecteurs de toute façon pour une solution en RAM et que cela fonctionnera.

Il existe un certain nombre de problèmes avec cette solution qui ne me dérangent pas. J'initialise les variables dans mon code, pas pendant la déclaration.

Ceci

int rx;

int main ( void )
{
  rx = 7;

au lieu de

int rx=7;

int main ( void )
{

Je ne suppose jamais non plus qu'une variable est égale à zéro lorsque le code commence, je l'initialise toujours à quelque chose avant de commencer. Votre code de démarrage et le script de l'éditeur de liens en équipe peuvent travailler ensemble pour faciliter l'automatisation de la réinitialisation du code bss et la copie de données init non nulles de la ROM à la RAM au démarrage. (que int rx = 7; ci-dessus nécessite un code qui copie la valeur 7 de quelque part dans rom et l’écrit dans l’emplacement mémoire du bélier alloué pour la variable rx de sorte que lorsque main () démarre, le 7 se trouve là.

Mon code de démarrage est également assez simple grâce à cette méthode:

.globl _start
_start:
    b reset
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang

hang : b hang

reset:
    ldr sp,=0x10004000
    bl main
    b hang

Vous allez voir ou lire des solutions qui permettent au code de démarrage et au script de l'éditeur de liens de fonctionner ensemble sans avoir à coder en dur les pointeurs de pile, l'espace de pile, etc., vous pouvez à nouveau mettre beaucoup de travail dans un démarrage compliqué les scripts de code et d’éditeur de liens pour gagner en automatisation et peut-être économiser du travail, peut-être pas. L’automatisation, si / quand vous travaillez, peut réduire les erreurs humaines et cela peut être une bonne chose, même si vous changez souvent de puce ou essayez d’écrire un bit de code qui fonctionne dans une famille de puces, vous voudrez peut-être aussi cette automatisation. .

Mon résultat est OUI, vous ne pouvez vivre qu'avec un seul script pour l’ensemble de vos travaux ARM. Mais vous devez adapter votre travail à ce script. Vous n’allez probablement pas trouver un script qui fonctionne avec le code exemple Everyones. Plus le script est compliqué, plus il sera difficile d'emprunter. Oui, mes scripts ci-dessus peuvent probablement être exécutés sur la ligne de commande ld, mais il y a bien longtemps (gcc 2,95), je ne pouvais pas le faire fonctionner si bien que le script minimal ci-dessus était développé et que je les utilisais depuis. Il a fallu modifier le second script pour une raison quelconque, mais avec 4.x.x, certainement 4.4.x, je peux utiliser l'un ou l'autre.

Answer 2

Il n’existe pas de script d’éditeur de liens universel. Ces scripts sont très importants, car ils définissent où seront placées les différentes sections de données et de programme en mémoire (RAM ou ROM). Il y a quelque chose d’équivalent dans les compilateurs IAR (fichiers xcl si je me souviens bien). De toute évidence, vous n’avez jusqu’à présent utilisé que ceux par défaut.

Il existe un document intéressant sur STR7xx intitulé "Utilisation des outils Open Source pour STR7xx Cross Développement " ;. Vous pouvez trouver un lien dans la page d'accueil de yagarto. Je vous recommande de l'examiner et d'essayer de comprendre le fonctionnement des fichiers de l'éditeur de liens. Vous devez également comprendre certains autres fichiers de configuration.