• Raspberry Pi 4 Boot Sequence

    3 days ago 0 comments

      The Raspberry Pi 4 boot sequence is very different from earlier models, so let's have look how it works now.

      When the Raspberry Pi 4 is powered on, the BCM2711 VPU core 0 gets started. The program counter is set to 0x60000000. This address maps to the on-chip boot ROM. Note that the VPU frequency is set to the oscillator (54.0 MHz on RPi4), so it's not very fast, but it does not do a lot of things either:

      1. Read boot-related OTP registers (17/18, 66 and 67). Note that these registers have a different meaning than on Raspberry Pi 3. More information can be found here: https://github.com/raspberrypi/firmware/issues/1169
      2. If a “boot indication pin” is configured, it is activated for some milliseconds.
      3. If USB device-mode recovery force boot pin is configured and active, steps 4 and 5 are skipped.
      4. If SD card boot pin is either active or not configured, the boot ROM tries to load recovery.bin from the first FAT partition. This provides a mechanism to unbrick your board if the EEPROM gets corrupted. More details can be found here: https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md
      5. Next, the boot ROM tries to load firmware from the EEPROM chip. This is a standard Winbond W25X40 chip, access through SPI0 on GPIO 40–43.
      6. If everything else fails, the chip enters USB device mode (on the Type-C connector) and waits to get the firmware image from the USB host. I have not been able to boot an image over USB yet, but it was tested by a Foundation engineer. More information: https://github.com/raspberrypi/firmware/issues/1184

      Note that a 20-byte signature must be appended to the firmware image. It is an HMAC-SHA1 hash of the image using a universal key that is also stored in the OTP, but not accessible using the Foundation firmware APIs. A similar mechanism was available as an optional feature on Raspberry Pi3. I originally assumed that the key is unique for each Raspberry Pi, but since there is one universal recovery.bin image that works for all, there must be only one key. Given that it provides no security, I'm not sure why this hash is now mandatory.