Details of Boot from NAND

Stage 1: Processor ROM Code
Stage 1 is the execution of the OMAP2420 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 with the OMAP2420 device. If the ROM code
does not support a particular NAND Flash device, contact a Texas Instruments representative
to determine if additional ROM code is available that will support the Micron
NAND Flash device.
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 (see
Figure 2) to the NAND Flash device, followed by a READ ID (90h) command (see Figure 3
on page 5). The READ ID operation enables the OMAP2420 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 X-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 OMAP2420 processor ROM code performs a badblock
check on these blocks.
Block 0 of the MT29F1G08ABB device is guaranteed to be good for 1,000 PROGRAM/
ERASE cycles, so in the majority of cases, the ROM code will not have to look beyond
block 0 for a bootable image.
Code Shadowing to the OMAP Processor SRAM
After the NAND Flash device configuration has been verified and the bad blocks have
been checked, the process of copying (shadowing) the X-Loader from the NAND Flash
device to the internal SRAM of the OMAP2420 processor begins.
First, the ROM code reads bytes 1 through 4 of the X-Loader to determine the size of the
file; then it reads bytes 5 through 8 of the X-Loader, which contain the destination
address in SRAM where the X-Loader will be shadowed (see Figure 6 on page 8). The
ROM code then shadows the X-Loader from the NAND Flash device to the OMAP2420
processor SRAM (see Figure 4), and finally, the system jumps to the SRAM address where
the first byte of the X-Loader is stored.
Error Correction Code
The ROM code contains error correction code and checks for errors in the X-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 X-Loader
is stored in the NAND Flash. It is important to remember that this X-Loader is executed
in the OMAP processor SRAM, so the image must fit in the available SRAM.
In a Linux-based system, the stage 2 boot consists of an X-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)
Building the X-Loader
Building the X-Loader is a critical step in developing a boot-from-NAND system.
Figure 5 on page 8 shows the process for converting source code to a raw binary
X-Loader that can be stored in the Micron NAND Flash device. The “Boot_image” prefix
in the file names is provided only as an example; actual file names can be designated by
the system designer. Figure 6 on page 8 illustrates how the Boot_image.bin code is laid
out in the NAND Flash.
1. Compile the X-Loader source code into an executable format. The example in
Figure 5 on page 8 shows how the source code comprises Boot_image.c and
Boot_image.h; the executable is Boot_image.out.
2. Execute the OST Tools to sign the target file Boot_image.out. When this process is
complete, an 8-byte header is included in the Boot_image.ift file. Bytes 1 through 4 of
Boot_image.ift contain the file size. Bytes 5 through 8 contain the OMAP processor
SRAM address where the X-Loader will be loaded and executed (see Figure 6 on
page 8). OST Tools are available from TI. (See OST Tools documentation for additional
details.)
3. Format the Boot_image.ift file resulting from step 2 for 2KB/page NAND Flash. Code
must be developed for this purpose if it is not available from TI.
To format the Boot_image.ift file, calculate the ECC for each 512-byte sector. Then
store the result in the appropriate area of the file. See Figure 7 on page 9 for boot code,
bad block marking, and ECC storage in a typical page of an MT29F1G08ABB NAND
Flash device programmed for boot-from-NAND in an OMAP2420-based system.
4. Program a copy of the Boot_image.bin file to each of the first four good blocks of the
NAND Flash device. The MT29F1G08ABB device identifies a good block as one that
has 0xFF data at byte 0x800 in both page 0 and page 1.
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 (128KB) of the Micron MT29F1G08ABB 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.
Stage 4: Operating System
The final stage of the boot process involves the initial execution of the OS. The operating
system kernel is stored in NAND Flash and shadowed to DRAM for execution as
described in the stage 3 boot description. When the system jumps to the beginning of
the OS code (see Figures 10), the OS takes control of the system.
Writing Binary Images to NAND Flash with Limited OST Tools Support
Some versions of the OST Tools do not fully support Micron NAND Flash devices. In
these cases, it is necessary to develop an alternative method for loading the boot code
into the NAND Flash device. A workstation similar to the one shown in Figure 11 is
required. In addition, modified X-Loader and U-Boot software are required. Contact
your Micron representative for the modified software.

Thứ Năm, 23 tháng 6, 2011 08:44 Đọc tiếp >>

Boot Stages in Boot from NAND

Stage 1: Processor ROM Code
During power-on, or after a RESET operation, the OMAP2420 processor runs its internal
ROM code. Note that only NAND Flash devices supported by the OMAP2420 processor
ROM can be used for the boot process (see Table 2 on page 4).
Stage 2: Bootstrap
X-Loader is an example of stage 2 bootstrap code. The X-Loader code is stored in the
NAND Flash, and the ROM code copies it to the OMAP 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; in this case U-Boot is the boot loader code. 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.

