[PATCH 2.6.30-rc6 3/3] NAND: Add 4-bit ECC support for large page NAND chips

[Troy Kisky]

Narnakaje, Snehaprabha wrote:
> 
>> -----Original Message-----
>> From: Troy Kisky [mailto:troy.kisky at boundarydevices.com]
>> Sent: Wednesday, May 20, 2009 3:07 PM
>> To: Narnakaje, Snehaprabha
>> Cc: linux-mtd at lists.infradead.org; davinci-linux-open-
>> source at linux.davincidsp.com; dwmw2 at infradead.org; tglx at linutronix.de;
>> akpm at linux-foundation.org
>> Subject: Re: [PATCH 2.6.30-rc6 3/3] NAND: Add 4-bit ECC support for large
>> page NAND chips
>>
>> Narnakaje, Snehaprabha wrote:
>>> Troy,
>>>
>>>> -----Original Message-----
>>>> From: Troy Kisky [mailto:troy.kisky at boundarydevices.com]
>>>> Sent: Monday, May 18, 2009 8:17 PM
>>>> To: Narnakaje, Snehaprabha
>>>> Cc: dwmw2 at infradead.org; davinci-linux-open-
>> source at linux.davincidsp.com;
>>>> linux-mtd at lists.infradead.org; tglx at linutronix.de; akpm at linux-
>>>> foundation.org
>>>> Subject: Re: [PATCH 2.6.30-rc6 3/3] NAND: Add 4-bit ECC support for
>> large
>>>> page NAND chips
>>>>
>>>> Troy Kisky wrote:
>>>>> nsnehaprabha at ti.com wrote:
>>>>>> From: Sneha Narnakaje <nsnehaprabha at ti.com>
>>>>>>
>>>>>> This patch adds 4-bit ECC support for large page NAND chips using the
>>>> new ECC
>>>>>> mode NAND_ECC_HW_OOB_FIRST. The platform data from board-dm355-evm
>> has
>>>> been
>>>>>> adjusted to use this mode.
>>>>>>
>>>>>> The patches have been verified on DM355 device with 2K Micron devices
>>>> using
>>>>>> mtd-tests and JFFS2. Error correction upto 4-bits has also been
>>>> verified using
>>>>>> nandwrite/nanddump utilities.
>>>>>>
>>>>>> Reviewed-by: David Brownell <dbrownell at users.sourceforge.net>
>>>>>> Signed-off-by: Sneha Narnakaje <nsnehaprabha at ti.com>
>>>>>> ---
>>>>>>  drivers/mtd/nand/davinci_nand.c |   37
>>>> +++++++++++++++++++++++++++++++------
>>>>>>  1 files changed, 31 insertions(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/mtd/nand/davinci_nand.c
>>>> b/drivers/mtd/nand/davinci_nand.c
>>>>>> index ba6940d..4557b8d 100644
>>>>>> --- a/drivers/mtd/nand/davinci_nand.c
>>>>>> +++ b/drivers/mtd/nand/davinci_nand.c
>>>>>> @@ -500,6 +500,24 @@ static struct nand_ecclayout hwecc4_small
>>> __initconst = {
>>>>>>  	},
>>>>>>  };
>>>>>>
>>>>>> +/* An ECC layout for using 4-bit ECC with large-page (2048bytes)
>> flash,
>>>>>> + * storing ten ECC bytes plus the manufacturer's bad block marker
>> byte,
>>>>>> + * and not overlapping the default BBT markers.
>>>>>> + */
>>>>>> +static struct nand_ecclayout hwecc4_2048 __initconst = {
>>>>>> +	.eccbytes = 40,
>>>>>> +	.eccpos = { 0, 1, 2, 3, 4,
>>>>>> +		/* offset 5 holds the badblock marker */
>>>> I don't see any bad block overrides to move it from bytes 0,1
>>>> to byte 5 in this patch. What am I missing?
>>> We are making sure we are not overwriting offset 5, that holds the
>> badblock marker from nand manufacturer. Thus offset 5 is skipped in the
>> eccpos.
>>
>> Yes, I agree, you are. But how does Linux know where to look for the bad
>> block marker?
> 
> I believe, it is defined in the nand_bbt.c.
> 
> BTW, looking closely at the nand_bbt.c, looks like I made a mistake :-)
> 
> static struct nand_bbt_descr smallpage_flashbased = {
>         .options = NAND_BBT_SCAN2NDPAGE,
>         .offs = 5,
>         .len = 1,
>         .pattern = scan_ff_pattern
> };
> 
> static struct nand_bbt_descr largepage_flashbased = {
>         .options = NAND_BBT_SCAN2NDPAGE,
>         .offs = 0,
>         .len = 2,
>         .pattern = scan_ff_pattern
> };
> 
> Since my patches are to support large page, Shouldn't I be skipping 2 bytes (offset 0 and 1)?
> 
> The 1 byte at offset 5 was for smallpage.
> 
> Thanks
> Sneha
> 
> 

Yes, that is what I thought. If you can place the ecc anywhere, please put it at the end of the oob data
for large page devices.


Troy