Mi chiedo quale sia la sequenza di avvio di Raspberry Pi in una configurazione tipica (diciamo NOOBS), dall'applicazione di potenza (o dal ripristino a caldo se diverso) fino all'apparizione del logo; o dove è descritto.

Accanto al quadro generale più necessario di quella sequenza, sono molto interessato alle prime fasi:

1. Qual è il vettore di ripristino per la CPU ARM e come / dove viene definito?
2. Da quale memoria vengono recuperate le prime istruzioni della CPU ARM? Dov'è e quale tecnologia viene utilizzata per memorizzare questo codice?
3. È quel codice ARM32 o Thumb (o forse Jazelle)? Dipende dal bit di ordine basso del vettore di reset?
4. È disponibile la fonte (o il disassemblaggio o il dump) di quel codice di avvio anticipato? In caso contrario, c'è qualcosa di tecnico che impedisce l'uso della porta JTAG per determinarlo? _{^{Per quanto riguarda il diritto, sono pronto ad assumermi il rischio di confidare nella mia comprensione della legge applicabile nel luogo in cui vivo (Francia), che è che mi è completamente consentito analizzare il mio computer, almeno in assenza di un contratto esplicito requisito per non farlo.}}
5. In quale ordine vengono inizializzate le periferiche e con quale codice?
6. Oltre alla CPU ARM, ci sono alcuni processori / automi in esecuzione nel BCM2835 e, in senso affermativo, in che modo la sua sequenza di avvio è correlata alla CPU ARM?

Sono pronto per immergermi nel Manuale di riferimento tecnico della CPU ARM e nelle periferiche ARM BCM2835 o in qualsiasi altro documento.

Aggiornamento: Dopo la pubblicazione, ho trovato questo e questo , affermando che la GPU del BCM2835 agisce come un master per ARM ed è fortemente coinvolta nella sequenza di avvio.

La sequenza di avvio di Raspberry Pi è sostanzialmente questa:

1. L'avvio dello stage 1 si trova nella ROM su chip. Carica la fase 2 nella cache L2
2. Lo stadio 2 è bootcode.bin. Abilita SDRAM e carica la Fase 3
3. La fase 3 è loader.bin. Conosce il .elfformato e i carichistart.elf
4. start.elfcarichi kernel.img. Quindi legge anche config.txt, cmdline.txte bcm2835.dtb se esiste il file dtb, viene caricato in 0×100& kernel @ 0×8000 Se disable_commandline_tagsè impostato carica kernel @ 0×0 Altrimenti carica kernel @ 0×8000e mette ATAGS in0×100
5. kernel.img viene quindi eseguito sul ARM.

Tutto viene eseguito sulla GPU fino a quando non kernel.imgviene caricato sul ARM.

Ho trovato questo diagramma abbastanza utile: