How does ECC work with nandwrite/nanddump in mtd-utils?

Question

I am working on a device which has a NAND flash chip in TSOP48, a SK Hynix H27U1G8F2BTR (1Gbit/128Mbyte, 2048byte (+ 64byte spare) pages, 128K blocks).

I have desoldered the chip and dumped the contents to a file. This file contains the OOB (out-of-band) data as well, resulting in a 138412032byte file.

I create a new simulated NAND MTD device using:

modprobe nandsim first_id_byte=0xad second_id_byte=0xf1 third_id_byte=0x00 fourth_id_byte=0x1d

Which results in a device with the correct parameters:

$mtdinfo /dev/mtd0
mtd0
Name:                           NAND simulator partition 0
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          1024 (134217728 bytes, 128.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

I can now write my image to mtd using nandwrite, with the -o option to indicate that the dump contains OOB information:

nandwrite -o /dev/mtd0 with_oob.bin

Then I can dump the image using nanddump:

nanddump /dev/mtd0 -f without_oob.bin

This results in a 134217728byte file without OOB data. This file is sensible (as in, contains file systems I can mount).

A few times, when playing around, I have seen ECC errors when running nanddump.

How does this combination of nandsim, nandwrite and nandddump decide which ECC scheme to use? The flash is from a TI AM335 system, and as far as I know, the ECC scheme is decided by a combination of the processor and OS. How do these utilities know what to do?

Answer 1

First of all the ECC scheme used does not necessaryly have to be the for all the flash erase blocks. There are ususally 3 different types of flash partitions used and for every type the method to specify the used ECC code differs:

1. The one that are accessed by the ROM bootcode
2. The ones that are accessed by the bootloader (usually u-boot)
3. The ones that are accessed by the operating system (assuming you are using Linux)

In general the use of a specific ECC method is limited by the OOB size of the flash. The AM335x_U-Boot_User's_Guide (cannot post link here because of reputation) explains it in sections BCH Flash OOB Layout and the example matches to the flash chip you are using. The 64 bytes per 2k page effectively limit the usable ECC algorithms to BCH8, BCH4 or HAMMING codes.

BCH Flash OOB Layout

For any ECC scheme we need to add some extra data while writing so as to detect and correct (if possible) the errors introduced by the NAND part. In case of BCH scheme some bytes are needed to store the ECC related info.

The section of NAND memory where addition info like ECC data is stored is referred to as Out Of Band or OOB section.

The first 2 bytes are used for Bad block marker – 0xFFFF => Good block

The next ‘N’ bytes is used for BCH bytes

N = B * Number of 512-byte sectors in a page

B = 8 bytes per 512 byte sector in BCH4 B = 14 bytes per 512 byte sector in BCH8 B = 26 bytes per 512 byte sector in BCH16

So for a 2k page-size NAND flash with 64-byte OOB size, we will use BCH8. This will consume 2 + (14*4) = 58 bytes out of 64 bytes available.

ECC used by ROM bootcode

The AM335x processor's ROM bootcode decides which ECC scheme to use for NAND flash depending on the mechanism expalined in the AM335x technical reference manual chapter 26.1.7.4 NAND

ECC Correction The default ECC correction applied is BCH 8b/sector using the GPMC and ELM hardware. For device ID codes D3h, C3h, D5h, C5h, D7h, C7h, DEh, CEh when manufacturer code (first ID byte) is 98h the Cell type information is checked in the 4th byte of ID data. If it is equal to 10b then the ECC correction applied is BCH 16b/sector. In addition ECC computation done by the ROM can be turned off completely by using SYSBOOT[9]. This is particularly useful when interfacing with NAND devices that have built in ECC engines.

Other ways to control the ECC behavior are ONFI or and I2C EEPROM but the H27U1G8F2BTR datasheet does not mention ONFI so I guess it is not supported by the flash chip.

So basically BCH8 or BCH16 or no ECC mechanism is used for the first 128K the ROM bootloader reads from NAND flash.

ECC used by the bootloader

The bootloader decides this on his own. For example for U-boot this information is compiled into u-boot and the first level bootloader (SPL/MLO) as well. The information is controlled by U-Boot configuration settings set at compile time. Recent versions of U-boot can switch the ecc at runtime using the nandecc command.

ECC used by the OS

The selection is completely OS specific. For Linux embedded systems using AM335x processors I know that this information is passed into the kernel using the device tree.

Which ECC method does nandsim use

There is a parameter called bch which can be passed to the nandsim module to select an ecc code. From the code I guess It is initialized to zero so it won't use any ECC code. So it seems that nandsim can use BCH8 and BCH16 but only one for the whole flash that is simulated.

modprobe nandsim bch=8 first_id_byte=0xad second_id_byte=0xf1 third_id_byte=0x00 fourth_id_byte=0x1d

Which ECC method does nanddump/nandwrite use

Again, this depends on the OS/Linux you used to dump the flash. Similar to the nandsim module real mtd drivers have ways to specify the used ECC scheme (kernel parameters, device tree). But you can instruct nanddump to ignore the ECC information, too.

References

• AM335x technical reference manual http://www.ti.com/lit/gpn/am3359
• bch Linux Kernel parameter for nandsim http://lxr.free-electrons.com/source/drivers/mtd/nand/nandsim.c#L175
• The AM335x_U-Boot_User's_Guide