All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] PATCH: bugfix for nand erase failure with bad blocks
Date: Tue, 16 Jun 2009 15:19:19 -0500	[thread overview]
Message-ID: <4A37FE47.3030203@freescale.com> (raw)
In-Reply-To: <20090616200940.DD093832E416@gemini.denx.de>

Wolfgang Denk wrote:
> Dear "Michele De Candia (VT)",
> 
> In message <4A37F7BF.2090101@valueteam.com> you wrote:
>>>> this patch fixes a bug for 'nand erase' command: when bad blocks are 
>>>> present into erasing area, they were skipped but the erased size was 
>>>> updated anyway.
>>> And what exactly is the bug in this behaviour?
>>>   
>> I think that 'erase' should have the same behaviour of 'write' and 
>> 'read' commands: skip bad blocks until read/write size is reached. If 
>> you write a script that erases and then writes a NAND area and bad 
>> blocks are not skipped while erasing (as U-Boot actually does), the 
>> following 'write'  is successfully done but ECC checks fail on next read 
>> on the same area.
> 
> I see - thanks for the explanation.
> 
> Hm... actually I think the write should fail in such a case...
> 
> Scott, what do you think?

I think the current behavior is reasonable.  You're erasing a specific 
region of flash, not an amount needed to hold a certain amount of data.

While I can see the appeal of Michele's suggestion, I think it would be 
more error-prone as people trying to erase a region rather than just the 
size of data could erase too much.

It definitely should not be an error to erase a region that happens to 
contain a bad block.  Bad blocks are expected and we need to work around 
them.

-Scott

  reply	other threads:[~2009-06-16 20:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-16 13:06 [U-Boot] PATCH: bugfix for nand erase failure with bad blocks Michele De Candia
2009-06-16 18:10 ` Wolfgang Denk
2009-06-16 19:51   ` Michele De Candia
2009-06-16 20:09     ` Wolfgang Denk
2009-06-16 20:19       ` Scott Wood [this message]
2009-06-17  7:18         ` Michele De Candia
2009-06-17  7:43           ` Michele De Candia
2009-06-17  7:44           ` Michele De Candia
2009-06-17 15:54             ` Scott Wood
2009-06-17 16:17               ` Michele De Candia
2009-06-17 22:04                 ` Scott Wood
2009-06-17 22:15                   ` Wolfgang Denk
2009-06-17 22:34                     ` Scott Wood
2009-06-19  7:01                       ` Michele De Candia
2009-06-17 22:11               ` Wolfgang Denk
2009-06-17  9:18         ` Wolfgang Denk

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=4A37FE47.3030203@freescale.com \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.