mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: linux@horizon.com
To: linux@horizon.com, osv@javad.com
Cc: dedekind@yandex.ru, kalin@thinrope.net,
	linux-kernel@vger.kernel.org, linux-os@analogic.com
Subject: Re: Lifetime of flash memory
Date: 29 Mar 2006 10:56:10 -0500	[thread overview]
Message-ID: <20060329155610.4903.qmail@science.horizon.com> (raw)
In-Reply-To: <87mzf96fac.fsf@javad.com>

>> Due to the multiplexing scheme used in high-density NAND flash devices,
>> even the non-programmed cells are exposed to a fraction of the programming
>> voltage and there are very low limits on the number of write cycles to
>> a page before it has to be erased again.  Exceeding that can cause some
>> unwanted bits to change from 1 to 0.  Typically, however, it is enough
>> to write each 512-byte portion of a page independently.

> Well, I'm not sure. The Toshiba and Samsung NANDs I've read manuals for
> seem to limit number of writes to a single page before block erase, --
> is 512-byte portion some implementation detail I'm not aware of?

No.  I just meant that I generally see "you may program each 2K page a
maximum of 4 times before performing an erase cycle", and I assume the
spec came from 2048/512 = 4, so you can program each 512-byte sector
separately.  I would assume if the page size were changed again, they'd
try to keep that property.

E.g. from the Samsung K9K8G08U1A/K9F4G08U0A data sheet (p. 34):

	PAGE PROGRAM

	The device is programmed basically on a page basis, but it does
	allow multiple partial page programming of a word or consecutive
	bytes up to 2,112, in a single page program cycle.  The number
	of consecutive partial page programming operations within the
	same page without an intervening erase operation must not exceed
	4 times for a single page.  The addressing should be done in
	sequential order in a block.
	[...]
	The internal write verify detects only errors for "1"s that are
	not successfully programmed to "0"s."

>> Now, erasing is done in larger units called BLOCKs.  This is more
>> variable, but a power of two multiple of the page size.  32 to 64 pages
>> (16 k for small page/32-page blocks to 128K for large page with 64-page
>> blocks) is a typical quantity.  You can only erase a block at a time.

> Typical? Are you aware of a "large page" NAND FLASH with different
> number of pages per block? It's not just curiosity, it's indeed
> important for me to know if there are CF cards in the market with
> physical block size != 128K.

No, I'm not aware of any violations of that rule; I just hadn't looked
hard enough to verify that it was a rule, but I had seen the device ID
bits that allow a wide range to be specified.

The "more variable" statement is really based on NOR flash experience,
where it truly does vary all over the map.

> [... skip interesting and nicely put details of NAND technology ...]

Hopefully this makes descriptions like the start of the Samsung data
sheet more comprehensible:

	Product Information

	The K9F4G08U0A is a 4,224 Mbit (4,429,185,024 bit) memory
	organized as 262,144 rows (pages) by 1,112x8 columns.  Spare
	64x8 columns are located from column address of 2,048-2,111.
	A 2,112-byte data register is connected to memory cell arrays
	accomodating data transfer between the I/O buffers and memory
	during page read and page program operations.  The memory array
	is made up of 32 cells that are serially connected to form a
	NAND structure.  Each of the 32 cells resides in a different page.
	A block consists of two NAND structured strings.  A NAND structure
	consists of 32 cells.  Total 1,081,244 NAND cells reside in
	a block.  The program and read operations are executed on a page
	basis, while the erase operation is executed on a block basis.
	The memory array consists of 4,086 separately erasable 128K-byte
	blocks.  It indicates that the bit-by-bit erase operation is
	prohibited on the K9F4G08U0A.

  reply	other threads:[~2006-03-29 15:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-23  7:49 linux
2006-03-26 13:55 ` Artem B. Bityutskiy
2006-03-26 16:21   ` linux
2006-03-26 16:36     ` Artem B. Bityutskiy
2006-03-27 16:18       ` Lennart Sorensen
2006-03-27 17:44         ` linux-os (Dick Johnson)
2006-03-27 18:01           ` Lennart Sorensen
2006-03-28  4:28           ` Sergei Organov
2006-03-28  6:41             ` Magnus Damm
2006-03-28  8:58               ` Sergei Organov
2006-03-28 12:55             ` linux-os (Dick Johnson)
2006-03-28 13:27               ` Sergei Organov
2006-03-28 13:35               ` Sergei Organov
2006-03-29  1:01             ` linux
2006-03-29  4:33               ` Sergei Organov
2006-03-29 15:56                 ` linux [this message]
2006-03-30  6:33                   ` Sergei Organov
2006-03-30 11:23                     ` linux
2006-03-30 12:18                       ` Sergei Organov
2006-03-28  0:21 ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2006-03-21 17:01 John Richard Moser
2006-03-21 17:14 ` David Vrabel
2006-03-21 17:28   ` John Richard Moser
2006-03-21 18:37     ` Paulo Marques
2006-03-21 18:00   ` hackmiester / Hunter Fuller
2006-03-21 18:20 ` Joshua Kugler
2006-03-21 18:40   ` John Richard Moser
2006-03-23  3:46 ` Kalin KOZHUHAROV

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=20060329155610.4903.qmail@science.horizon.com \
    --to=linux@horizon.com \
    --cc=dedekind@yandex.ru \
    --cc=kalin@thinrope.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=osv@javad.com \
    /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

all inboxes | Powered by JetHome®