[PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips

[PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips

[Anton Vorontsov]

For large page chips, nand_bbt is looking into OOB area, and checking
for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
reserved for bbt means.

But ELBC driver is specifying ecclayout so that oobfree area starts at
offset 1, so only one byte left for the bbt purposes.

This causes problems with any OOB users, namely JFFS2: after first mount
JFFS2 will fill all OOBs with "erased marker", so OOBs will contain:

  OOB Data: ff 19 85 20 03 00 ff ff ff 00 00 08 ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

And on the next boot, NAND core will rescan for bad blocks, then will
see "0xff 0x19" pattern, and will mark all blocks as bad ones.

To fix the issue we should implement our own bad block pattern: just one
byte at OOB start.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---

The patch that fixes oobfree will follow, but you have to choice which
you'll want to apply (if any), not both.

 drivers/mtd/nand/fsl_elbc_nand.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 1b06d29..69609cc 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -116,6 +116,20 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
 	.oobavail = 48,
 };
 
+/*
+ * fsl_elbc_oob_lp_eccm* specify for LP NANDs that OOB starts at offset 1, so
+ * we have to adjust bad block pattern (this is for compatiblitywith already
+ * reflashed devices, otherwise we could fix ecclayout.oobfree instead).
+ */
+static u8 scan_ff_pattern[] = { 0xff, };
+
+static struct nand_bbt_descr largepage_memorybased = {
+	.options = 0,
+	.offs = 0,
+	.len = 1,
+	.pattern = scan_ff_pattern,
+};
+
 /*=================================*/
 
 /*
@@ -687,6 +701,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
 			chip->ecc.layout = (priv->fmr & FMR_ECCM) ?
 			                   &fsl_elbc_oob_lp_eccm1 :
 			                   &fsl_elbc_oob_lp_eccm0;
+			chip->badblock_pattern = &largepage_memorybased;
 			mtd->ecclayout = chip->ecc.layout;
 			mtd->oobavail = chip->ecc.layout->oobavail;
 		}
-- 
1.5.5.4

Re: [PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips

[Scott Wood]

Anton Vorontsov wrote:
> For large page chips, nand_bbt is looking into OOB area, and checking
> for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
> reserved for bbt means.

Interesting... both the 8313 manual and the manual for a random large 
page NAND chip say that the bad block indicator is one byte.

BTW, I was just looking at NAND boot on this chip, and it seems that it 
expects ECCM=1 for large page devices, so we should make that the 
default (preferably at the same time as we fix this problem, so that we 
don't break compatibility with a working version).

-Scott

Re: [PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips

[Anton Vorontsov]

On Thu, Jun 26, 2008 at 01:59:45PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> For large page chips, nand_bbt is looking into OOB area, and checking
>> for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
>> reserved for bbt means.
>
> Interesting... both the 8313 manual and the manual for a random large  
> page NAND chip say that the bad block indicator is one byte.

Ok, great. If I understood David correctly, second byte is used (by some
chips?) for redundancy, thus should not be a big problem if we'll ignore
it. So, would you ack this part? Then I'll resend it with some typos
fixed. ;-)

> BTW, I was just looking at NAND boot on this chip, and it seems that it  
> expects ECCM=1 for large page devices, so we should make that the  
> default (preferably at the same time as we fix this problem, so that we  
> don't break compatibility with a working version).

Ugh. I think driver should support both. If we'll change (force) this in
Linux, we'll break older u-boots (especially FSL U-Boots with NAND
support enabled). I believe that simply changing ECCM to 1 in the newer
community u-boots would be less pain for everybody, no?

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: [PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips

[Scott Wood]

Anton Vorontsov wrote:
> On Thu, Jun 26, 2008 at 01:59:45PM -0500, Scott Wood wrote:
>> Anton Vorontsov wrote:
>>> For large page chips, nand_bbt is looking into OOB area, and checking
>>> for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
>>> reserved for bbt means.
>> Interesting... both the 8313 manual and the manual for a random large  
>> page NAND chip say that the bad block indicator is one byte.
> 
> Ok, great. If I understood David correctly, second byte is used (by some
> chips?) for redundancy, thus should not be a big problem if we'll ignore
> it. So, would you ack this part? Then I'll resend it with some typos
> fixed. ;-)

Acked-by: Scott Wood <scottwood@freescale.com>

>> BTW, I was just looking at NAND boot on this chip, and it seems that it  
>> expects ECCM=1 for large page devices, so we should make that the  
>> default (preferably at the same time as we fix this problem, so that we  
>> don't break compatibility with a working version).
> 
> Ugh. I think driver should support both. If we'll change (force) this in
> Linux, we'll break older u-boots (especially FSL U-Boots with NAND
> support enabled).

I'm not aware of a Freescale board with large page NAND...

> I believe that simply changing ECCM to 1 in the newer
> community u-boots would be less pain for everybody, no?

OK, though we'll have to load the existing FMR[ECCM] into priv->fmr on 
init, rather than starting with zero.

-Scott

Re: [PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips

[Anton Vorontsov]

On Fri, Jun 27, 2008 at 09:43:28AM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> On Thu, Jun 26, 2008 at 01:59:45PM -0500, Scott Wood wrote:
>>> Anton Vorontsov wrote:
>>>> For large page chips, nand_bbt is looking into OOB area, and checking
>>>> for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
>>>> reserved for bbt means.
>>> Interesting... both the 8313 manual and the manual for a random large 
>>>  page NAND chip say that the bad block indicator is one byte.
>>
>> Ok, great. If I understood David correctly, second byte is used (by some
>> chips?) for redundancy, thus should not be a big problem if we'll ignore
>> it. So, would you ack this part? Then I'll resend it with some typos
>> fixed. ;-)
>
> Acked-by: Scott Wood <scottwood@freescale.com>

Thanks, but it seems we can't ignore the second byte. :-( See the patch
I just sent.

>>> BTW, I was just looking at NAND boot on this chip, and it seems that 
>>> it  expects ECCM=1 for large page devices, so we should make that the 
>>>  default (preferably at the same time as we fix this problem, so that 
>>> we  don't break compatibility with a working version).
>>
>> Ugh. I think driver should support both. If we'll change (force) this in
>> Linux, we'll break older u-boots (especially FSL U-Boots with NAND
>> support enabled).
>
> I'm not aware of a Freescale board with large page NAND...

MPC8610HPCD comes with 1*4GB LP NAND.

>> I believe that simply changing ECCM to 1 in the newer
>> community u-boots would be less pain for everybody, no?
>
> OK, though we'll have to load the existing FMR[ECCM] into priv->fmr on  
> init, rather than starting with zero.

Yeah. But this is another issue.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: [PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips

[Iwo Mergler]

Anton Vorontsov wrote:
> For large page chips, nand_bbt is looking into OOB area, and checking
> for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
> reserved for bbt means.
>
> But ELBC driver is specifying ecclayout so that oobfree area starts at
> offset 1, so only one byte left for the bbt purposes.
>
> This causes problems with any OOB users, namely JFFS2: after first mount
> JFFS2 will fill all OOBs with "erased marker", so OOBs will contain:
>
>   OOB Data: ff 19 85 20 03 00 ff ff ff 00 00 08 ff ff ff ff
>   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> And on the next boot, NAND core will rescan for bad blocks, then will
> see "0xff 0x19" pattern, and will mark all blocks as bad ones.
>
> To fix the issue we should implement our own bad block pattern: just one
> byte at OOB start.
>
>   
Anton,

the problem with bad block markers is that if they are set, _nothing_ is 
guaranteed
to work with that block. You cannot assume that it is possible to 
relocate the BB
marker into the first byte, if the second one is set. If you don't 
relocate it, your
new pattern will fail to find the bad block.

Most manufacturers use the first OOB byte in one of the first two pages 
in a block
as the BB marker. Others use, as you noticed, the first two OOB bytes of 
the first and
possibly second page of a block.

The point is that if  the marker is set, nothing can be done with that 
block. You must
not touch it.

To make things worse, some hardware NAND controllers *require* you to place
the ECC immediately after the data area. That's right, straight over the 
BB marker
locations.

The solution to your and other similar problems is to use a Bad Block 
Table (BBT)
at the end of the NAND. When your device comes up for the first time, it 
must
scan the NAND for bad blocks, and then write this information into the BBT.

In all consecutive boots, the device must always use the BBT and not 
scan again.

The algorithm, as implemented e.g. in U-Boot and the Linux kernel is to look
for a valid BBT first and only go scanning if it doesn't exist. After 
the scan,
the BBT is written and available next time.

You just need to set the correct flags in your low-level NAND driver.

Kind regards,

Iwo

[PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT

[Anton Vorontsov]

This patch implements support for flash-based BBT for chips working
through ELBC NAND controller, so that NAND core will not have to re-scan
for bad blocks on every boot.

Because ELBC controller may provide HW-generated ECCs we should adjust
bbt pattern and bbt version positions in the OOB free area.

The patch is mandatory for JFFS2 to work on large page NANDs connected
through the ELBC, since it workarounds ecclayout.oobfree first value:
after BBT has been created, BBT tracking code will not look for bad
block pattern anymore.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---

On Fri, Jun 27, 2008 at 04:19:14PM +1000, Iwo Mergler wrote:
> Anton Vorontsov wrote:
>> For large page chips, nand_bbt is looking into OOB area, and checking
>> for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
>> reserved for bbt means.
>>
>> But ELBC driver is specifying ecclayout so that oobfree area starts at
>> offset 1, so only one byte left for the bbt purposes.
>>
>> This causes problems with any OOB users, namely JFFS2: after first mount
>> JFFS2 will fill all OOBs with "erased marker", so OOBs will contain:
>>
>>   OOB Data: ff 19 85 20 03 00 ff ff ff 00 00 08 ff ff ff ff
>>   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>
>> And on the next boot, NAND core will rescan for bad blocks, then will
>> see "0xff 0x19" pattern, and will mark all blocks as bad ones.
>>
>> To fix the issue we should implement our own bad block pattern: just one
>> byte at OOB start.
>>
>>   
> Anton,
>
> the problem with bad block markers is that if they are set, _nothing_ is  
> guaranteed
> to work with that block. You cannot assume that it is possible to  
> relocate the BB
> marker into the first byte, if the second one is set.

Just looked into x16 LP NAND spec, and it says that block should be
considered as bad when the first _Word_ isn't 0xff. So we indeed should
not ignore the second byte. Ouch.

How about this patch?

 drivers/mtd/nand/fsl_elbc_nand.c |   34 +++++++++++++++++++++++++++++++++-
 1 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 1b06d29..1847aa7 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -116,6 +116,34 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
 	.oobavail = 48,
 };
 
+/*
+ * ELBC may use HW ECC, so that OOB offsets, that NAND core uses for bbt,
+ * interfere with ECC positions, that's why we implement our own descriptors.
+ * OOB {11, 5}, works for both SP and LP chips, with ECCM = 1 and ECCM = 0.
+ */
+static u8 bbt_pattern[] = {'B', 'b', 't', '0' };
+static u8 mirror_pattern[] = {'1', 't', 'b', 'B' };
+
+static struct nand_bbt_descr bbt_main_descr = {
+	.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+		   NAND_BBT_2BIT | NAND_BBT_VERSION,
+	.offs =	11,
+	.len = 4,
+	.veroffs = 15,
+	.maxblocks = 4,
+	.pattern = bbt_pattern,
+};
+
+static struct nand_bbt_descr bbt_mirror_descr = {
+	.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+		   NAND_BBT_2BIT | NAND_BBT_VERSION,
+	.offs =	11,
+	.len = 4,
+	.veroffs = 15,
+	.maxblocks = 4,
+	.pattern = mirror_pattern,
+};
+
 /*=================================*/
 
 /*
@@ -752,8 +780,12 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
 	chip->cmdfunc = fsl_elbc_cmdfunc;
 	chip->waitfunc = fsl_elbc_wait;
 
+	chip->bbt_td = &bbt_main_descr;
+	chip->bbt_md = &bbt_mirror_descr;
+
 	/* set up nand options */
-	chip->options = NAND_NO_READRDY | NAND_NO_AUTOINCR;
+	chip->options = NAND_NO_READRDY | NAND_NO_AUTOINCR |
+			NAND_USE_FLASH_BBT;
 
 	chip->controller = &ctrl->controller;
 	chip->priv = priv;
-- 
1.5.5.4

Re: [PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT

[Scott Wood]

Anton Vorontsov wrote:
> Just looked into x16 LP NAND spec, and it says that block should be
> considered as bad when the first _Word_ isn't 0xff. So we indeed should
> not ignore the second byte. Ouch.

The FCM doesn't support 16-bit devices.

> How about this patch?

ACK

-Scott

Re: [PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT

[Anton Vorontsov]

On Fri, Jun 27, 2008 at 10:30:34AM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> Just looked into x16 LP NAND spec, and it says that block should be
>> considered as bad when the first _Word_ isn't 0xff. So we indeed should
>> not ignore the second byte. Ouch.
>
> The FCM doesn't support 16-bit devices.

And will never support? Then maybe, in addition, we could apply the first
patch that you've acked so we'll unbreak NANDs for pour souls that tried
to reflash the JFFS2 into NAND, so that they'll will not have to
"nand scrub" their NANDs?

>> How about this patch?
>
> ACK

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: [PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT

[Scott Wood]

Anton Vorontsov wrote:
> On Fri, Jun 27, 2008 at 10:30:34AM -0500, Scott Wood wrote:
>> Anton Vorontsov wrote:
>>> Just looked into x16 LP NAND spec, and it says that block should be
>>> considered as bad when the first _Word_ isn't 0xff. So we indeed should
>>> not ignore the second byte. Ouch.
>> The FCM doesn't support 16-bit devices.
> 
> And will never support? 

It's a hardware limitation in current chips (see the manual description 
of BRn[PS]), though upon further looking it seems that it may be 
supported in the future.

> Then maybe, in addition, we could apply the first
> patch that you've acked so we'll unbreak NANDs for pour souls that tried
> to reflash the JFFS2 into NAND, so that they'll will not have to
> "nand scrub" their NANDs?

OK -- we can limit it to 8-bit chips once 16-bit support is added to the 
driver.

-Scott

Re: [PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT

[Anton Vorontsov]

On Fri, Jun 27, 2008 at 11:29:36AM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> On Fri, Jun 27, 2008 at 10:30:34AM -0500, Scott Wood wrote:
>>> Anton Vorontsov wrote:
>>>> Just looked into x16 LP NAND spec, and it says that block should be
>>>> considered as bad when the first _Word_ isn't 0xff. So we indeed should
>>>> not ignore the second byte. Ouch.
>>> The FCM doesn't support 16-bit devices.
>>
>> And will never support? 
>
> It's a hardware limitation in current chips (see the manual description  
> of BRn[PS]), though upon further looking it seems that it may be  
> supported in the future.
>
>> Then maybe, in addition, we could apply the first
>> patch that you've acked so we'll unbreak NANDs for pour souls that tried
>> to reflash the JFFS2 into NAND, so that they'll will not have to
>> "nand scrub" their NANDs?
>
> OK -- we can limit it to 8-bit chips once 16-bit support is added to the  
> driver.

Great. So.. the final patchset.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

[PATCH 1/3] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips

[Anton Vorontsov]

For large page chips, nand_bbt is looking into OOB area, and checking
for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
reserved for bbt means.

But ELBC driver is specifying ecclayout so that oobfree area starts at
offset 1, so only one byte left for the bbt purposes.

This causes problems with any OOB users, namely JFFS2: after first mount
JFFS2 will fill all OOBs with "erased marker", so OOBs will contain:

  OOB Data: ff 19 85 20 03 00 ff ff ff 00 00 08 ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

And on the next boot, NAND core will rescan for bad blocks, then will
see "0xff 0x19" pattern, and will mark all blocks as bad ones.

To fix the issue we should implement our own bad block pattern: just one
byte at OOB start. Though, this will work only for x8 chips. For x16
chips two bytes must be checked. Since ELBC driver does not support x16
NANDs (yet), we're safe for now.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Scott Wood <scottwood@freescale.com>
---
 drivers/mtd/nand/fsl_elbc_nand.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 1b06d29..99dc2be 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -116,6 +116,20 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
 	.oobavail = 48,
 };
 
+/*
+ * fsl_elbc_oob_lp_eccm* specify that LP NAND's OOB free area starts at offset
+ * 1, so we have to adjust bad block pattern. This pattern should be used for
+ * x8 chips only. So far hardware does not support x16 chips anyway.
+ */
+static u8 scan_ff_pattern[] = { 0xff, };
+
+static struct nand_bbt_descr largepage_memorybased = {
+	.options = 0,
+	.offs = 0,
+	.len = 1,
+	.pattern = scan_ff_pattern,
+};
+
 /*=================================*/
 
 /*
@@ -687,6 +701,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
 			chip->ecc.layout = (priv->fmr & FMR_ECCM) ?
 			                   &fsl_elbc_oob_lp_eccm1 :
 			                   &fsl_elbc_oob_lp_eccm0;
+			chip->badblock_pattern = &largepage_memorybased;
 			mtd->ecclayout = chip->ecc.layout;
 			mtd->oobavail = chip->ecc.layout->oobavail;
 		}
-- 
1.5.5.4

[PATCH 2/3] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT

[Anton Vorontsov]

This patch implements support for flash-based BBT for chips working
through ELBC NAND controller, so that NAND core will not have to re-scan
for bad blocks on every boot.

Because ELBC controller may provide HW-generated ECCs we should adjust
bbt pattern and bbt version positions in the OOB free area.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Scott Wood <scottwood@freescale.com>
---
 drivers/mtd/nand/fsl_elbc_nand.c |   34 +++++++++++++++++++++++++++++++++-
 1 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 99dc2be..5f1bc5e 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -130,6 +130,34 @@ static struct nand_bbt_descr largepage_memorybased = {
 	.pattern = scan_ff_pattern,
 };
 
+/*
+ * ELBC may use HW ECC, so that OOB offsets, that NAND core uses for bbt,
+ * interfere with ECC positions, that's why we implement our own descriptors.
+ * OOB {11, 5}, works for both SP and LP chips, with ECCM = 1 and ECCM = 0.
+ */
+static u8 bbt_pattern[] = {'B', 'b', 't', '0' };
+static u8 mirror_pattern[] = {'1', 't', 'b', 'B' };
+
+static struct nand_bbt_descr bbt_main_descr = {
+	.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+		   NAND_BBT_2BIT | NAND_BBT_VERSION,
+	.offs =	11,
+	.len = 4,
+	.veroffs = 15,
+	.maxblocks = 4,
+	.pattern = bbt_pattern,
+};
+
+static struct nand_bbt_descr bbt_mirror_descr = {
+	.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+		   NAND_BBT_2BIT | NAND_BBT_VERSION,
+	.offs =	11,
+	.len = 4,
+	.veroffs = 15,
+	.maxblocks = 4,
+	.pattern = mirror_pattern,
+};
+
 /*=================================*/
 
 /*
@@ -767,8 +795,12 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
 	chip->cmdfunc = fsl_elbc_cmdfunc;
 	chip->waitfunc = fsl_elbc_wait;
 
+	chip->bbt_td = &bbt_main_descr;
+	chip->bbt_md = &bbt_mirror_descr;
+
 	/* set up nand options */
-	chip->options = NAND_NO_READRDY | NAND_NO_AUTOINCR;
+	chip->options = NAND_NO_READRDY | NAND_NO_AUTOINCR |
+			NAND_USE_FLASH_BBT;
 
 	chip->controller = &ctrl->controller;
 	chip->priv = priv;
-- 
1.5.5.4

[PATCH 3/3] MTD: NAND: fsl_elbc_nand: ecclayout cleanups

[Anton Vorontsov]

This patch deletes oobavail assignments, they're calculated by the nand
core code in nand_scan_tail, plus current oobavail values are wrong for
the LP NANDs.

Also remove mtd->ecclayout and mtd->oobavail assignments, mtd core
handles this all by itself.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 drivers/mtd/nand/fsl_elbc_nand.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 5f1bc5e..d6d1ff5 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -89,7 +89,6 @@ static struct nand_ecclayout fsl_elbc_oob_sp_eccm0 = {
 	.eccbytes = 3,
 	.eccpos = {6, 7, 8},
 	.oobfree = { {0, 5}, {9, 7} },
-	.oobavail = 12,
 };
 
 /* Small Page FLASH with FMR[ECCM] = 1 */
@@ -97,7 +96,6 @@ static struct nand_ecclayout fsl_elbc_oob_sp_eccm1 = {
 	.eccbytes = 3,
 	.eccpos = {8, 9, 10},
 	.oobfree = { {0, 5}, {6, 2}, {11, 5} },
-	.oobavail = 12,
 };
 
 /* Large Page FLASH with FMR[ECCM] = 0 */
@@ -105,7 +103,6 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm0 = {
 	.eccbytes = 12,
 	.eccpos = {6, 7, 8, 22, 23, 24, 38, 39, 40, 54, 55, 56},
 	.oobfree = { {1, 5}, {9, 13}, {25, 13}, {41, 13}, {57, 7} },
-	.oobavail = 48,
 };
 
 /* Large Page FLASH with FMR[ECCM] = 1 */
@@ -113,7 +110,6 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
 	.eccbytes = 12,
 	.eccpos = {8, 9, 10, 24, 25, 26, 40, 41, 42, 56, 57, 58},
 	.oobfree = { {1, 7}, {11, 13}, {27, 13}, {43, 13}, {59, 5} },
-	.oobavail = 48,
 };
 
 /*
@@ -730,8 +726,6 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
 			                   &fsl_elbc_oob_lp_eccm1 :
 			                   &fsl_elbc_oob_lp_eccm0;
 			chip->badblock_pattern = &largepage_memorybased;
-			mtd->ecclayout = chip->ecc.layout;
-			mtd->oobavail = chip->ecc.layout->oobavail;
 		}
 	} else {
 		dev_err(ctrl->dev,
-- 
1.5.5.4

Re: [PATCH 3/3] MTD: NAND: fsl_elbc_nand: ecclayout cleanups

[Scott Wood]

Anton Vorontsov wrote:
> This patch deletes oobavail assignments, they're calculated by the nand
> core code in nand_scan_tail, plus current oobavail values are wrong for
> the LP NANDs.
> 
> Also remove mtd->ecclayout and mtd->oobavail assignments, mtd core
> handles this all by itself.
> 
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>

ACK

-Scott