How the Raspberry Pi boots up

This is an in-detail account of the Raspberry Pi boot process collected from various sources, mainly from the official forums. First, you need to know the RPi does not boot up like a conventional desktop computer. The VideoCore a.k.a the Graphics processor actually boots before the ARM CPU! Anyway, before we get into the details here’s a diagram of the RPi highlighting the Broadcom BCM2835 SoC.

The SoC (or System-on-Chip) contains the ARM CPU, the VideoCore Graphics Processor,  ROM (Read-Only-Memory) chips, the SDRAM and so many other things. Basically, think of a SoC as your Motherboard and CPU compressed together into a single chip.

When you power on your Raspberry Pi, the first bits of code to run is stored in a ROM chip in the SoC and is built into the Pi during manufacture! This is the called the first-stage bootloader. The SoC is hardwired to run this code on startup on a small RISC Core (Reduced Instruction Set Computer). It is used to mount the FAT32 boot partition in your SDCard so that the second-stage bootloader can be accessed. So what is this ‘second-stage bootloader’ stored in the SD Card? It’s ‘bootcode.bin’. You might have seen this file if you had mounted the SD Card in Windows. Now here’s something tricky. The first-stage bootloader has not yet initialized your ARM CPU (meaning CPU is in reset) or your RAM. So, the second-stage bootloader also has to run on the GPU. The bootloader.bin file is loaded into the 128K 4 way set associative L2 cache of the GPU and then executed. This enables the RAM and loads start.elf which is also in your SD Card. This is the third-stage bootloader and is also the most important. It is the firmware for the GPU, meaning it contains the settings or in our case, has instructions to load the settings from config.txt which is also in the SD Card.  You can think of the config.txt as the ‘BIOS settings’ (as is mentioned in the forum). Some of the settings you can control are (thanks to dom):

arm_freq : frequency of ARM in MHz. Default 700.

gpu_freq : Sets core_freq, h264_freq, isp_freq, v3d_freq together.

core_freq : frequency of GPU processor core in MHz. Default 250.

h264_freq: frequency of hardware video block in MHz. Default 250.

isp_freq: frequency of image sensor pipeline block in MHz. Default 250.

v3d_freq: frequency of 3D block in MHz. Default 250.

sdram_freq: frequency of SDRAM in MHz. Default 400.

The start.elf also splits the RAM between your GPU and the ARM CPU. The ARM only has access the to the address space left over by the GPU address space. For example, if the GPU was allocated addresses from 0x000F000 – 0x0000FFFF, the ARM has access to addresses from 0x00000000 – 0x0000EFFF. (These are not real address ranges. It’s just for demonstration purposes). Now what’s even funnier is that the ARM core perceives 0x00005001 as it’s beginning address 0x00000000. In other words, if the ARM core requests the address 0x0000000, the actual address in RAM is 0x00005001. Edit: The physical addresses perceived by the ARM core is actually mapped to another address in the VideoCore (0xC0000000 and beyond) by the MMU (Memory Management Unit) of the VideoCore. The config.txt is loaded after the split is done so you cannot specify the splitting amounts in the config.txt. However, different .elf files having different splits exist in the SD Card. So, depending on your requirement, you can rename those files to start.elf and boot the Pi. (The forums mention of having this functionality in a dynamic fashion, but I don’t know whether they have implemented it yet) [EDIT8/7/2014: As per Andrew’s comment it has been implemented in present firmware]  In the Pi, the GPU is King!

Other than loading config.txt and splitting RAM, the start.elf also loads cmdline.txt if it exists. It contains the command line parameters for whatever kernel that is to be loaded. This brings us to the final stage of the boot process. The start.elf finally loads kernel.img which is the binary file containing the OS kernel (DUH!?) and releases the reset on the CPU. The ARM CPU then executes whatever instructions in the kernel.img thereby loading the operating system.

After starting the operating system, the GPU code is not unloaded. In fact, start.elf is not just firmware for the GPU, It is a proprietary operating system called VideoCore OS. When the normal OS (Linux) requires an element not directly accessible to it, Linux communicates with VCOS using the mailbox messaging system.

Note: Special thanks to user dom  in the official RPi forums and the community behind the official wiki.

Booting the Raspberry Pi without a Monitor or Router – the first time!

If you’ve just got a new Raspberry Pi and don’t have a monitor to try it out, fear not. The latest Debian Wheezy distributions have SSH enabled on default, thus enabling us to log in if we have a net connection to the RPi.

Note: You should have a Linux distribution running since we are going to modify some files in the SD Card which will have a Linux File System.

First, write the latest Debian Wheezy Image in to a SD Card using Win32DiskImager.

Then we are going to open a file in the SD Card so switch to your favorite Linux distribution (Ubuntu anyone? ) Hopefully your SD Card will already be mounted, otherwise google to find how.

I used Fedora 18, so it was mounted in


where ‘/’ signifies the root file system of the your computer (not the Pi). Type “mount” in a terminal to find the SD Card if it’s not displayed in the desktop.
Now we must give our Raspberry Pi an IP Address. This will enable us to connect to the RPi through SSH. By default, the RPi is configured to receive an IP address from a DHCP server. What we’ll do is change this default setting to a static IP address of our choosing. These settings are recorded in a file called ‘interfaces’ in /etc/network/ where ‘/’ signified the root in the Raspberry Pi SD Card.
Therefore to open this file, the full path for the ‘interfaces’ file for me would be


To open it, type the following in the terminal taking care to replace the path with your path. This will open the file in the ‘nano’ text editor.

sudo nano /run/media/sagara/62ba9ec9-47d9-4421-aaee-71dd6c0f3707/etc/network/interfaces

Then comment out the ‘dhcp’ line and modify it like the following. I have chosen to give my RPi the address

auto lo

iface lo inet loopback
#iface eth0 inet dhcp this is a comment
iface eth0 inet static

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

Save and exit nano. Now you have given your Raspberry Pi a static IP address. Since we are not using a router to connect to the Pi, we’ll be using a RJ45 Ethernet cable a.k.a ‘Crossover’ cable. So connect your RPi and Laptop/PC together with the cable.

Now if you know a teensy bit about networking, this won’t sound peculiar; you have to give the Ethernet port on your Laptop/PC and the Ethernet port on your RPi, unique, valid IP addresses which are on the same network. We have already given an IP address and a network address for the Pi. (see the address and netmask values). The only thing remaining is to give the Ethernet port on our Laptop/PC an IP address on the same network. I have chosen to give as the IP address of my laptop.

If you are on Windows, open the Network and Sharing Center and click on the Ethernet connection properties.


Then in the IPV4 properties choose “Use the following IP address” and put,

IP :
Subnet Mask:

Then download PuTTy. It’s a SSH client for windows. Start it and put as the connecting address and now you can connect to your Raspberry Pi!!


You can also do this in Linux. All you have to do is assign a static IP address to the Ethernet port. SSH is already installed on most Linux distributions so PuTTy will not be needed. Here’s a snapshot of SSH-ing to my RPi from Fedora.


After this, you may want install a VNC Server on your Pi. That will enable you to use the screen in your laptop as a monitor for the Raspberry Pi.

Check it out: