RFC: detect and manage power cut on MLC NAND (linux-mtd Digest, Vol 144, Issue 70)

Jeff Lauruhn (jlauruhn) jlauruhn at micron.com
Wed Mar 18 09:12:22 PDT 2015


Disturb is a block level affect, as long as partition A and B are in different blocks there will be no disturb between them.   Disturbs, does not damage cells; ERASE returns cells to undisturbed levels.  Disturbed bits are effectively managed with error correction codes (ECC).

Officially I would say don't use SLC emulation, but technically I know what your doing.   The reason I say no is because we have very precise recipes designed to create very tight distibutions, and although the first pass distributions might look like an SLC, they are really designed with the expectation of the upper page being programmed.  Not a true SLC. 

With MLC lithography of 25 nm and less  the difference between each level (L0, L1, L2 and L3) is just a few 10's of electrons.  The distribution have to be very tight, in order to meet retention requirements.

Jeff Lauruhn
NAND Application Engineer
Embedded Business Unit


-----Original Message-----
From: Andrea Marson [mailto:andrea.marson at dave.eu] 
Sent: Wednesday, March 18, 2015 1:45 AM
To: Boris Brezillon; Jeff Lauruhn (jlauruhn)
Cc: linux-mtd at lists.infradead.org; Andrea Scian; Richard Weinberger; dedekind1 at gmail.com
Subject: Re: RFC: detect and manage power cut on MLC NAND (linux-mtd Digest, Vol 144, Issue 70)

Hello,

I would like to discuss about another couple of topics: partitioning and SLC emulation.

1) IIUC read/program disturb effects exhibit at block level.
In a typical embedded linux systems there are software parts - bootloader, kernel image etc. - that virtually are never changed (almost
...) but are read many times. Other parts - application libraries, log files etc. - are read and wrote many times instead.
If these two kinds of software are stored in different MTD partitions - ket's say partition A for bootloader, kernel etc. and partition B for application libraries, log files etc. - can we say that read/write operations performed on partition B have no disturb effects on partition A?

2) IIUC Boris has worked on SLC emulation too. This seems to be a promising feature because it would allow to partition NAND flash and to create higher reliability partition (at the cost of halving the size). 
Is it possibile to implement such functionality in software stack
only(MTD/UBI) or is it necessary that NAND memory supports specific features?

Regards,
Andrea Marson


> Very nice explanation!  Not sure if I could have done better myself.
>
> Jeff Lauruhn
> NAND Application Engineer
> Embedded Business Unit
> Micron Technology, Inc
>
>
> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon at free-electrons.com]
> Sent: Tuesday, March 17, 2015 3:02 AM
> To: Andrea Scian
> Cc: Jeff Lauruhn (jlauruhn); Richard Weinberger; dedekind1 at gmail.com; 
> mtd_mailinglist
> Subject: Re: RFC: detect and manage power cut on MLC NAND
>
> Hi Andrea,
>
> I'll let Jeff answer this question, but I'd like to share my understanding.
>
> On Tue, 17 Mar 2015 10:30:30 +0100
> Andrea Scian <rnd4 at dave-tech.it> wrote:
>
>>
>>
>> Dear Jeff,
>>
>> Il 16/03/2015 22:11, Jeff Lauruhn (jlauruhn) ha scritto:
>>> Good morning Boris;
>>> RR is a new feature and not available on all parts few.  I'm not 
>>> sure about others, but since these are features, you simply enable 
>>> of disable via SET FEATURE/GET FEATURE.  If you already provide that 
>>> SET/GET FEATURE functionality then an end-user determine if their 
>>> device supports a feature and then write the code to enable when 
>>> they need it on their particular design.
>>
>> I can confirm this. In fact I'm currently working with two Micron NAND:
>>
>> MT29F32G08CBACAWP
>> MT29F32G08CBADAWP
>>
>> The latter should be "just" a newer die revision of the former (at 
>> least, this is what our distributor says)
>>
>> There's a technology change between the two and, in fact, the latter 
>> supports RR while there's no mention of such a feature inside rev C.
>>
>> Jeff, could you please help me in understanding which if the 
>> following sentences are true and which are false?
>> - rev D is more "robust" than rev C because it has RR (so an 
>> additional feature that improve error correction)
>> - rev D is "robust" like rev C, if rev D is used with RR
>> - if RR is not used rev D is more error prone than rev C
>
> RR shouldn't change NAND robustness (or sensitivity to read/write disturbance generating bitflips).
>
> AFAIU RR will help you improve your NAND lifetime, because you're allowed to change voltage thresholds which means you can fix errors that were previously considered as unfixable and lead to blocks being marked bad earlier.
>
> I'll let Jeff correct me if I'm wrong ;-).
>
>>
>> I think this is crucial to understand how RR works and how much is 
>> needed inside MTD/UBI code.
>
> Hopefully this can all be handled in the MTD layer, with some help from the UBI layer to feed the wear information (number of P/E cycles on each block).
>
> Best Regards,
>
> Boris
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
>
>




More information about the linux-mtd mailing list