OneNAND: Check first or second pages for bad block information

OneNAND: Check first or second pages for bad block information

[Kyungmin Park]

Hi,

I'm not sure we have to check 2nd page. Yes, Spec. says we will check 1st and 2nd ones.

It increase the boot time even though it's smaller one than others.

Let me think, when we check 2nd page case.
In initial bad, no need to check 2nd page.
In runtime bad, it is only happend when first page write failed. But during write it has non-0xFF value. so next time it will be detected as invalid.

How do you think about it?

Thank you,
Kyungmin Park


------- Original Message -------
Sender : Adrian Hunter<ext-adrian.hunter@nokia.com> 
Date   : Jan 19, 2007 23:37
Title  : [PATCH] [MTD] OneNAND: Check first or second pages for bad block
 information


OneNAND records bad block information in the out-of-band area of
either the first or second page of a block.  Due to a logic error,
only the first page was being checked.

Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
---
 drivers/mtd/onenand/onenand_bbt.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_bbt.c b/drivers/mtd/onenand/onenand_bbt.c
index 90db8f5..aa46b7f 100644
--- a/drivers/mtd/onenand/onenand_bbt.c
+++ b/drivers/mtd/onenand/onenand_bbt.c
@@ -68,7 +68,7 @@ static int create_bbt(struct mtd_info *m
 
 	printk(KERN_INFO "Scanning device for bad blocks\n");
 
-	len = 1;
+	len = 2;
 
 	/* We need only read few bytes from the OOB area */
 	scanlen = ooblen = 0;
-- 
1.4.3

Re: OneNAND: Check first or second pages for bad block information

[Adrian Hunter]

ext Kyungmin Park wrote:
> I'm not sure we have to check 2nd page. Yes, Spec. says we will check 1st and 2nd ones.
> 
> It increase the boot time even though it's smaller one than others.

My experience is that the OneNAND bad block scanning time is very small (i.e. insignicant) compared with overall boot time.
For example:
	2048 blocks x 2 pages x 30 microseconds per page = 0.12 seconds

> Let me think, when we check 2nd page case.
> In initial bad, no need to check 2nd page.
> In runtime bad, it is only happend when first page write failed. But during write it has non-0xFF value. so next time it will be detected as invalid.
> 
> How do you think about it?

I cannot comment on how OneNAND actually works.  Also I do not have any experience of encountering bad blocks.  So I would follow the specification.

The specification says:

	Check "FFFFh" at the 1st word of sector 0
	of spare area in 1st and 2nd page

Based on the specification, I would presume that if a bad block goes un-noticed, it could be erased and written without error and only produce errors when the data is read back, by which time it is too late.

If you can guarantee that we never need to read the 2nd page to detect bad blocks, then the specification should be changed accordingly.

Re: OneNAND: Check first or second pages for bad block information

[Artem Bityutskiy]

Hi,

On Mon, 2007-01-22 at 07:33 +0000, Kyungmin Park wrote:
> Hi,
>
> I'm not sure we have to check 2nd page. Yes, Spec. says we will check 
1st and 2nd ones.
>
> It increase the boot time even though it's smaller one than others.
>
Actually, if one is very concerned about BB scanning time, he should use 
on-flash BBT instead of in-memory BBT.

> Let me think, when we check 2nd page case.
> In initial bad, no need to check 2nd page.
> In runtime bad, it is only happend when first page write failed. But 
during write it has non-0xFF value. so next time it will be detected as 
invalid.
>
My understanding is that the second page is used only when the first one 
could not be written to due to some reasons - dunno which reasons.

So I wonder, how sane is it to read 1st page's OOB, and if no read errors 
detected - avoid reading the second one.

OneNAND: Check first or second pages for bad block information

[Kyungmin Park]

Hi, 


> I'm not sure we have to check 2nd page. Yes, Spec. says we will check 1st and 2nd ones.
> 
> It increase the boot time even though it's smaller one than others.

> My experience is that the OneNAND bad block scanning time is very small (i.e. insignicant) compared with overall boot time.
> For example:
>	2048 blocks x 2 pages x 30 microseconds per page = 0.12 seconds

I think it's big :). But if you don't mind.


> The specification says:
> 
> 	Check "FFFFh" at the 1st word of sector 0
> 	of spare area in 1st and 2nd page

> Based on the specification, I would presume that if a bad block goes un-noticed, it could be erased and written without error and only produc> e errors when the data is read back, by which time it is too late.

O.K., We follow the Spec.

I will commit your patch.

Thank you,
Kyungmin Park