Boot - Configuration


When the Pi is powered on, the boot sequence is the following:

1. 1st stage bootloader
2. 2nd stage bootloader
3. 3rd stage bootloader
4. Kernel
5. Init
6. Daemons
7. Shell
8. GUI

==============================

Booting up the Raspberry Pi

A System on a Chip (SoC) is a method of placing all necessary electronics for running a computer on a single chip. The SoC contains: CPU, GPU,  ROM chips, RAM (SDRAM) and many other things. You can imagine an SoC like a motherboard with CPU and RAM is compressed together into a single chip. The SoC of the Raspberry Pi is called Broadcom BCM2835 (depending on the model).This contains a CPU (ARM CPU, ARM1176JZFS, running at 700Mhz), a GPU (VideoCore 4 GPU, which is capable of full HD quality playback), ROM, SDRAM, L2 cache and other things.

When Raspberry Pi is turned on, the BCM2835 system on chip (SoC) powers up, but the ARM CPU is held in reset (which means it is off), the VideoCore GPU comes up first, and it is responsible for booting the system. (At this point the SDRAM is also disabled.)

1st stage bootloader - ROM:

In the fist phase, the Videocore GPU starts executing the first stage bootloader from the ROM, which was built into the SoC during manufacture. The SoC is hardwired to run this code on startup. The task of the first stage bootloader in the ROM is to mount the boot partition in the SD card and load bootcode.bin (second stage bootloader) from the SD card into the L2 cache, and then start running it.

(The chip on the Pi (BCM2835) originally was architected as a multimedia processor (targeted at set-top boxes), so the L2 cache was designed to be used by the GPU alone. Unlike other traditional processors, the CPU of the Pi doesn’t have any L2 cache of its own.)

2nd stage bootloader - bootcode.bin:

The ARM CPU is still not initialized yet, so the second stage bootloader (bootcode.bin) is also executed on the Video GPU. bootcode.bin enables SDRAM and reads start.elf (third stage bootloader) from SD card into RAM and runs it. (In the past another bootloader (called loader.bin) was loaded at this stage, but since few years it has been phased out.)

3rd stage bootloader - start.elf:

The third stage bootloader (start.elf) is the firmware for the GPU, meaning it contains instructions to load the settings from config.txt (which is also on the SD card). You can think of config.txt, as the "BIOS settings", as it contains parameters for the ARM CPU/GPU/RAM, frequency, and one  additional important parameter: gpu_mem. This parameter specifies how much memory is allocated to the GPU, as start.elf also splits the RAM between the GPU and CPU. (based on this parameter GPU and CPU has its own address space)

(Prior to the introduction of the 512MB Raspberry Pi, multiple start.elf files were provided (arm128_start.elf, arm192_start.elf, arm224_start.elf). These files partitioned the memory used between the ARM processor and the VideoCore GPU, but this has now been superseded with a gpu_mem parameter in the config.txt file specifying the memory to be allocated to the GPU.)

After the config.txt file has been loaded and parsed, the third stage bootloader will load cmdline.txt. cmdline.txt is a file containing the kernel command line parameters to be passed to the kernel at boot. 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, and also releases the reset on the CPU. The ARM CPU then executes the instructions in the kernel.img file and the operating system starts booting.

After starting the operating system, the GPU code is not unloaded. In fact, start.elf is not just firmware for the GPU, it is an 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).

Kernel:

The Linux kernel is one of the most fundamental parts of Raspbian. It is the heart of the operating system, which is responsible for all kind of the operations like displaying text on the screen, or handling the keyboard. For example if you want to use a USB drive by connecting it to the Raspberry Pi, the kernel needs to know what it is and how to use it. In this case, the kernel automatically detects the USB drive and notifies a daemon (a special background application) that automatically makes the files available to you.

Init:

When the kernel has finished loading, it automatically runs a program called init. This program is designed to finish the initialization of the Raspberry Pi, and then to load the rest of the operating system. This program starts by loading all the daemons into the background, followed by the graphical user interface.

Daemons:

A daemon is a piece of software that runs behind the scenes to provide additional functionalities to the operating system. Some examples of a daemon,  like printing daemon, which in the background makes printing possible, or syslog daemon, which is responsible for logging system activities, or Autofs, a daemon that automatically mounts removable storage devices such as USB drives.

A distribution (such as Raspbian) needs more than just the kernel to work, it also needs other softwares that allow the user to interact with the kernel. The core operating system consists of a collection of programs and scripts that make this happen.

The shell:

After all the daemons have been loaded, init launches a shell. A shell is a special program, it is an interface to your Raspberry Pi that allows you to type in commands using a keyboard. (When you open a terminal/console session and you type in commands, at that time the shell is being used.) There are several shells available in Linux,  Raspbian uses the Bourne again shell (bash) which is the most common shell used in Linux.

GUI (X server and desktop environment):

After the shell and daemons are loaded, by default the X server is automatically started. The role of the X server is to provide you a graphical user interface (GUI) where the mouse can be used, and windows/drawings can be displayed on the screen. Usually this GUI is called as "desktop environment" ( a metaphor for a desktop), which consists of a bunch of programs running on top of the operating system. This is sometimes described as a graphical shell.  A desktop environment typically consists of icons, windows, toolbars, folders, wallpapers it can also provide drag and drop functionality and other features that make the desktop metaphor more complete.  Raspbian includes a graphical user interface called Lightweight X11 Desktop Environment or LXDE. LXDE is used in Raspbian as it was specifically designed to run on devices such as the Raspberry Pi, which only have limited resources. (The opposite if the desktp envrinment is the tradditional command-line interface (CLI), which is still used, when we open a shell.)

==============================

Firmware

Firmware is a small package of code that usually installed on a special chip of a computer. Firmware helps the OS to know, how to talk to the hardware. In the case of the Raspberry Pi, there is no special chip, the firmware will live on the first partition of the SD card. The software package  which contains the firmware is called "raspberrypi-bootloader" (this package also contains the kernel as well).

In earlier Raspbian realeases the firmware and kernel were separated, so each of them needed an update independently. Firmware was updated with "rpi-update" and the kernel (Raspbian OS) was updated with "apt-get upgrade".

In the newer releases of Raspbian, the kernel and the firmware are incuded in one package (raspberrypi-bootlader), so a separate firmware update (rpi-update) is not needed anymore. The command "rpi-update" is still available, but not recommended to use. Some details from rpi-update on GitHub:

"Even on Raspbian you should only use this with a good reason.

This gets you the latest bleeding edge kernel/firmware. There is always the possibility of regressions.

Bug fixes and improvements will eventually make their way into new Raspbian releases and apt-get when they are considered sufficiently well tested.

A good reason for using this would be if you like to help with the testing effort, and are happy to risk breakages and submit bug reports. These testers are welcome."

So, the rpi-update command will load the latest "cutting edge" version of the firmware, and occasionally this can cause minor problems, and after some time and testing this firmware version will be available with "apt-get upgrade" as well.

==============================

Configuration

The Raspberry Pi chip (BCM2835) has no BIOS menu, where various low-level system settings can be configured. It relies on text files containing configuration settings that are loaded by the chip when the power is switched on. These files are in the /boot directory:

config.txt     <--it contrlols the hardware settings

start.elf      <--memory partitioning

cmdline.txt    <--kernel mode parameters

==============================

config.txt

The Pi’s hardware is controlled by settings in config.txt,  which tells the Pi how to set up its various inputs and outputs, and at what speed it should run.

The config.txt file is read by the system during starts up, after it is powered on. (Which means after modifying this file, the Pi has to be restarted.)  If the Pi won’t boot with your new settings, simply deleting the file config.txt (on another PC)  from the /boot directory should be enough to restore the default settings.

Boot Options

In config.txt, with below settings, it is possible to control the boot process:

• disable_commandline_tags   <--start.elf will skip memory locations past 0x100 before loading the kernel.

• cmdline                    <--replacing cmdline.txt

• kernel                     <--name of the kernel file to be loaded

• ramfsfile                  <--the name of the initial RAM file system (RAMFS) to be loaded.

• init_uart_baud             <--the speed of the serial console, in bits per second. (default is 115200)

