The nand driver supports three different types of hardware ECC.
NAND_ECC_HW3_256
Hardware ECC generator providing 3 bytes ECC per 256 byte.
NAND_ECC_HW3_512
Hardware ECC generator providing 3 bytes ECC per 512 byte.
NAND_ECC_HW6_512
Hardware ECC generator providing 6 bytes ECC per 512 byte.
NAND_ECC_HW8_512
Hardware ECC generator providing 6 bytes ECC per 512 byte.
If your hardware generator has a different functionality add it at the appropriate place in nand_base.c
The board driver must provide following functions:
enable_hwecc
This function is called before reading / writing to the chip. Reset or initialize the hardware generator in this function. The function is called with an argument which let you distinguish between read and write operations.
calculate_ecc
This function is called after read / write from / to the chip. Transfer the ECC from the hardware to the buffer. If the option NAND_HWECC_SYNDROME is set then the function is only called on write. See below.
correct_data
In case of an ECC error this function is called for error detection and correction. Return 1 respectively 2 in case the error can be corrected. If the error is not correctable return -1. If your hardware generator matches the default algorithm of the nand_ecc software generator then use the correction function provided by nand_ecc instead of implementing duplicated code.
Many hardware ECC implementations provide Reed-Solomon codes and calculate an error syndrome on read. The syndrome must be converted to a standard Reed-Solomon syndrome before calling the error correction code in the generic Reed-Solomon library.
The ECC bytes must be placed immediately after the data bytes in order to make the syndrome generator work. This is contrary to the usual layout used by software ECC. The separation of data and out of band area is not longer possible. The nand driver code handles this layout and the remaining free bytes in the oob area are managed by the autoplacement code. Provide a matching oob-layout in this case. See rts_from4.c and diskonchip.c for implementation reference. In those cases we must also use bad block tables on FLASH, because the ECC layout is interfering with the bad block marker positions. See bad block table support for details.