When the power is first applied to the Raspberry Pi, or it has been reset (for more information, see the “Reset” section in Chapter 3 of Raspberry Pi Hardware Reference [Apress, 2014]), a boot sequence is initiated. As you will see in this chapter, it is the GPU that actually brings up the ARM CPU.

The way that the Raspberry Pi is designed, it must be booted from firmware found on the SD card. It cannot boot from any other source. RISC code for the GPU is provided by the Raspberry Pi Foundation in the file bootcode.bin.

After the second-stage boot loader has been executed, it is possible that other operating systems or ARM boot loaders such as U-Boot can be initiated.

Booting ARM Linux

Generally speaking, Linux under the ARM architecture needs a small amount of assistance to get started. The following are some of the minimal things that the boot loader needs to do:²⁵

1. Initialize and configure memory (with MMU, cache, and DMA disabled)
2. Load the kernel image into memory
3. Optionally, load an initial RAM disk image
4. Initialize and provide boot parameters to the loaded kernel (ATAG list)
5. Obtain/determine the Linux machine type (MACH_TYPE)
6. Execute the kernel image with the correct starting register values (r1 = machine number, r2 points to the ATAG list)
7. Additionally, the boot loader is expected to perform some initialization of a serial and/or video console.

In the Raspberry Pi, this boot-loading assistance comes from the embedded GPU in the SoC. The GPU supports a small RISC core that is able to run from initial code found in its ROM. From this small amount of code, the GPU is able to initialize itself and the SD card hardware. From the media on the SD card, it is able to bootstrap itself the rest of the way. For this reason, the Raspberry Pi must always bootstrap from an SD card.

Boot Sequence

This section looks at the startup sequence in greater detail. The participating hardware components, the files and data elements are considered. The boot procedure consists of the following sequence of events:

1. At power-up (or reset), the ARM CPU is offline.²³
2. A small RISC core in the GPU begins to execute SoC ROM code (first-stage boot loader).
3. The GPU initializes the SD card hardware.
4. The GPU looks at the first FAT32 partition in the SD media. (There remains some question about specific limitations as Broadcom has documented this—for example, can it boot from a first FAT16 partition?)
5. The second-stage boot-loader firmware named bootcode.bin is loaded into the GPU.
6. The GPU control passes to the loaded bootcode.bin firmware (SDRAM is initially disabled).
7. The file start.elf is loaded by the GPU into RAM from the SD card.
8. An additional file, fixup.dat, is used to configure the SDRAM partition between GPU and ARM CPU.
9. The file config.txt is examined for configuration parameters that need to be processed.
10. Information found in cmdline.txt is presumably also passed to start.elf.
11. The GPU allows the ARM CPU to execute the program start.elf.
12. The module start.elf runs on the ARM CPU, with information about the kernel to be loaded.
13. The kernel is loaded, and execution control passes to it.

Boot Files

The FAT32 partition containing the boot files is normally mounted as /boot, after Raspbian Linux has come up. Table 2-1 lists the files that apply to the boot process. The text files can be edited to affect new configurations. The binary files can also be replaced by new revisions of the same.

config.txt

The config.txt file permits you to configure many aspects of the boot process. Some options affect physical devices, and others affect the kernel being loaded.

Composite Video Settings

The composite video output from the Raspberry Pi is primarily configured by three basic parameters:

• sdtv_mode
• sdtv_aspect
• sdtv_disable_colourburst

Standard Definition Video

The parameter sdtv_mode determines the video mode (TV standard) of the composite video output jack.

Composite Aspect Ratio

The sdtv_aspect parameter configures the composite video aspect ratio.

Color Burst

By default, color burst is enabled. This permits the generation of color out of the composite video jack. Setting the video for monochrome may be desirable for a sharper display.

High-Definition Video

This section covers config.txt settings that affect HDMI operation.

HDMI Safe Mode

The hdmi_safe parameter enables support of automatic HDMI configuration for optimal compatibility.

When hdmi_safe=1 (enabled), the following settings are implied:

• hdmi_force_hotplug=1
• config_hdmi_boost=4
• hdmi_group=1
• hdmi_mode=1
• disable_overscan=0

HDMI Force Hot-Plug

This configuration setting allows you to force a hot-plug signal for the HDMI display, whether the display is connected or not. The NOOBS distribution enables this setting by default.

HDMI Ignore Hot-Plug

