Ich frage mich, wie die Startsequenz des Raspberry Pi in einer typischen Konfiguration aussieht (sagen wir NOOBS), von der Stromzufuhr (oder dem Warm-Reset, wenn das anders ist) bis zum Erscheinen des Logos. oder wo das beschrieben ist.

Neben dem dringend benötigten Gesamtbild dieser Sequenz interessieren mich vor allem die frühen Phasen:

1. Was ist der Rücksetzvektor für die ARM-CPU und wie / wo ist dieser definiert?
2. Aus welchem ​​Speicher werden die ersten ARM-CPU-Anweisungen abgerufen? Wo ist das und mit welcher Technologie wird dieser Code gespeichert?
3. Ist das ARM32 oder Thumb (oder vielleicht Jazelle) Code? Hängt das vom niederwertigen Bit des Rücksetzvektors ab?
4. Ist die Quelle (oder die Zerlegung oder der Speicherauszug) dieses frühen Startcodes verfügbar? Wenn nicht, kann der JTAG-Port aus technischen Gründen nicht verwendet werden, um dies festzustellen? _{^{Was das Recht betrifft, bin ich bereit, das Risiko einzugehen, meinem Verständnis des in meinem Land (Frankreich) geltenden Rechts zu vertrauen, dh, ich darf meinen eigenen Computer zumindest ohne ausdrücklichen Vertrag vollständig analysieren Anforderung, dies nicht zu tun.}}
5. In welcher Reihenfolge werden Peripheriegeräte initialisiert und mit welchem ​​Code?
6. Gibt es neben der ARM-CPU einige Prozessoren / Automaten, die im BCM2835 ausgeführt werden, und bejahen Sie, wie sich die Startreihenfolge auf die ARM-CPU bezieht?

Ich bin bereit, in das Technische Referenzhandbuch der ARM-CPU und die ARM-Peripheriegeräte BCM2835 oder ein anderes Dokument einzutauchen.

Update: Nach dem Posten habe ich dies und das herausgefunden und festgestellt, dass die GPU des BCM2835 als Master für den ARM fungiert und stark in die Startsequenz involviert ist.

Die Startreihenfolge des Raspberry Pi ist im Wesentlichen wie folgt:

1. Der Start von Stufe 1 befindet sich im On-Chip-ROM. Lädt Stufe 2 in den L2-Cache
2. Stufe 2 ist bootcode.bin. Aktiviert SDRAM und lädt Stufe 3
3. Stufe 3 ist loader.bin. Es kennt das .elfFormat und lädtstart.elf
4. start.elflädt kernel.img. Es liest dann auch config.txt, cmdline.txtund bcm2835.dtb wenn die dtb-Datei existiert, wird sie bei 0×100& kernel @ geladen. 0×8000 Wenn disable_commandline_tagsgesetzt, lädt sie kernel @. 0×0 Andernfalls lädt sie kernel @ 0×8000und setzt ATAGS auf0×100
5. kernel.img wird dann auf dem ARM ausgeführt.

Alles wird auf der GPU ausgeführt, bis kernel.imges auf den ARM geladen wird.

Ich fand dieses Diagramm sehr nützlich: