All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Scian <rnd4@dave-tech.it>
To: "Boris Brezillon" <boris.brezillon@free-electrons.com>,
	"Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Brian Norris <computersforpeace@gmail.com>
Subject: Re: [PATCH 1/2] mtd: nand: use a lower value for badblockbits when working with MLC NAND
Date: Wed, 9 Mar 2016 17:37:17 +0100	[thread overview]
Message-ID: <56E0513D.5000508@dave-tech.it> (raw)
In-Reply-To: <20160309152638.0b5e9250@bbrezillon>

Il 09/03/2016 15:26, Boris Brezillon ha scritto:
> On Tue, 1 Mar 2016 14:47:21 +0000
> Bean Huo 霍斌斌 (beanhuo) <beanhuo@micron.com> wrote:
>
>> Hi, Andrea and Boris
>> This is a historical subject, and talked before.
>>  From our field issues, 8 bits of bad block mark for MLC NAND is not reasonable.
>> Because of bitflip on bad block mark, regard one good block as a bad block is common
>> Issue. Especially first time boot after reflow. The solution is modified this value to 4 for MLC
>> NAND by hand, and the factory BB mark is “0x00”.
>> I think, 4 bits for MLC NAND make sense.
>
>
> I'm tempted to say "let's start with this value and see what happens in
> real world". If we want to be a bit more conservative we could decide
> to chose 2, which should address most problems too (during my tests, I
> never seen such a huge concentration of bitflips in the same byte).
>
> Brian, Andrea, what do you think?
>

I'm currently using 4 on my custom kernel.
On all datasheet I've seen factory bad block marker is 0x00 and the same 
is (AFAIK) used by MTD to mark bad blocks.

Kind Regards,

-- 

Andrea SCIAN

DAVE Embedded Systems

  reply	other threads:[~2016-03-09 16:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A765B125120D1346A63912DDE6D8B6310BF69672@NTXXIAMBX02.xacn.micron.com>
2016-03-09 14:26 ` [PATCH 1/2] mtd: nand: use a lower value for badblockbits when working with MLC NAND Boris Brezillon
2016-03-09 16:37   ` Andrea Scian [this message]
2016-03-10  2:48     ` Bean Huo 霍斌斌 (beanhuo)
2015-03-06 12:12 [PATCH 0/2] Use badblockbits-like approach in nand_bbt.c rnd4
2015-03-06 12:12 ` [PATCH 1/2] mtd: nand: use a lower value for badblockbits when working with MLC NAND rnd4
2015-03-15  9:07   ` Boris Brezillon
2015-04-03 12:52     ` Andrea Scian
2015-07-23 21:24       ` Andrea Scian
2015-07-23 22:00         ` Brian Norris

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=56E0513D.5000508@dave-tech.it \
    --to=rnd4@dave-tech.it \
    --cc=beanhuo@micron.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.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 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.