Raspberry Pi 1 (BCM2835) -- Bootloader & Boot Process: Community Documentation

Target Hardware: Raspberry Pi 1 Model A, Model B, Model A+, Model B+ (all variants using BCM2835 SoC)

1. Overview of the BCM2835 Boot Sequence

The BCM2835 employs a distinctive boot architecture in which the VideoCore GPU serves as the primary boot processor, with the ARM1176JZF-S CPU being activated only after the GPU has prepared the system. This is fundamentally different from most embedded platforms where the main CPU handles all boot stages.

Step-by-Step Boot Flow

Detailed Sequence

1. Power-On Reset - The BCM2835 SoC powers on with the GPU core active and the ARM core held in reset - The internal ROM bootloader (mask ROM, not modifiable) begins execution on the GPU

2. SD Card Detection and Loading - The ROM bootloader scans the SD card for a FAT16 or FAT32 boot partition - It reads the first bootcode.bin found (typically 64KB or less in early versions) into the GPU's L2 cache or small on-chip SRAM - This loader contains the SDRAM initialization code specific to the Pi 1 hardware

(Source: Raspberry Pi GitHub firmware repository contains bootcode.bin in the /boot directory)

3. SDRAM Initialization (bootcode.bin) - bootcode.bin executes on the GPU and initializes the external SDRAM - This is a critical step -- without working SDRAM, the Pi cannot proceed to load larger firmware components or the Linux kernel - The memory controller is configured with timing parameters specific to the SDRAM chips used on the Pi 1 board

4. Loading start.elf - Once SDRAM is available, bootcode.bin loads start.elf (the main VideoCore firmware) into SDRAM - start.elf is significantly larger (several MB) and contains:

   • Graphics processing firmware
   • Audio/video codecs
   • The ARM bootloader logic
   • Device tree blob handling

5. Configuration Reading (config.txt) - start.elf reads config.txt from the boot partition to configure boot options - This file controls memory split (GPU vs ARM), video settings, enable_uart, overclocking, and device tree parameters

6. Kernel Loading - start.elf loads kernel.img (or a named kernel such as kernel7.img on later models, but Pi 1 uses kernel.img) into memory at address 0x00008000 - It prepares either ATAGS (for older kernels) or a device tree blob (DTB) in memory - For Pi 1, the default is ATAGS at address 0x100

7. ARM Handoff - start.elf releases the ARM1176JZF-S from reset - The ARM CPU begins execution at address 0x00008000 - Boot is complete; the Linux kernel (or bare-metal firmware) takes over

2. Boot Firmware & Storage

Firmware Files on the SD Card Boot Partition

The Raspberry Pi 1 requires a FAT-formatted boot partition (typically the first partition, type 0x0C FAT32 or 0x0E FAT16) containing the following files:

(Source: GitHub raspberrypi/firmware /boot directory structure)

Boot Order Priority

The ROM bootloader searches for bootcode.bin in the following locations (in order):

1. SD card (primary boot mode)
2. If not found, it attempts USB (with additional requirements)
3. Network boot is not natively supported by the BCM2835 ROM; this requires special bootloader modifications or an external SPI EEPROM (not present on Pi 1)

EEPROM

There is no external SPI EEPROM on the original Raspberry Pi 1 (Model A/B) or A+/B+. The bootloader resides entirely on the SD card. This is a key distinction from later Pi models (Pi 3B+, Pi 4, Pi 5) which include an external EEPROM for storing a more flexible bootloader.

The boot firmware (bootcode.bin, start.elf, fixup.dat) is stored on the SD card's boot partition and must be present for each boot.

3. Boot Modes Supported

SD Card (Primary and Only Native Mode)

• Supported on all Pi 1 models: Model A, Model B, Model A+, Model B+
• The BCM2835 ROM bootloader natively supports SD card boot only
• Requires a FAT-formatted partition as the first partition
• Boot files must be in the root of this partition
• The SD card must contain a valid partition table and boot sector

USB (Limited/Community-Enabled)

• USB boot is NOT natively supported by the BCM2835 ROM. The original Pi 1 cannot boot directly from USB devices without significant workarounds.
• Community workarounds exist: Users have developed custom bootcode.bin variants (often called "USB boot" firmware) that allow loading from USB mass storage devices. These modified bootloaders are typically sourced from community forums or the raspberrypi/firmware repository's "extra" branches.
• USB boot requires the custom bootloader to first initialize USB (which the ROM cannot do), load bootcode.bin from a USB device, then proceed with SDRAM init and kernel load.
• Important: The Pi 1 Model A+ and B+ have more robust power management that may help with USB boot reliability, but the fundamental ROM limitation remains.

Network/PXE (Not Natively Supported)

• The BCM2835 does not have native PXE/network boot capability in its ROM
• No Ethernet boot option is available out-of-the-box
• Community solutions exist using modified bootcode.bin that implement DHCP/TFTP clients, but these are not part of the official firmware and are considered experimental on Pi 1

Summary Table

4. UART / Serial Console

Default UART Configuration

• The BCM2835 has two UARTs:
• UART0 (PL011) - Full-featured, used by default for serial console
• UART1 (mini UART) - Limited features, lower performance
• On Pi 1, the PL011 UART is mapped to the GPIO pins 14 (TXD) and 15 (RXD) by default
• Default baud rate: 115200 bps, 8N1 (8 data bits, no parity, 1 stop bit)

Enabling Serial Console

• By default, the Pi 1 may or may not output to UART depending on the firmware version and config.txt settings
• To enable serial console output: enable_uart=1 in config.txt (or enable_uart=0 to disable)
• The serial console is controlled by start.elf firmware; earlier firmware versions had the UART enabled by default, while newer versions may require explicit enablement

Hardware Connections

• A USB-to-serial TTL adapter (e.g., FTDI, CP2102) set to 3.3V logic is required
• Warning: Do NOT connect 5V serial adapters directly; use 3.3V logic level or level shifters to avoid damaging the BCM2835's GPIO

Quirks on Raspberry Pi 1

1. No automatic console on early firmware: Early versions of bootcode.bin/start.elf did not automatically output to UART. Users reported needing specific firmware versions or config.txt options to see boot messages.

2. Baud rate variation: Some early firmware used 9600 baud by default. Modern firmware uses 115200 baud.

3. HDMI/Composite video override: The GPU boot process outputs to video first; serial console may be secondary. If no video output is connected, serial console may still show boot messages.

4. GPIO pin changes on Model A+ / B+: The header layout remains the same, but power management differences may affect UART stability (especially with certain USB hubs or power conditions).

5. Mini UART vs PL011: On Pi 1, the PL011 is the primary. The mini UART (UART1) is available on GPIO 14/15 if the PL011 is reconfigured, but this is rarely used.

5. Bare-Metal and OS Bring-up Notes

U-Boot

• U-Boot can be used as a second-stage bootloader on Pi 1, loaded after start.elf hands off to ARM
• However, because start.elf already handles memory initialization and kernel loading, using U-Boot on Pi 1 is less common than on other embedded platforms
• To use U-Boot: compile u-boot.bin for Raspberry Pi, rename to kernel.img, place on SD card; U-Boot will then load the final OS
• U-Boot on Pi 1 requires a device tree blob (DTB) or ATAGS setup matching the BCM2835 hardware

Circle (Bare-Metal C++ Framework)

• Circle is a C++ bare-metal framework for Raspberry Pi (supports Pi 1 through Pi 3)
• For Pi 1 (BCM2835), Circle provides:
• Direct hardware access without an OS
• SDRAM initialization (or uses the one set up by start.elf)
• GPU initialization (optional, via circular buffer)
• USB host/device support
• Basic peripherals (GPIO, timer, UART, interrupt controller)
• Circle can run either:
• After start.elf (using the GPU-provided memory setup), or
• Standalone (by replacing kernel.img and providing minimal initialization)

Custom Firmware / Bare-Metal Development

• The Pi 1 is an excellent platform for bare-metal development
• Custom ARM code can be loaded as kernel.img
• Key considerations:
• The ARM core starts at 0x00008000
• ATAGS are at 0x100 (if using device tree, DTB is passed in r2 or at a configured address)
• The GPU must have already initialized SDRAM (requires running start.elf)
• Alternative: bypass GPU entirely and write ROM-compatible code (requires different bootloader, not covered here)

Linux Kernel

• Linux kernel for Pi 1 uses the bcmrpi or bcm2709 device tree (though bcmrpi_defconfig is typical)
• Kernel versions up to 6.x continue to support BCM2835 (Pi 1)
• The kernel is loaded by start.elf at the address specified in the firmware

6. Key Differences from Neighbouring Pi Generations

Pi 1 Model A+ / B+ Specific Differences

• Reduced power consumption: Model A+ and B+ use smaller PCB and lower-power components
• Same boot process: The boot sequence is identical to original Model A/B
• No hardware differences in boot: All Pi 1 variants share the same BCM2835 and boot behavior

7. Open Questions / Areas Without Official Documentation

Community-Only or Undocumented Areas

1. Exact contents of bootcode.bin: The binary is closed-source (Broadcom proprietary). Its exact initialization sequence and SDRAM timing parameters are not publicly documented. Community knowledge is derived from reverse engineering.

2. SD card timing and compatibility: The ROM bootloader's SD card interface is not formally documented. Some SD cards may fail to boot due to timing issues; the community maintains lists of known-working and non-working cards.

3. USB boot implementation details: Since USB boot requires custom/community bootloader variants, the exact method to enable it and the limitations are not officially documented.

4. GPU memory split internals: While gpu_mem in config.txt controls the split, the exact memory layout and why certain values are required are not publicly documented.

5. Bootloader update mechanism: There is no official "firmware update" process for Pi 1; users manually copy newer bootcode.bin, start.elf, and fixup.dat from the Raspberry Pi GitHub repository.

6. Recovery boot mode: There is no dedicated "recovery" mode button or ROM-level recovery on Pi 1; if SD card boot fails, the device is effectively bricked until a working SD card is inserted.

7. Device tree vs ATAGS preference: The transition from ATAGS to device tree happened across firmware versions; exact firmware versions where device tree became default are not formally documented.

References

• Raspberry Pi GitHub Firmware Repository: https://github.com/raspberrypi/firmware
• eLinux Wiki: RPi Software (boot sequence documentation)
• Raspberry Pi Forums: Community discussions on boot modes, UART, and firmware

*This