How to distinguish MLC and SLC NANDs?

[Atlant Schmidt]

Juergen :

> BTW: Is there a known disadvantage or incompatibility if I protect the data of
> an SLC with the more stronger ECC sums intended for MLCs (beside the effect
> the OOB area is more filled than required)?

  Just speed and storage space (which you already realized).

  Better ECCs are otherwise, well, "better"!

  More generally, if you have a relatively small number of
  well-known NAND Flash types, you could probably use the
  Vendor ID and Device Type codes and a table to determine
  which parts are SLC and which are MLC. It's a shame this
  mechanism wasn't built in from the beginning; the same
  question came up just the other day in our shop and we
  ended up collecting all the Device Type codes (we only
  use one vendor and so far, three specific chip types).

                             Atlant


-----Original Message-----
From: linux-mtd-bounces at lists.infradead.org [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of Juergen Beisert
Sent: Friday, September 16, 2011 02:13
To: linux-mtd at lists.infradead.org
Cc: Brian Norris
Subject: Re: How to distinguish MLC and SLC NANDs?

Hi Brian,

Brian Norris wrote:
> On Thu, Sep 15, 2011 at 7:33 AM, Juergen Beisert <jbe at pengutronix.de> wrote:
> > Is there a unique pattern for MLC
> > or SLC in the mtd structure available after calling nand_scan_ident() to
> > select what correction sum type should be used for the attached NAND?
>
> Actually, there isn't anything available in struct mtd_info. This
> belongs in struct nand_chip, actually, since it's a NAND-specific
> feature. In fact, there is some data available there. As you can see
> in nand_get_flash_type() in nand_base.c, we fill in the
> `chip->cellinfo' field, then later use a mask on it like this:
>
> chip->cellinfo & NAND_CI_CELLTYPE_MSK
>
> According to the data sheets for *most* NAND parts, this is a safe way
> of determining SLC vs. MLC (non-zero => MLC; zero => SLC), and we use
> it for certain detection code paths.

Hmm, *most* means this information is not reliable? Would it be better to give
the driver a hint what kind of NAND it should expect via the platform_data?

> Note that if the chip uses ONFI, you supply your own ID table, or the chip
> uses some of the older ID codes, nand_base.c won't set chip->cellinfo for
> you; but it will default to SLC I think, which is the correct option for old
> parts.

BTW: Is there a known disadvantage or incompatibility if I protect the data of
an SLC with the more stronger ECC sums intended for MLCs (beside the effect
the OOB area is more filled than required)?

> But it's up to you to determine your own reliance on this method. I
> don't know of any users who rely on `chip->cellinfo &
> NAND_CI_CELLTYPE_MSK' for this type of information.

I was in the hope of a perfect world and the MTD framework detects the NAND
type reliable ;-). Now I tend more to use user's info from the platform_data.

Thanks for your answer.

Juergen

--
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/


 Click https://www.mailcontrol.com/sr/IXaeqh!Rro7TndxI!oX7Us7Qlo!t9IHtvEZSmYARWeyYDIP5X8F0kaKcsMuDG4ISzSBCnLyI1OpLwdQMGDtFKA==  to report this email as spam.

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.