NAND bad blocks

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(add actual bad block data from data sheet)
(Solution)
Line 30: Line 30:
 
  nand write.e
 
  nand write.e
 
command in [[u-boot]]
 
command in [[u-boot]]
 +
 +
=== Flash Tool ===
 +
 +
==== sjf2410 (during development) ====
 +
The [[sjf2410]] tool has a compile-time option to check (and skip) bad blocks.  If we use this for flashing u-boot, we will preserve the bad block info. 
 +
 +
==== for production? ====
 +
 +
I have no idea how flashing during the production process is supposed to happen.

Revision as of 13:38, 13 January 2007

Contents

Problem

NAND memory apparently gets shipped with blocks that are already bad. The vendor just marks those blocks as bad, thus resulting in higher yield and lower per-unit cost.

The only block that is guaranteed to be good, is the first block (first 16kBytes).

We are also guaranteed that a minimum of 4016 blocks (out of the 4096) are good. This means up to 80 blocks (320kBytes) can be dead.

Solution

The solution is split into various pieces

Boot loader

The boot loader itself contains a small first-stage boot loader for the S3C2410 Steppingstone.

This code (which Harald wrote in ARM assembly) needs to be altered to detect and skip bad blocks. At this time, the bootloader could itself extend over bad blocks. However, how do we first flash the bootloader into NAND? The JTAG flashing program has no support for detecting bad blocks.

Kernel

The kernel is contained in its own partiton QT2410#NAND. We have to flash it using the

nand write.e

command, and read it later again via

nand read.e

command. Those two variants (as opposed to their non-".e"-postfixed versions) simply skip bad blocks

Root Filesystem

The root filesystem uses JFFS2, which is already bad block tolerant. It, too, has to be written using the

nand write.e

command in u-boot

Flash Tool

sjf2410 (during development)

The sjf2410 tool has a compile-time option to check (and skip) bad blocks. If we use this for flashing u-boot, we will preserve the bad block info.

for production?

I have no idea how flashing during the production process is supposed to happen.

Personal tools

Problem

NAND memory apparently gets shipped with blocks that are already bad. The vendor just marks those blocks as bad, thus resulting in higher yield and lower per-unit cost.

The only block that is guaranteed to be good, is the first block (first 16kBytes).

We are also guaranteed that a minimum of 4016 blocks (out of the 4096) are good. This means up to 80 blocks (320kBytes) can be dead.

Solution

The solution is split into various pieces

Boot loader

The boot loader itself contains a small first-stage boot loader for the S3C2410 Steppingstone.

This code (which Harald wrote in ARM assembly) needs to be altered to detect and skip bad blocks. At this time, the bootloader could itself extend over bad blocks. However, how do we first flash the bootloader into NAND? The JTAG flashing program has no support for detecting bad blocks.

Kernel

The kernel is contained in its own partiton QT2410#NAND. We have to flash it using the

nand write.e

command, and read it later again via

nand read.e

command. Those two variants (as opposed to their non-".e"-postfixed versions) simply skip bad blocks

Root Filesystem

The root filesystem uses JFFS2, which is already bad block tolerant. It, too, has to be written using the

nand write.e

command in u-boot