Overclocking - Overvoltage

The config.txt file allows to alter the speed at which the chip runs. (it is known as overclocking, which increase its performance, but it decreases the lifetime of the processor.)

The processor of the Pi is split into two parts: the central processor (CPU) and the graphics processor (GPU)

(CPU handles all the processing tasks while the GPU handles displaying things on the screen,)

Using config.txt, it is possible overclock one or both parts of the chip. You can also increase the speed at which the memory module—located on top of the chip in a package-on-package (PoP) mounting format—operates.

Disabling L2 Cache

The Pi’s processor has 128 KB of Layer 2 cache memory onboard. Although this memory is small, it is very fast and It is used to temporarily store (cache) data and instructions between the slower main memory and the processor to improve performance.

The chip on the Pi (BCM2835) originally was architected as a multimedia processor (targeted at set-top boxes), so this L2 cache is designed to be used by the GPU portion alone. Unlike a traditional processor, the CPU doesn’t have any L2 cache of its own. Using config.txt, you can allow the CPU portion to access the L2 cache memory. Because of the physical location of the cache (more far away from the CPU and more closer to the GPU), in some cases, this can improve performance, but in other cases, this can harm performance

Enabling the L2 cache on a distribution built for a standard Pi with cache disabled may result in strange and unwanted behaviour.

To switch the L2 cache on for CPU access, add the following line to the config.txt file: disable_l2cache=0

(To disable the CPU’s access to the cache memory, replace the 0 with a 1.)

Modifying the Display

Usually the connected TV or Monitor is detected automatically, but sometimes this automatic detection doesn’t work. If the Pi is connected to a TV and there’s nothing to see, you may need to override defaults settings. config.txt file can be used to improve or modify the video output like width and height of the dispplays, tv mode....

=========================

start.elf (memory partitioning

The config.txt file can control various feature of the Pi’s hardware except the memory partitioning of the central processing unit (CPU) and graphics processing unit (GPU).

The chip of the Pi is split into two sections: the general-purpose CPU and the graphics-oriented GPU. Both of these sections require memory to operate, meaning that the memory on the Raspberry Pi needs to be shared between the two. This split is controlled by a file called start.elf. Some choose to split the memory in half, equally for CPU and GPU, ensuring that the graphics hardware can perform to its fullest potential. Others allow the CPU to have a larger share in order to improve general-purpose performance. (Default settings is usually good.)

Some distributions include three copies of start.elf:

arm128_start.elf, arm192_start.elf, and arm224_start.elf. These three files are identical except the amount of memory reserved for the CPU. To change the Pi memory partitioning, remove (rename) start.elf from the /boot directory and replace the original file with one of these files. (Make sure you rename the file to start.elf, or the Pi won’t boot.)

When you next reboot the Pi, it will have more memory available to the ARM CPU. To check the amount of memory available, type "free".

================================

cmdline.txt - Software Settings

In addition to config.txt and start.elf, there’s another important text file in the /boot directory: cmdline.txt  This file contains the options passed to the Linux kernel as the Pi boots up. (It is called sometimes as the kernel mode line, as the content of the file is in 1 line.)

In a usual Linux distribution these options are passed to the kernel by a tool known as a bootloader, which has its own configursation file. On the Pi, these options are in  cmdline.txt and  these are read by the Pi at startup. Almost any kernel option can be written into this file, like the appearance of the console or which kernel is loaded. A

An example line (this should be written as one continuous line):

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait

dwg_otc.lpm_enable=0    <--it disables the On-The-Go (OTG) mode of its USB controller

console=ttyAMA0,115200  <--creates a serial console device (ttyAMA0) with given speed

kgdboc=ttyAMA0,115200   <--enables kernel debugging over serial console created above 

console=tty1            <--creates the console device tty1 (without this no screen would be available)

root=/dev/mmcblk0p2     <--tells to the kernel where it can find its root file system

rootfstype=ext4         <--it tells to the kernel what format the root partition was created

rootwait                <--tells the kernel, not boot until the device with root file system is not available

Typically cmdline.txt is not modified. It is created by the distribution maintainers specifically for that version of Linux. Any changes require a reboot.