Thứ Năm, 23 tháng 6, 2011 08:41 Đọc tiếp >>

Boot from NAND

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 technical note discusses a boot-from-NAND solution for applications using the
Texas Instruments™ (TI) OMAP2420 processor and the Micron® MT29F1G08ABB
NAND Flash device. The technical note provides a four-stage boot sequence. Stages 1
and 2 are independent of the operating system (OS); however, they are highly dependent
on system hardware. Thus, the primary focus of this technical note is on stage 1 and
stage 2 boot processes.
Additional system details:
• TI OMAP2420 H4 with processor daughter card “Menelaus ES 2.0”;
S/N: 750-0006, Rev C.
• The boot-from-NAND concepts discussed are OS independent; however, the Linux
OS is used as an example in some explanations.
Note that secure booting via the OMAP™ high-security (HS) device is not in the scope of
this document. However, NAND Flash booting for HS and GP differs only in the generation
of the X-Loader. Thus, the solution discussed here is generally applicable to both
the HS and GP processors.

Thứ Năm, 23 tháng 6, 2011 08:38 Đọc tiếp >>

Make U-Boot

• Check the target boards supported by U-Boot
• Config your target board – smdk2410 as an example
• Make u-boot
:
smdk2410_config : unconfig
@./mkconfig $(@:_config=) arm arm920t smdk2410 NULL s3c24x0
:
vi /u-boot-1.1.2/makefile
[root@test u-boot-1.1.2]# make smdk2410_config
Configuring for smdk2410 board ….
[root@test u-boot-1.1.2]# make
:
-Map u-boot.map –o u-boot
arm-linux-objcopy --gap-fill=0xff –O srec u-boot u-boot.srec
arm-linux-objcopy --gap-fill=0xff –O binary u-boot u-boot.bin

Thứ Năm, 23 tháng 6, 2011 08:36 Đọc tiếp >>

Bootloader Overview

• Bootstrapping
– When system is powered on, the first piece of code (called bootstrapping)
initializes basic hardware and then bring up OS kernel.
– It can be included in a bootloader, or in OS directly.
• Bootloader Selection
– The Processor architectures and platforms that it supports
– The OS that it supports
– Debugging abilities, Stability and Portability
– Functionalities:
• simple bootup, or with monitoring capability and lots of drivers support.
– The medium they are installed in
• usually ROM, EEPROM or Flash
– The storage device from which the kernel image is downloaded
• host PC, local Flash, disk, CF, etc.
– The device and protocol by which the kernel image is transmitted
• Serial port, USB, ethernet, IDE, etc.
– The 'host-side' software used to transmit the kernel image
• if it is coming from an external device/machine.
– 'sleep' reset support
• Not to do a normal reboot if this was a sleep wakeup.

Thứ Năm, 23 tháng 6, 2011 08:34 Đọc tiếp >>

ARM Architecture Overview(II)

Thứ Năm, 23 tháng 6, 2011 08:32 Đọc tiếp >>

ARM Architecture Overview(I)

• ARM Operating Modes
– User mode: a normal program execution state
– FIQ – Fast Interrupt: for fast interrupt handling
– IRQ – Normal Interrupt: for general purpose interrupt handling
– Supervisor mode (SVC): a protected mode for operating system
– Abort mode: when a data or instruction pre-fetch is aborted
– Undefined mode: when an undefined instruction is executed
– System mode: a privileged user mode for the operating system
• ARM Processor States
– Arm state: all instructions are 32bits long, word-aligned.
– Thumb state: all instructions are 16 bits wide, half-word aligned.
– Jazelle state: all instructions are 8 bits wide for Java Bytecode
(for v5TEJ only)
• ARM Exception Types
– Reset
• Hardware reset: when the processor reset pin is asserted
• Software reset: by branching to the reset vector (0x0000)
– Undefined instruction
• the processor cannot recognize the currently execution instruction
– Software Interrupt (SWI)
• By s/w instruction, to allow a program running in User mode to
request privileged operations that are in Supervisor mode
– Prefetch Abort
• Fetch an instruction from an illegal address
– Data Abort
• A data transfer instr. try to load or store data at an illegal address
– IRQ: The processor IRQ pin is asserted and the I bit in CPSR is clear
– FIQ: The processor FIQ pin is asserted and the F bit in CPSR is clear

Thứ Năm, 23 tháng 6, 2011 08:28 Đọc tiếp >>