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.
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.
0 nhận xét:
Đăng nhận xét