DM368 DM365 NAND Bad Block Handling

From RidgeRun Developer Connection
Jump to: navigation, search

DM36x NAND support

The TMS320DM36x Digital Media System-on-Chip (DMSoC) ARM Subsystem User's Guide chapter 11 documents the DM36x boot process, including details on how the DM36x boots from NAND (section 11.2.1, pg 168).

The DM36x processor contains a built-in ROM Boot Loader (RBL). The RBL code can not be changed and only supports a fixed list of supported NAND chips. If your NAND chip isn't supported, you will not be able to use that chip to boot from NAND. See the TMS320DM368 Digital Media System-on-Chip (DMSoC) Silicon Revision 1.1 and 1.2 Silicon Errata for details.

Step 1: determine NAND characteristics

The RBL uses the NAND chip's device ID to look up the block size and page size in the RBL table of supported chips.

Step 2: locate a valid NAND UBL Descriptor

RBL searches block 1 though 24 for a NAND block that contains a valid NAND UBL Descriptor (as documented in table 109, pg 170).

Page 0 Address 32 bit value Description
0 0xA1ACEDxx Magic number
4 Entry Point Address of UBL Entry point address for the user bootloader (absolute address)
8 Number of pages in UBL Number of pages (size of user bootloader in number of pages)
12 Starting Block # of UBL Block number where user bootloader is present
16 Starting Page # of UBL Page number where user bootloader is present
20 PLL settings - M Multiplier PLL setting (if Magic Number indicates PLL enable)
24 PLL settings - N Divider PLL setting (if Magic Number indicates PLL enable)
28 Fast EMIF setting Fast EMIF settings (if Magic Number indicates fast EMIF boot)

RBL considers a NAND block to contain a valid NAND UBL Descriptor if (A) the OOB indicates the block is bad, (B) there is no unrecoverable ECC error, and (C) a valid Magic Number is found. The DM36x NAND ECC hardware can correct up to 4 bit errors in each 512 bytes read from NAND. See the

Step 3: read UBL into IRAM

RBL configures the PLL and EMIF according to the entries in the valid NAND UBL Descriptor. RBL then uses UBL location and size information from the NAND UBL Descriptor to load UBL into IRAM.

Step 4: handling UBL read errors

If RBL encounters an unrecoverable error reading the UBL from NAND, RBL considers the NAND UBL Descriptor invalid and continues its search for a valid NAND UBL Descriptor as described in step 2.

Step 5: running UBL

Once RBL has loaded a UBL into IRAM without encountering any fatal errors, RBL transfers control to UBL using the entry point specified in the NAND UBL Descriptor.

UBL NAND support

The User Boot Loader (UBL) is responsible for initial hardware configuration to the point that the U-Boot bootloader can be loaded into SDRAM and run.

UBL supports a NAND read page routine that uses the OOB information to skip bad NAND pages and to recover from up to 4 bit errors. TI makes the UBL source code available so you can refer to the source code to see the exact details.

UBL looks for a valid NAND Bootloader Descriptor in a similar way to RBL looking for a valid NAND UBL Descriptor, using a recovery to search for another NAND Bootloader Descriptor if an error is encountered when loading the bootloader from NAND.

The RidgeRun SDK uses the UBL included with the TI DVSDK with patches to check for the NAND blocks being marked bad and to handle the silicon issue listed in the DM36x chip errata.

U-Boot NAND support

U-Boot NAND commands

There are several u-boot commands to handle nand data transfers and bad block handling. In this section the most common are exposed.

NAND dump

This command displays the page of the nand chip in the given direction.

# nand dump 0x0 

NAND bad blocks

This command displays all the bad blocks on the whole NAND chips.

# nand bad 

Das U-Boot bootloader (U-Boot) also supports reading data from NAND, identifying bad pages and performing up to 4 bit error correction. In addition, U-Boot also writes to NAND, with the ability to save to NAND the following components:

  • UBL
  • U-Boot
  • U-Boot environment
  • Linux kernel
  • File systems

In order to write this elements, RidgeRun SDK uses U-boot's nand write(.ubl) and nand erase commands.

When bad blocks are found while executing a write command the block is skipped and data is written on the next block, however the erase command counts the bad block as part of the erased area. Here's an example with pseudo-code:

//Block 24 and 26 have data, while block 25 is bad
nand erase start:24 numblocks:2

In this case only block 24 will be really erased and block 25 is skipped but it will count as the second erased block.