Logiciels Libres et Systèmes Embarqués


4.2. Principe de U-Boot

U-Boot démarre (généralement) à partir d'une ROM, avant même que le contrôleur de mémoire vive ne soit initialisé. Etant donné que le minimum requis pour qu'un code C puisse fonctionner est la présence d'une pile, U-Boot utilise soit le cache de données, soit une mémoire présente sur la puce du processeur (OCM) en tant que mémoire vive. Dans notre cas très particulier, les contrôleurs mémoire sont déjà initialisés lorsque U-Boot démarre, la SDRAM sera donc utilisée dès l'amorce du système.

Au démarrage de U-Boot, seule la pile est dans une mémoire inscriptible, il n'est donc pas possible d'utiliser la mémoire globale (segment DATA). Pour pallier à ce problème, U-Boot dédie une partie de la pile à une structure de données globales (nommée gd_t) accessible à travers le pointeur gd. Ce pointeur est stocké dans un registre de manière permanente (R29 sur PowerPC et R8 sur ARM), ainsi toutes les fonctions peuvent y accéder directement, c'est à dire sans que gd ne soit passé en paramètre (ce qui aurait utilisé trop de pile).

Une fois que le contrôleur DRAM est initialisé (appel à initdram), U-Boot copie son moniteur (c'est-à-dire son coeur) en partie haute de la mémoire vive, cette étape est appelé relocation. A partir de ce moment, U-Boot se retrouve dans un environnement traditionnel (segments DATA et BSS accessibles en écriture), dans la configuration suivante [11] :

0x0000 0000	Exception Vector code
      :
0x0000 1FFF
0x0000 2000	Free for Application Use
      :
      :

      :
      :
0x00FB FF20	Monitor Stack (Growing downward)
0x00FB FFAC	Board Info Data and permanent copy of global data
0x00FC 0000	Malloc Arena
      :
0x00FD FFFF
0x00FE 0000	RAM Copy of Monitor Code
0x00FF FFFF	[End of RAM]