What is the boot sequence?

Question

I am wondering what the boot sequence of the Raspberry Pi is in a typical setup (say NOOBS), from power application (or warm reset if that's different) up to, say, the apparition of the logo; or where that is described.

Beside a most needed general picture of that sequence, I'm most interested in the early stages:

1. What's the reset vector for the ARM CPU, and how/where is that defined?
2. From what memory are the first ARM CPU instructions fetched? Where is that, and what technology is used to store this code?
3. Is that ARM32 or Thumb (or perhaps Jazelle) code? Does that depend on the low order bit of the reset vector?
4. Is source (or disassembly, or dump) of that early boot code available? If not, is anything technical preventing the use of the JTAG port to determine that? _{^{As for legal, I'm ready to assume the risk of trusting my understanding of the law applicable where I live (France), which is that I'm fully allowed to analyze my own computer, at least in the absence of an explicit contractual requirement not to do so.}}
5. In what order are peripherals initialized, and by what piece of code?
6. Beside the ARM CPU, is there some processor/automata running in the BCM2835, and in the affirmative how does its boot sequence relate to the ARM CPU?

I'm ready to dive into the ARM CPU's Technical Reference Manual and BCM2835 ARM Peripherals, or any other doc.

Update: After posting, I found this and this, stating the BCM2835's GPU is acting as a master to the ARM, and is heavily involved in the boot sequence.

Answer 1

The boot sequence of the Raspberry Pi is basically this:

1. Stage 1 boot is in the on-chip ROM. Loads Stage 2 in the L2 cache
2. Stage 2 is bootcode.bin. Enables SDRAM and loads Stage 3
3. Stage 3 is loader.bin. It knows about the .elf format and loads start.elf
4. start.elf loads kernel.img. It then also reads config.txt, cmdline.txt and bcm2835.dtb If the dtb file exists, it is loaded at 0×100 & kernel @ 0×8000 If disable_commandline_tags is set it loads kernel @ 0×0 Otherwise it loads kernel @ 0×8000 and put ATAGS at 0×100
5. kernel.img is then run on the ARM.

Everything is run on the GPU until kernel.img is loaded on the ARM.

I found this diagram quite useful:

Answer 2

For the new Pi4, the boot flow got some changes as the old bootcode.bin moved from sdcard or /boot to internal 512KB EEPROM

• more : Pi4 Bootflow