Understanding Bootloader

Here we are going to talk about the boot process used in most of the Cellphones and other mobile devices.

Disclaimer: We (i.e. Arenoid Developers) do not take any kind of responsibility and action/reaction occurring/happening from the usage of the material presented in these pages. All the material is culled from different resources found on internet. The original author of the material remains the sole owner

NAND Boot Process

Overview
NAND Flash memory devices are designed for applications requiring nonvolatile, highdensity,
solid-state storage media. Historically, NAND Flash has been used extensively in
applications such as mass storage cards and digital cameras. With its low cost and high
performance, NAND Flash is beginning to make its way into more complex embedded
systems where NOR Flash has dominated in the past—for example, in mobile phones.
In complex embedded systems, one of the challenges associated with a change from
NOR Flash to NAND Flash has been the boot process. NOR Flash has been a popular
choice for these systems because it contains a traditional memory interface (including
both address and data buses), making it capable of execute-in-place (XIP) operation. XIP
memory enables the system CPU to execute code directly from the memory device
because the boot code is stored on and executed from a single device.
NAND Flash is a page-oriented memory device that does not inherently support XIP, at
least not in the same manner as a typical XIP memory device. Operating system and
boot code can be stored in NAND Flash memory, but the code must be copied (or shadowed)
to DRAM before it can be executed. This requires system designers to modify the
boot process for their systems when using NAND Flash. The payoff for this modification
is that the system benefits from the lower cost of NAND Flash as the storage solution and
the higher performance of DRAM as the XIP memory.

(This boot process doesn't hold true for Secure booting supprted by some Processors)

bootnand.JPG

Boot Stages

Stage 1: Processor ROM Code
During power-on, or after a RESET operation, the processor runs its internal
ROM code.

Stage 2: Bootstrap
TheBootstrap Loader code is stored in the NAND Flash, and the ROM code copies
it to the processor SRAM for execution.

Stage 3: Boot Loader
Stage 3 is the boot loader, which is used to copy the operating system code from the
NAND Flash to the DRAM. E.G. U-Boot. The U-Boot code is stored in NAND Flash,
and the stage 2 code copies it to the DRAM for execution.

Stage 4: Operating System
The OS code, such as the Linux kernel, is stored in the NAND Flash, and the stage 3 code
copies it to the DRAM, where it is executed. The boot process is complete after this stage
as the OS takes control of the system.

Stage 1: Processor ROM Code
Stage 1 is the execution of the processor ROM code. This ROM code cannot
be modified by the system designer. Only NAND Flash devices supported by the ROM
code can be used for boot-from-NAND.
After a power-on-reset is initiated, the ROM code reads the SYS.BOOT register to determine the memory interface configuration and programs the general-purpose memory
controller (GPMC) accordingly. Then the ROM code issues a RESET (FFh) command tto the NAND Flash device, followed by a READ ID (90h) command. The READ ID operation enables the processor to determine how the NAND Flash device is configured and whether this device is supported by the ROM code.

Bad Blocks
The ROM code expects the bootstrap loader to be in block 0, 1, 2, or 3 of the NAND Flash device and can use any of these blocks in the boot process. After the NAND Flash device configuration has been determined, the processor ROM code performs a bad block
check on these blocks.

Code Shadowing to the Processor SRAM
After the NAND Flash device configuration has been verified and the bad blocks have
been checked, the process of copying (shadowing) the bootstrap from the NAND Flash
device to the internal SRAM of the processor begins.
First, the ROM code reads bytes 1 through 4 of the bootstrap to determine the size of the
file; then it reads bytes 5 through 8 of the bootstrap loader, which contain the destination
address in SRAM where the bootstrap will be shadowed. The
ROM code then shadows the bootstrap from the NAND Flash device to the SRAM, and finally, the system jumps to the SRAM address where the first byte of the bootstrap Loader is stored.

Error Correction Code
The ROM code contains error correction code and checks for errors in the bootstrap loader. The ECC scheme is a Hamming code capable of detecting 2-bit errors and correcting one 1-bit error per 512 bytes.
• When a 1-bit error is detected in a 512-byte sector, the ROM code will use the ECC to correct the error, and the boot process will continue from that block.
• When a 2-bit error is detected in a 512-byte sector, the ROM code will skip this block and attempt to boot from the next block.
• When an error of 3 bits or more is detected, effects on the system may vary and may include hanging.

Stage 2: Bootstrap
Stage 2 of the boot process is dependent on NAND Flash in the sense that the bootstrap Loader is stored in the NAND Flash. It is important to remember that this BOOTSTRAP Loader is executed in the processor SRAM, so the image must fit in the available SRAM.
In a Linux bootstrap based system, the stage 2 boot consists of an BOOTSTRAP Loader that bootstraps U-Boot. This bootstrap includes:
• Information for each supported CPU architecture
• A configuration file for each supported board
• NAND Flash driver code
• Serial driver code (to support debug and development efforts)

Stage 3: Boot Loader
Stage 3 of the boot process is heavily dependent on the OS. In a Linux system, the stage 3
boot consists of U-Boot, the OS boot loader for Linux. U-Boot resides in the NAND Flash
but is shadowed to DRAM for execution (as mentioned in the stage 2 boot description).
U-Boot Considerations
• The memory map must be configured to support boot-from-NAND.
• U-Boot must contain NAND Flash support such that it can read and write to the
NAND Flash device.
• U-Boot environment data should be written such that it can be stored in a single
block NAND Flash device.
• The CFG_NAND_BOOT configuration label is stored in a board configuration file and
is used to differentiate NAND U-Boot from NOR U-Boot.
U-Boot shadows the OS kernel code from NAND Flash to DRAM and then
jumps to the address in DRAM where the first byte of the OS code is stored.

nandshadow.JPG
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License