Enabling the hdmi_ignore_hotplug setting causes it to appear to the system that no HDMI display is attached, even if there is. This can help force composite video output, while the HDMI display is plugged in.

HDMI Drive

This mode allows you to choose between DVI (no sound) and HDMI mode (with sound, when supported).

HDMI Ignore EDID

Enabling this option causes the EDID information from the display to be ignored. Normally, this information is helpful and is used.

HDMI EDID File

When hdmi_edid_file is enabled, the EDID information is taken from the file named edid.txt. Otherwise, it is taken from the display, when available.

HDMI Force EDID Audio

Enabling this option forces the support of all audio formats even if the display does not support them. This permits pass-through of DTS/AC3 when reported as unsupported.

Avoid EDID Fuzzy Match

Avoid fuzzy matching of modes described in the EDID.

HDMI Group

The hdmi_group option defines the HDMI type.

HDMI Mode

This option defines the screen resolution to use in CEA or DMT format (see the parameter hdmi_group in the preceding subsection “HDMI Group”). In Table 2-2, the modifiers shown have the following meanings:

• H means 16:9 variant of a normally 4:3 mode.
• 2x means pixel doubled (higher clock rate).
• 4x means pixel quadrupled (higher clock rate).
• R means reduced blanking (fewer bytes are used for blanking within the data stream, resulting in lower clock rates).

HDMI Boost

The config_hdmi_boost parameter allows you to tweak the HDMI signal strength.

HDMI Ignore CEC Init

When this option is enabled, the CEC initialization is not sent to the device. This avoids bringing the TV out of standby and channel switch when rebooting.

HDMI Ignore CEC

When this option is enabled, the assumption made is that CEC is not supported at all by the HDMI device, even if the device does have support. As a result, no CEC functions will be supported.

Overscan Video

A few options control the overscan support of the composite video output. When overscan is enabled, a certain number of pixels are skipped at the sides of the screen as configured.

Disable Overscan

The disable_overscan option can disable the overscan feature. It is enabled by default:

Overscan Left, Right, Top, and Bottom

These parameters control the number of pixels to skip at the left, right, top, and bottom of the screen.

Frame Buffer Settings

The Linux frame buffer support is configured by a few configuration options described in this section.

Frame Buffer Width

The default is to define the width of the frame buffer as the display’s width minus the overscan pixels.

Frame Buffer Height

The default is to define the height of the frame buffer as the display’s height minus the overscan pixels.

Frame Buffer Depth

This parameter defines the number of bits per pixel.

Frame Buffer Ignore Alpha

The alpha channel can be disabled with this option. As of this writing, this option must be used when using a frame buffer depth of 32 bits.

General Video Options

The display can be flipped or rotated in different ways, according to the display_rotate option. You should be able to do both a flip and a rotate by adding the flip values to the rotate value.

The 90º and 270º rotations require additional memory on the GPU, so these options won’t work with a 16 MB GPU split.

While the flip options are documented, I was unable to get them to work. The rotations, however, were confirmed as working.

Licensed Codecs

The following options permit you to configure the purchased license key codes for the codecs they affect.

Testing

The following test option enables image/sound tests during boot. This is intended for manufacturer testing.

Memory

This section summarizes configuration settings pertaining to memory.

Disable GPU L2 Cache

The disable_l2cache option allows the ARM CPU access to the GPU L2 cache to be disabled. This needs the corresponding L2 disabled in the kernel.

GPU Memory (All)

The gpu_mem option allows configuration of the GPU memory for all Raspberry Pi board revisions (unless gpu_mem_256 or gpu_mem_512 is supplied).

GPU Memory (256)

The gpu_mem_256 option allows configuration of the GPU memory for the 256 MB Raspberry Pi boards. When specified, it overrides the gpu_mem option setting.

GPU Memory (512)

The gpu_mem_512 option configures the GPU memory allocated for the 512 MB Raspberry Pi boards. When specified, it overrides the gpu_mem option setting.

Boot Options

Several options in this section affect the boot process. Many options pertain to the kernel being started, while others affect file systems and devices.

Disable Command-Line Tags

The disable_commandline_tags option permits the user to prevent start.elf from filling in ATAGS memory before launching the kernel. This prevents the cmdline.txt file from being supplied to the kernel at boot time.

Command Line

The cmdline option allows you to configure the kernel command-line parameters within the config.txt file, instead of the cmdline.txt file.

Kernel

By default, start.elf loads the kernel from the file named kernel.img. Specifying the kernel parameter allows the user to change the file’s name.

Kernel Address

This parameter determines the memory address where the kernel image is loaded into.

RAM File System File

The ramfsfile parameter names the file for the RAM FS file, to be used with the kernel.

RAM File System Address

The ramfsaddr parameter specifies where the RAM file system image is to be loaded into memory.

Init RAM File System

This option is a convenience option, which combines the options ramfsfile and ramfsaddr.

Device Tree Address

The device_tree_address option defines where the device tree address is loaded.

Init UART Baud

The init_uart_baud option allows the user to reconfigure the serial console to use a baud rate that is different from the default.

Init UART Clock

The init_uart_clock parameter permits the user to reconfigure the UART to use a different clock rate.

Init EMMC Clock

The init_emmc_clock parameter allows the user to tweak the EMMC clock, which can improve the SD card performance.

Boot Delay

The boot_delay and boot_delay_ms options allow the user to reconfigure the delay used by start.elf prior to loading the kernel. The actual delay time used is computed from the following:

where

• D is the computed delay in milliseconds.
• b is the boot_delay value.
• m is the boot_delay_ms value.

The boot_delay_ms augments the boot_delay parameter.

Avoid Safe Mode

A jumper or switch can be placed between pins P1-05 (GPIO 1) and P1-06 (ground) to cause start.elf to initiate a safe mode boot. If GPIO 1 is being used for some other I/O function, the safe mode check should be disabled.

Overclocking

According to the Raspberry Pi Configuration Settings file, Revision 14 (http://elinux.org/RPi_config.txt) the ARM CPU, SDRAM, and GPU have their own clock signals (from a PLL). The GPU core, H.264, V3D, and ISP all share the same clock.

The following commands can be used to check your CPU, once you have a command-line prompt. The /proc/cpuinfo pseudo file will give you a BogoMIPS figure:

$ cat /proc/cpuinfo
Processor        : ARMv6−compatible processor rev 7 (v6l)
BogoMIPS         : 697.95
Features         : swp half thumb fastmult vfp edsp java tls
CPU implementer  : 0x41
CPU architecture : 7
CPU variant      : 0x0
CPU part         : 0xb76
CPU revision     : 7
Hardware         : BCM2708
Revision         : 000f
Serial           : 00000000 f52b69e9
$

The vcgencmd can be used to read the ARM CPU clock frequency:

$ vcgencmd measure_clock arm
frequency (45)=700074000
$

To configure for overclocking, you start with the phase-locked loop (PLL). The PLL frequency is computed as follows:

where

• p is the computed PLL frequency.
• c is the core frequency.

From this, the GPU frequency multiple m is computed from a trial GPU frequency t as follows:

The value m is then rounded to the nearest even integer value, and the final GPU frequency g is computed as follows:

If we take an example where the core frequency c is 500 MHz, then p is determined as follows:

Further, if we are targeting a GPU frequency of 300 MHz, we compute m:

The value m is rounded to the nearest even integer:

The final GPU frequency becomes

The example GPU clock is 333.33 MHz.

Table 2-3 lists the standard clock profiles, as provided by the Raspberry Pi Foundation. Additionally, it is stated that if the SoC reaches temp_limit, the overclock settings will be disabled. The value of temp_limit is configurable.

Warranty and Overclocking

At one time, overclocking could void your warranty. Also note that Internet forum users have reported SD card corruption when trying out overclocked configurations (though several improvements to SD card handling have been made). Be sure to back up your SD card.

The following combination of parameters may set a permanent bit in your SoC chip and void your warranty. While the Raspberry Pi announcement (www.raspberrypi.org/introducing-turbo-mode-up-to-50-more-performance-for-free/) speaks of overclocking without voiding the warranty, it is subject to some conditions like using the cpufreq driver. The following conditions may put your warranty in jeopardy:

• ver_voltage > 0, and at least one of the following:
• force_turbo = 1
• current_limit_override = 0x5A000020
• temp_limit > 85

Force Turbo Mode

The documentation indicates that force_turbo has no effect if other overclocking options are in effect.

By default, force_turbo is disabled. When disabled, it disables some other configuration options such as h264_freq. However, enabling force_turbo also enables h264_freq, v3d_freq, and isp_freq.

Initial Turbo

The initial_turbo option is described in config.txt as “enables turbo mode from boot for the given value in seconds (up to 60).” This is somewhat confusing.

What is meant is that turbo mode will be enabled after a delay of a configured number of seconds after boot. By default, if turbo mode is enabled, it is enabled immediately (after examining config.txt).

The initial_turbo option allows the boot process to proceed at normal clock rates until the process has progressed to a certain point. Some people on Internet forums that experience SD card corruption from overclocking will suggest the initial_turbo option as a solution.

Temperature Limit

The temp_limit configuration option allows the user to override the default safety limit. Increasing this value beyond 85ºC voids your warranty.

When the SoC temperature exceeds temp_limit, the clocks and voltages are set to default values for safer operation.

ARM CPU Frequency

The parameter arm_freq sets the clock frequency of the ARM CPU in MHz. This option applies in non-turbo and turbo modes.

Minimum ARM CPU Frequency

This option can be used when using dynamic clocking of the ARM CPU. This sets the lowest clock speed for the ARM.

GPU Frequency

The gpu_freq option determines the following other values:

The gpu_freq parameter has the following default value:

Core Frequency

The core_freq option allows the user to configure the GPU processor core clock. This parameter also affects the ARM performance, since it drives the L2 cache.

Minimum Core Frequency

When dynamic clocking is used, this sets the minimum GPU processor core clock rate. See also the core_freq option. Like the core_freq option, this parameter affects the ARM performance, since it drives the L2 cache.

H.264 Frequency

This parameter configures the frequency of the video block hardware. This parameter applies when force_turbo mode is enabled.

ISP Frequency

This parameter configures the image sensor pipeline clock rate and applies when force_turbo mode is enabled.

V3D Frequency

The v3d_freq configures the 3D block frequency in MHz. This parameter applies when force_turbo mode is enabled.

SDRAM Frequency

The sdram_freq parameter allows the user to configure frequency of the SDRAM.

Minimum SDRAM Frequency

When dynamic clocks are used, the sdram_freq_min allows the user to configure a minimum clock rate in MHz.

Avoid PWM PLL

The avoid_pwm_pll configuration parameter allows the user to unlink the core_freq from the rest of the GPU. A Pi configuration note states, “analog audio should still work, but from a fractional divider, so lower quality.”

Voltage Settings

The configuration parameters in this subsection configure voltages for various parts of the Raspberry Pi.

Current Limit Override

When supplied, the switched-mode power supply current limit protection is disabled. This can be helpful with overclocking if you are encountering reboot failures.

Over Voltage

The ARM CPU and GPU core voltage can be adjusted through the over_voltage option. Use the values shown in Table 2-4.

Over Voltage Minimum

The over_voltage_min option can be used when dynamic clocking is employed, to prevent the voltage dropping below a specified minimum. Use the values from Table 2-4.

Over Voltage SDRAM

The over_voltage_sdram configuration option is a convenient way to set three options at once:

• over_voltage_sdram_c: SDRAM controller voltage
• over_voltage_sdram_i: SDRAM I/O voltage adjust
• over_voltage_sdram_p: SDRAM physical voltage adjust

Raspberry Pi documentation says the over_voltage_sdram option “sets over_ voltage_sdram_c, over_voltage_sdram_i, over_voltage_sdram_p together.” Use the values shown in Table 2-4.

SDRAM Controller Voltage

Use the over_voltage_sdram_c option to set the voltage for the SDRAM controller. Use the values shown in Table 2-4. See also the over_voltage_sdram option.

SDRAM I/O Voltage

Use the over_voltage_sdram_i option to set the voltage for the SDRAM I/O subsystem. Use the values shown in Table 2-4. See also the over_voltage_sdram option.

SDRAM Physical Voltage

The over_voltage_sdram_p option adjusts the “physical voltage” for the SDRAM subsystem. Use the values shown in Table 2-4. See also the over_voltage_sdram option.

cmdline.txt

The cmdline.txt file is used to supply command-line arguments to the kernel. The Raspbian values supplied in the standard image are broken into multiple lines here for easier reading (note that the NOOBS distribution may show a different device for the root file system):

$ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 
 console=ttyAMA0,115200 
 kgdboc=ttyAMA0,115200 
 console=tty1 
 root=/dev/mmcblk0p2 
 rootfstype=ext4 
 elevator=deadline 
 rootwait
$

This file is provided as a convenience, since the parameters can be configured in the config.txt file, using the cmdline="text" option. When the config.txt option is provided, it supersedes the cmdline.txt file.

Once the Raspbian Linux kernel comes up, you can review the command-line options used as follows (edited for readability):

$ cat /proc/cmdline
 dma.dmachans=0x7f35 
 bcm2708_fb.fbwidth=656 
 bcm2708_fb.fbheight=416 
 bcm2708.boardrev=0xf 
 bcm2708.serial=0xf52b69e9 
 smsc95xx.macaddr=B8:27:EB:2B:69:E9 
 sdhci−bcm2708.emmc_clock_freq=100000000 
 vc_mem.mem_base=0x1c000000 
 vc_mem. mem_size=0x20000000 
 dwc_otg.lpm_enable=0 
 console=ttyAMA0,115200 
 kgdboc=ttyAMA0,115200 
 console=tty1 
 root=/dev/mmcblk0p2 
 rootfstype=ext4 
 elevator=deadline 
 rootwait
$

Additional options can be seen prepended to what was provided in the cmdline.txt file. Options of the format name.option=values are specific to kernel-loadable modules. For example, the parameter bcm2708_fb.fbwidth=656 pertains to the module bcm2708_fb.

There are too many Linux kernel parameters to describe here (entire books have been written on this topic), but some of the most commonly used ones are covered in the following subsections.

Serial console=

The Linux console parameter specifies to Linux what device to use for a console. For the Raspberry Pi, this is normally specified as follows:

console=ttyAMA0,115200

This references the serial device that is made available after boot-up as /dev/ttyAMA0. The parameter following the device name is the baud rate (115200).

The general form of the serial console option is as follows:

console=ttyDevice,bbbbpnf

The second parameter is the options field:

Virtual console=

Linux supports a virtual console, which is also configurable from the console= parameter. Raspbian Linux specifies the following:

console=tty1

This device is available from /dev/tty1, after the kernel boots up. The tty parameters used for this virtual console can be listed (edited here for readability):

$ sudo −i
# stty −a </dev/tty1
speed 38400 baud ; rows 26; columns 82; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; 
eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^Q; stop = ^S ; susp = ^Z; rprnt = ^R; werase = ^W; 
lnext = ^V; flush = ^O; min = 1; time = 0;
−parenb −parodd cs8 hupcl −cstopb cread −clocal −crtscts
−ignbrk brkint −ignpar −parmrk −inpck −istrip −inlcr 
−igncr icrnl ixon −ixoff −iuclc −ixany imaxbel iutf8
opost −o lcuc −ocrnl onlcr −onocr −onlret −ofill −ofdel 
nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok −echonl −noflsh 
−xcase −tostop −echoprt −echoctl echoke
#

kgdboc=

The kgdboc parameter was named after the idea “kgdb over console.” This allows you to use a serial console as your primary console as well as use it for kernel debugging. The primary console, however, need not be a serial console for kgdboc to be used.²⁷

The Raspbian image supplies this:

kgdboc=ttyAMA0,115200

This allows kernel debugging to proceed through serial device /dev/ttyAMA0, which is the only serial device supported on the Raspberry Pi.

root=

The Linux kernel needs to know what device holds the root file system. The standard Raspbian image supplies the following:

root=/dev/mmcblk0p2

This points the kernel to the SD card (mmcblk0), partition 2 (non-NOOBS distribution). See also the rootfstype parameter.

The general form of the root= parameter supports three forms:

• root=MMmm: Boot from major device MM, minor mm (hexadecimal).
• root=/dev/nfs: Boot a NFS disk specified by nfsroot (see also nfs-root= and ip=).
• root=/dev/name: Boot from a device named /dev/name.

rootfstype=

In addition to specifying the device holding the root file system, the Linux kernel sometimes needs to know the file system type. This is configured through the rootfstype parameter. The standard Raspbian image supplies the following:

rootfstype=ext4

This example indicates that the root file system is the ext4 type.

The Linux kernel can examine the device given in the root parameter to determine the file system type. But there are scenarios where the kernel cannot resolve the type or gets confused. Otherwise, you may want to force a certain file system type. Another situation is when MTD is used for the root file system. For example, when using JFFS2, it must specified.

elevator=

This option selects the I/O scheduler scheme to be used within the kernel. The standard Raspbian image specifies the following:

elevator=deadline

To find out the I/O scheduler option being used and the other available choices (in your kernel), we can consult the /sys pseudo file system:

$ cat /sys/block/mmcblk0/queue/scheduler
noop [deadline] cfq
$

The name mmcblk0 is the name of the device that your root file system is on. The output shows in square brackets that the deadline I/O scheduler is being used. The other choices are noop and cfq. These I/O schedulers are as follows:

The deadline I/O scheduler is the newest implementation, designed for greater efficiency and fairness. The deadline scheduler uses a cyclic elevator, except that it additionally logs a deadline for the request. A cyclic elevator is one where the requests are ordered according to sector numbers and head movement (forward and backward). The deadline scheduler will use the cyclic elevator behavior, but if it looks like the request is about to expire, it is given immediate priority.

rootwait=

This option is used when the device used for the root file system is a device that is started asynchronously with other kernel boot functions. This is usually needed for USB and MMC devices, which may take extra time to initialize. The rootwait option forces the kernel to wait until the root device becomes ready.

Given that the root file system is on the SD card (a MMC device), the Raspbian image uses the following:

rootwait

nfsroot=

The nfsroot option permits you to define a kernel that boots from an NFS mount (assuming that NFS support is compiled into the kernel). The square brackets show placement of optional values:

nfsroot=[server−ip:]root−dir[,nfs−options]

When unspecified, the default of /tftpboot/client_ip_address will be used. This requires that root=/dev/nfs be specified and optionally ip= may be added.

To test whether you have NFS support in your kernel, you can query the /proc file system when the system has booted:

$ cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   cgroup
nodev   tmpfs
nodev   devtmpfs
nodev   debugfs
nodev   sockfs
nodev   pipefs
nodev   anon_inodefs
nodev   rpc_pipefs
nodev   configfs
nodev   devpts
        ext3
        ext2
        ext4
nodev   ramfs
        vfat
        msdos
nodev   nfs
nodev   nfs4
nodev   autofs
nodev   mqueue

From this example, we see that both the older NFS (nfs) and the newer NFS4 file systems are supported.

ip=

This option permits the user to configure the IP address of a network device, or to specify how the IP number is assigned. See also the root= and nfsroot= options.

ip=client−ip:server−ip:gw−ip:netmask:hostname:device:autoconf

Table 2-5 describes the fields within this option. The autoconf value can appear by itself, without the intervening colons if required. When ip=off or ip=none is given, no autoconfiguration takes place. The autoconfiguration protocols are listed in Table 2-6.

Emergency Kernel

In the event that your Raspberry Pi does not boot up properly, an emergency kernel is provided in /boot as file kernel_emergency.img. This kernel includes a BusyBox root file system to provide recovery tools. Through use of e2fsck, you’ll be able to repair your normal Linux root file system. If necessary, you’ll be able to mount that file system and make changes with the BusyBox tools.

To activate the emergency kernel, mount your SD card in a Linux, Mac, or Windows computer. Your computer should see the FAT32 partition, allowing you to rename files and edit configurations. Rename your current kernel.img to something like kernel.bak (you likely want to restore this kernel image later). Then rename kernel_emergency.img as kernel.img.

If you have used special configuration options in config.txt and cmdline.txt, you should copy these to config.bak and cmdline.bak, respectively. Then remove any special options that might have caused trouble (especially overclocking options). Alternatively, you can restore original copies of these two files, as provided by the standard Raspbian image download.

The entire procedure is summarized here:

1. Rename kernel.img to kernel.bak (retain the normal kernel).
2. Rename kernel_emergency.img to kernel.img.
3. Copy config.txt to config.bak.
4. Copy cmdline.txt to cmdline.bak.
5. Edit or restore config.txt and cmdline.txt to original or safe configurations.

Step 5 requires your own judgment. If you have customized hardware, there may be some nonstandard configuration settings that you need to keep (see the previous “Avoid Safe Mode” section). The idea is to simply give your emergency kernel as much chance for success as possible. Disabling all overclocking options is also recommended.

With the kernel exchanged and the configuration restored to safe options, it should now be possible to boot the emergency kernel. Log in and rescue.

To restore your system back to its normal state, you’ll need to follow these steps:

1. Rename kernel.img to kernel_emergency.img (for future rescues).
2. Rename kernel.bak to kernel.img (reinstate your normal kernel).
3. Restore/alter your config.txt configuration, if necessary.
4. Restore/alter your cmdline.txt configuration, if necessary.

At this point, you can reboot with your original kernel and configuration.