public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Adrian Hunter <ext-adrian.hunter@nokia.com>
To: kyungmin.park@samsung.com
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: OneNAND: Check first or second pages for bad block information
Date: Mon, 22 Jan 2007 10:45:03 +0200	[thread overview]
Message-ID: <45B4798F.8030809@nokia.com> (raw)
In-Reply-To: <3686708.94231169451196140.JavaMail.weblogic@ep_ml23>

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.

  reply	other threads:[~2007-01-22  8:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-22  7:33 OneNAND: Check first or second pages for bad block information Kyungmin Park
2007-01-22  8:45 ` Adrian Hunter [this message]
2007-01-22  9:13 ` Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2007-01-22 11:59 Kyungmin Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45B4798F.8030809@nokia.com \
    --to=ext-adrian.hunter@nokia.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox