nand write -->> This command directly does a raw write. ie it doesnt look

for bad blocks. and data might get written in the bad block

nand write.e -->> The NAND has the ecc, this command writes using the ecc blocks,

ie it skips bad blocks present in NAND to ensure data is not written to bad blocks.

nand write.jffs2 -->> This command to write jffs2 image to rootfs partition in NAND

Thx,

NAND basics


NAND memory has quite unique characteristics.

  • When it is erased, all bits are set to 1' (you will see 0xff on all bytes in a hexdump)
  • You can change as many bits as you want to '0'
  • You cannot set a bit back to '1' by using a regular write. You have to erase a whole erase block to do so
  • The number of erase cycles per block is limited. Once you have reached the limit, some bits will not get back to 0xff
    • In the case of the chip in the Neo1973, this is 100000 guaranteed per-block erase cycles.

NAND page

A NAND page consists of a number of data bytes (512 in the Neo1973 GTA01 case, 2048 in the GTA02 case) plus a number of out-of-band (OOB) bytes (GTA01: 16, GTA02: 64).

Only the data bytes are used for application data. The OOB bytes are used for

  • Marking an erase block as bad (first or second page of erase block)
  • Storing ECC (error correction codes)
  • Storing filesystem specific information (JFFS2)

NAND erase block

A erase block consists of multiple pages. In the Neo1973 GTA01 case, every erase block has 32 pages, resulting in 16kBytes (hex: 0x4000) of data bytes (without OOB). GTA02 has 128kByte large erase blocks.

Problem

Bad Blocks

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 flash contains four kinds of blocks (16kBytes):

  • Factory-Default bad blocks
    • Samsung marks the 6th OOB byte as non 0xFF in the first and/or second page in blocks that are bad
  • Worn-out bad blocks
  • Good blocks
  • The first block.
    • This block is guaranteed to not require error correction up to 1000 writes. This is needed as initial boot code can't do ECC.

We are also guaranteed that a minimum of 4026 blocks (out of the total 4096) are good. This means up to 70 blocks (1.3MBytes) can be dead, resulting in a total guaranteed amount of working NAND storage of 65961984 bytes.

Backup

You may want to backup the "Factory-Default bad blocks" just in case you accidentally delete it.
The u-boot command "nand bad" lists the offsets of the bad blocks.

Solution

The solution is split into various pieces, one at each level.

Boot loader

first-stage

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

This code (mostly written in ARM assembly) was altered to detect and skip bad blocks. This means, the first stage bootloader can itself extend over bad blocks.

This also means that the flashing routine needs to detect and skip bad blocks, resulting in a u-boot image that can have gaping holes ;) The existing "traditional"  JTAG flashing program is not detecting bad blocks (Note: this might be changed through a compile option, see below)



Environment


The  environment is traditionally stored at a fixed location within the NAND flash. This is not acceptable, since it could be a factory-set bad block.

The solution that was implemented for Openmoko/Neo1973 was to put the in-flash address of the environment into the out-of-band (OOB) area of the first block (the one which is guaranteed to be good). Since the environment address is unlikely to change often, the 1000 erase cycles guaranteed for the first block are good enough.

The exact location is byte 8..15 of the 16byte OOB area, starting with the four ASCII bytes ENVO, followed by the little-endian 32bit unsigned integer of the NAND address where the environment is located.

The u-boot "dynenv get" command can be used to read out a pre-programmed Environment offset from NAND, and the "dynenv set" can be used to write the offset (if the last eight bytes of OOB area are erased (0xff)).

Bad Block Table (BBT)

Since the usual bad block marker in the OOB area does not allow us to distinguish between factory-bad and worn-out-bad blocks, we need to store this information elsewhere. This place is called bad-block table (BBT) and is stored as a bitmap in the last two good blocks at the end of NAND. To increase security, a backup of those two blocks is kept in the two preceding good blocks as well.

The BBT location itself is identified by special markers (BBT0/BBT1) in the OOB area of the first page of the respective erase blocks.

The BBT consists of two bits per block which distinguish the three conditions (factory-bad/worn-out/good).

Both u-boot and Linux implement the same BBT layout and thus interoperate quite well.

BBT creation

The BBT is created once a BBT-implementing u-boot is started for the first time. The BBT scanning code assumes that the NAND is completely erased, i.e. only contains 0xff as content. Any block that contains bytes != 0xff in the OOB is marked as "factory bad" block.

Flashing kernel/rootfs from u-boot

The kernel is contained in its own . 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

As opposed to using fixed NAND flash addresses, we can use the mtd partition names. Thus, the magic of device-specific dynamic partition layout is all hidden neatly from the user. A flash command using a partiton name looks like:

nand write.e 0x32000000 kernel

Where 0x32000000 is the source address in RAM, and 'kernel' is the name of the kernel partition.

Kernel

Bad block table

In order to maintain the BBT created by u-boot, the kernel needs to have BBT support enabled. Unfortunately the mainline kernel doesn't have a CONFIG option for it, so if you're not using the -moko kernel tree, you have to manually patch the s3c2410 nand driver to enable the BBT option.

Flash Tool

sjf2410 (during development)

The  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, once u-boot steppingstone code has been enhanced to skip bad blocks.

However, even if the bad-block skipping works, sjf2410-linux only supports the extremely slow parallel-port based JTAG adaptors. Also, the o