All of lore.kernel.org
 help / color / mirror / Atom feed
From: Iwo Mergler <iwo@call-direct.com.au>
To: Mike Frysinger <vapier@gentoo.org>
Cc: linux-mtd@lists.infradead.org, dedekind1@gmail.com
Subject: Re: [PATCH] nandwrite: add --nobad to write bad blocks
Date: Wed, 29 Sep 2010 13:35:05 +1000	[thread overview]
Message-ID: <4CA2B3E9.3030707@call-direct.com.au> (raw)
In-Reply-To: <AANLkTi=ssyUrvaic86hx8tT0TvZiMzyDa_KL0SfU144J@mail.gmail.com>

Mike Frysinger wrote:
> i'm open to logic, but i cant figure out your side.  all i can see is
> "it's been this way" and "we shouldnt write bad blocks".  but both
> sound like policies that the end user should have control over rather
> than the userspace utils always enforcing.  so if you feel i've missed
> something, please highlight it.

Hi Mike,

while I agree with the philosophy to allow users to shoot
themselves in the foot if they really like that sort of thing,
the "don't touch bad blocks" rule makes sense and it's not
necessarily obvious.

Flash memory is only 'digital' in an idealised sense. Like
every other 'digital' device, the real thing is analogue.

The read value of a flash memory cell depends on the amount
of charge stored in a insulated transistor gate when compared
to a threshold voltage derived from the power supply. The
comparison is also temperature dependent.

In other words, a bit being read correctly depends on voltage
and temperature during both writing and reading.

Bad cells can be caused by impurities in the gate insulation
(slow discharge), incorrect insulation thickness, marginal
transistors, etc. The degree of 'badness' also depends on
voltage and temperature.

The upshot of this is that blocks are marked as bad by the
manufacturer based on corner case testing. Like erasing at
high temperature / low voltage and reading back at low
temperature / high voltage. The manufacturer can also
access pads on the naked die that are not connected to pins
during packaging.

This means that the manufacturer can catch marginal cases,
where a cell 'works', but will flip a bit within a month.

Depending on the damage, it may even require special tricks
to mark a block as bad.

Either way, as a user of the device, you may not be able
tell if a block is bad, or fully erase a bad block, or even
reliably mark it as bad again.

Thus the rule about not touching bad blocks. It's the only
way to make sure that you don't end up with a batch of products
that will die on the shelf, after you successfully tested them.


Best regards,

Iwo

  reply	other threads:[~2010-09-29  3:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-12  3:51 [PATCH] nandwrite: add --nobad to write bad blocks Mike Frysinger
2010-09-12 16:27 ` Artem Bityutskiy
2010-09-12 19:05   ` Mike Frysinger
2010-09-13  6:23     ` Artem Bityutskiy
2010-09-14  1:21       ` Mike Frysinger
2010-09-14  5:26         ` Artem Bityutskiy
2010-09-22  4:23           ` Mike Frysinger
2010-09-22  7:12             ` Artem Bityutskiy
2010-09-22  7:34               ` Mike Frysinger
2010-09-29  3:35                 ` Iwo Mergler [this message]
2010-09-29  6:56                   ` Jon Povey
2010-09-29 13:25                     ` Mike Frysinger
2010-09-29 23:44                     ` Iwo Mergler
2010-09-30  3:23                       ` Jon Povey
2010-09-29 12:59                   ` Artem Bityutskiy
2010-09-29 13:28                     ` Mike Frysinger
2010-09-30  3:51                       ` Jon Povey
2010-09-23  1:48             ` Jon Povey
2010-09-23 10:38 ` Artem Bityutskiy
2010-09-23 20:04   ` [PATCH v2] " Mike Frysinger
2010-09-24  8:50     ` Artem Bityutskiy
2010-09-24 12:33       ` Mike Frysinger

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=4CA2B3E9.3030707@call-direct.com.au \
    --to=iwo@call-direct.com.au \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vapier@gentoo.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.