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

[Narnakaje, Snehaprabha]

> -----Original Message-----
> From: Troy Kisky [mailto:troy.kisky at boundarydevices.com]
> Sent: Wednesday, May 20, 2009 4:19 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:
> >
> >> -----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,

I explored nand_bbt, jffs2 using the OOB area.

This is what I found -
2 bytes at offset 0: BB markers
4 bytes at offset 8: BBT magic number/data
1 byte at offset 12: BBT version
8 bytes at offset 16: JFFS2 clear markers

So, it is better to start with offset 24 (there are few bytes in between, but it is better to leave them as-is).

Dave, 

Did you have any comments?

Thanks
Sneha


> 
> 
> Troy