quick help - Linux MTD NAND subsystem

[Naidu Tellapati]

Hi Experts,

Thanks in advance for your time.  In our Nand Flash Controller's Linux driver I am planning to define the ecclayout as the following.

/* 512-byte page with 4-bit BCH ECC 8-bit */
static struct nand_ecclayout oob_512_8bit_ecc4 = {
	.eccbytes = 8,
	.eccpos = {8, 9, 10, 11, 12, 13, 14, 15},
	.oobfree = { {0, 5}, {6, 2} },
};

/* 512-byte page with 4-bit ECC, 16-bit */
static struct nand_ecclayout oob_512_16bit_ecc4 = {
	.eccbytes = 8,
	.eccpos = {8, 9, 10, 11, 12, 13, 14, 15},
	.oobfree = { {2, 6}, },
};

/* 2048-byte page size with 4-bit ECC */
static struct nand_ecclayout oob_2048_ecc4 = {
	.eccbytes = 32,
	.eccpos = {
		8, 9, 10, 11, 12, 13, 14, 15,
		16, 17, 18, 19, 20, 21, 22, 23,
		24, 25, 26, 27, 28, 29, 30, 31,
		32, 33, 34, 35, 36, 37, 38, 39,
	},
	.oobfree = { {2, 6}, {40, 24} },
};

Page Program sequence:

I am taking 2K page size as an example for my discussion.

The ECC engine inside our NAND Flash Controller generates and automatically writes the ECC bytes to the OOB area along with the page data as part of Page Program Operation.
The ECC engine calculates ECC residue bytes on each 512 bytes of data chunk, 8 ECC bytes per 512 bytes of data, a total of 32 bytes of EEC per 2K page. 
For this to happen, from the driver, we first program the Controller's spare offset register (ECC_SPARE_OFFSET_REGISTER) with the offset in the spare area
on the flash from where the ECC bytes have to be written.

As defined in the above ecclayout example nand_ecclayout oob_2048_ecc4, I will program the ecc spare offset 8 in the controller's register. 

Now could you please help me in understanding the following.

1. Is it mandatory that the JFFS2 always use the following Offsets in OOB area for storing clean marker information?
   
    Nand chips with 512 byte pagesize and 16 byte OOB size   (Offset - 0x08 to 0x0f)

    Nand chips with 2048 byte pagesize and 64 byte OOB size  (Offset - 0x10 to 0x17)

2. If answer to point 1 is yes, as the ecclayout clashes with the JFFS2 clean marker bytes, with the above 3 ecclayout definitions I think I can't use JFFS2 file system
    with the above 3 ecclayout configurations. Please correct me if I am wrong.

3. If answer to point 1 is no, shall we program the JFFS2 to use the oobfree (defined in ecclayout) locations for storing clean marker information.
   If yes, do we need at least 8 oobfree locations for storing clean marker information.

4. Since UBIFS does not make use of OOB area for storing file system specific information, I think I can always use UBIFS with the above 3 ecclayout definitions.

5. If we can't support JFFS2 file system, is it acceptable to write a NAND Flash Controller Linux driver which works only with UBIFS and does not work with JFFS2.

6. While reading the page data, since the ECC hardware inside our Flash Controller is taking care of correcting any errors detected and finally giving the corrected
    data to the driver, I think I just need to stub out the following two functions. Please correct me if I am wrong.

	img->nand.ecc.calculate = img_ecc_calculate;

	img->nand.ecc.correct = img_ecc_correct;

7. For regular page writes, the driver does not write any ECC data to the flash. Instead we let the Controller handle all the ECC data written to the device.

8. Now I am planning to implement the following function in my driver. I understand that the file system writes the clean block markers to the oobfree area at
   the time of driver initialization before any page program operation from the NAND Flash Controller. Hence the subsequent page program operations from the
   NAND Flash controller (page data + ECC bytes) have to ensure that the clean block marker bytes in OOB area are not disturbed. Please correct me if I am wrong.

            img->nand.ecc.write_oob = img_write_oob;

9. I am of the opinion that file system does not invoke the mtd->_write_oob() function after it has invoked page program operation. Please correct me if I am wrong.
   If it invokes mtd->_write_oob() after it has invoked page program operation, the nand_fill_oob function is filling 0xFF to EEC locations in the OOB area.

10. Since the nand_block_markbad_lowlevelfuntion is erasing the block before marking the block as bad  (in the OOB area), I need not to worry about ECC bytes in this particular case.

Thanks and regards,
Naidu.