All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Marc Reilly <marc@cpdesign.com.au>
Cc: barebox@lists.infradead.org, Juergen Beisert <jbe@pengutronix.de>,
	Wolfram Sang <wsa@pengutronix.de>
Subject: Re: Way to clear nand bad block table
Date: Fri, 27 Jul 2012 09:53:34 +0200	[thread overview]
Message-ID: <20120727075333.GV30009@pengutronix.de> (raw)
In-Reply-To: <1440381.IzydBDPxna@dev1>

On Fri, Jul 27, 2012 at 11:24:48AM +1000, Marc Reilly wrote:
> Hi Juergen,
> 
> Thanks for your ideas.
> 
> I managed to clear the BBT, it was a bit of a hack... the saga is below for 
> anyone who runs into similar problem.
> 
> On Thursday, July 26, 2012 11:27:48 AM Juergen Beisert wrote:
> > The flash blocks which contains the "bad block table" are protected by
> > the "bad block table" aware MTD layer.
> > 
> > So, the ugly way: run a bootloader which does not use the in-flash bad block
> > table. Then the tables are regular blocks in the flash and can be erased.
> > After that run again the bad block table aware bootloader and it will
> > re-create the in-flash table. But be careful: In this case the generic
> > functions scans all blocks in the NAND to collect the bad block markers in
> > each NAND block's OOB. If this information is already destroyed somehow,
> > this solution does not help.
> 
> Recompiling barebox with bbt support disabled stopped the all the bad block 
> messages, however erasing the nand didn't clear the BBT for subsequent 
> reboots...
> The issue was that the erase commands and functions skip erasing bad blocks, 
> and the blocks that held the actual BBT were being considered bad, so they 
> weren't getting erased. After commenting out calls to nand_block_checkbad() in 
> nand_write.c and block_isbad() in mtd_erase()/core.c I was able to manually 
> erase the blocks. (erasing actual bad blocks results in I/O error)
> Next restart of barebox the BBT was regenerated with the two actual bad 
> blocks.
> 
> After all that, I noticed imx_low_erase() in nand_imx.c. Probably would have 
> been easier to make up a command around that.

This problem comes up regularly. I remember Wolfram implemented a nand
'scrub' command. He was working on i.MX28. I don't know wether his
command was i.MX28 specific, but it would be nice to have such a command
around.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2012-07-27  7:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-26  8:25 Way to clear nand bad block table Marc Reilly
2012-07-26  9:27 ` Juergen Beisert
2012-07-27  1:24   ` Marc Reilly
2012-07-27  7:53     ` Sascha Hauer [this message]
2012-07-27  8:31       ` RFC: How to setup and handle NAND flashes in Barebox Juergen Beisert

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=20120727075333.GV30009@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=jbe@pengutronix.de \
    --cc=marc@cpdesign.com.au \
    --cc=wsa@pengutronix.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.