> -----Original Message----- > From: Troy Kisky [mailto:[email protected]] > Sent: Wednesday, May 20, 2009 4:19 PM > To: Narnakaje, Snehaprabha > Cc: [email protected]; davinci-linux-open- > [email protected]; [email protected]; [email protected]; > [email protected] > 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:[email protected]] > >> Sent: Wednesday, May 20, 2009 3:07 PM > >> To: Narnakaje, Snehaprabha > >> Cc: [email protected]; davinci-linux-open- > >> [email protected]; [email protected]; [email protected]; > >> [email protected] > >> 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:[email protected]] > >>>> Sent: Monday, May 18, 2009 8:17 PM > >>>> To: Narnakaje, Snehaprabha > >>>> Cc: [email protected]; davinci-linux-open- > >> [email protected]; > >>>> [email protected]; [email protected]; a...@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: > >>>>> [email protected] wrote: > >>>>>> From: Sneha Narnakaje <[email protected]> > >>>>>> > >>>>>> 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 <[email protected]> > >>>>>> Signed-off-by: Sneha Narnakaje <[email protected]> > >>>>>> --- > >>>>>> 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 _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
