Quelle est la séquence de démarrage?

35

Je me demande quelle est la séquence de démarrage du Raspberry Pi dans une configuration typique (disons NOOBS), depuis l’application d’alimentation (ou la réinitialisation à chaud si cela est différent) jusqu’à l’apparition du logo; ou où cela est décrit.

Outre une image générale très utile de cette séquence, je m'intéresse surtout aux premières étapes:

  1. Quel est le vecteur de réinitialisation de la CPU ARM et comment / où est-il défini?
  2. Dans quelle mémoire les premières instructions du processeur ARM sont-elles extraites? Où est-ce, et quelle technologie est utilisée pour stocker ce code?
  3. S'agit-il du code ARM32 ou du pouce (ou peut-être de Jazelle)? Cela dépend-il du bit de poids faible du vecteur de réinitialisation?
  4. La source (ou le désassemblage ou le dump) de ce code de démarrage initial est-elle disponible? Si non, est-ce que quelque chose de technique empêche l'utilisation du port JTAG pour le déterminer? En ce qui concerne les aspects juridiques, je suis prêt à assumer le risque de faire confiance à ma compréhension du droit applicable dans mon pays (France), ce qui signifie que je suis pleinement autorisé à analyser mon propre ordinateur, du moins en l'absence d'un contrat explicite obligation de ne pas le faire.
  5. Dans quel ordre les périphériques sont-ils initialisés et par quel morceau de code?
  6. Outre le processeur ARM, y a-t-il des processeurs / automates fonctionnant dans le BCM2835 et, dans l’affirmative, quel est le lien entre sa séquence de démarrage et le processeur ARM?

Je suis prêt à plonger dans le manuel de référence technique de la CPU ARM et les périphériques ARM BCM2835 , ou dans tout autre document.

Mise à jour: Après avoir posté, j'ai trouvé ceci et cela , indiquant que le GPU du BCM2835 agit en tant que maître pour ARM et est fortement impliqué dans la séquence de démarrage.

boot fgrieu
la source
4
Tout ce que je peux dire, c'est que la plupart de ces informations sont des sources fermées, comme le code source, les chargeurs de démarrage et les microprogrammes SoC. Pour l'instant, allot est inconnu. Vous devriez savoir une chose. Le BCM est un GPU ... pas un processeur. Le chargeur de démarrage démarre dans la section GPU, initialise la RAM et remet au processeur le premier endroit où nous avons accès au code source ... ou Raspbian. Bonne chance. Cette question est très large et difficile à répondre.
Piotr Kula
Connexes: Que se passe-t-il pendant le processus de démarrage? . Dupliquer?
Peter Mortensen

Réponses:

38

La séquence de démarrage du Raspberry Pi est fondamentalement la suivante:

  1. L'étape 1 de démarrage est dans la ROM sur puce. Charge l'étape 2 dans le cache N2
  2. L'étape 2 est bootcode.bin. Active la SDRAM et charge l'étape 3
  3. L'étape 3 est loader.bin. Il connaît le .elfformat et chargestart.elf
  4. start.elfdes charges kernel.img. Il lit ensuite également config.txt, cmdline.txtet bcm2835.dtb si le fichier dtb existe, il est chargé à 0×100& kernel @ 0×8000 Si disable_commandline_tagsest défini, il charge le noyau @ 0×0 Sinon, il charge le noyau @ 0×8000et met ATAGS à0×100
  5. kernel.img est ensuite exécuté sur le bras.

Tout est exécuté sur le GPU jusqu'à ce qu'il kernel.imgsoit chargé sur l'ARM.

J'ai trouvé ce diagramme assez utile:

Séquence d'amorçage

SG60
la source
2
Utile. Pourrait-on préciser si le chargeur de démarrage de la deuxième étape bootcode.binest un code géré par le GPU, l'ARM (et ensuite quel type de code) ou une combinaison de ceux-ci? Même chose pour la 3ème étape loader.bin(si cela n’est pas parti, comme cela semble être).
Fgrieu
3
@fgrieu J'ai modifié la réponse pour inclure une clarification. Tout est exécuté sur le GPU jusqu’à kernel.imgce qui est exécuté sur l’ARM.
SG60
1
Selon ce loader.bin n'est plus utilisé. bootcode.bincharge directement en start.elffonction de cet engagement Git
HeatfanJohn
@ SG60: Pouvez-vous mettre à jour votre réponse avec les informations de HeatfanJohn?
Peter Mortensen
Est-ce que quelqu'un sait à propos de NOOBS boot? Apparemment, le processus est légèrement différent, impliquant Recover.elf et quelques singeries à démarrage en douceur. Je suis curieux de pouvoir faire fonctionner uboot à un niveau légèrement inférieur.
Sam