ARM: LPC32XX SLC ECC Handling

ARM: LPC32XX SLC ECC Handling

[Sebastian Huber]

Hi,

the LPC32XX SLC controller has a ECC feature that covers only the main data 
area, but not the OOB data.  Is it the responsibility of the user to protect 
its OOB data via an ECC?  The LPC32XX MLC controller on the other hand covers 
the complete OOB data with its ECC.  How can a user determine if it has to 
protect its OOB data?

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: ARM: LPC32XX SLC ECC Handling

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

On Wed, 2012-08-08 at 11:16 +0200, Sebastian Huber wrote:
> Hi,
> 
> the LPC32XX SLC controller has a ECC feature that covers only the main data 
> area, but not the OOB data.  Is it the responsibility of the user to protect 
> its OOB data via an ECC?  The LPC32XX MLC controller on the other hand covers 
> the complete OOB data with its ECC.  How can a user determine if it has to 
> protect its OOB data?

I guess it is good idea to CC the author of the drivers.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ARM: LPC32XX SLC ECC Handling

[Roland Stigge]

Hi!

On 24/08/12 13:38, Artem Bityutskiy wrote:
>> the LPC32XX SLC controller has a ECC feature that covers only the
>> main data area, but not the OOB data.  Is it the responsibility
>> of the user to protect its OOB data via an ECC?  The LPC32XX MLC
>> controller on the other hand covers the complete OOB data with
>> its ECC.  How can a user determine if it has to protect its OOB
>> data?
> 
> I guess it is good idea to CC the author of the drivers.

Thanks for CC'ing, would have missed it.

Yes, it's exactly as Sebastian described - only the MLC controller
covers OOB in ECC.

At this point, I need to give back the question to the MTD
maintainers: Is there an API how we can help users at this point? I
would be happy to implement it.

Thanks,

Roland

Re: ARM: LPC32XX SLC ECC Handling

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

On Fri, 2012-08-24 at 14:54 +0200, Roland Stigge wrote:
> Hi!
> 
> On 24/08/12 13:38, Artem Bityutskiy wrote:
> >> the LPC32XX SLC controller has a ECC feature that covers only the
> >> main data area, but not the OOB data.  Is it the responsibility
> >> of the user to protect its OOB data via an ECC?  The LPC32XX MLC
> >> controller on the other hand covers the complete OOB data with
> >> its ECC.  How can a user determine if it has to protect its OOB
> >> data?
> > 
> > I guess it is good idea to CC the author of the drivers.
> 
> Thanks for CC'ing, would have missed it.
> 
> Yes, it's exactly as Sebastian described - only the MLC controller
> covers OOB in ECC.
> 
> At this point, I need to give back the question to the MTD
> maintainers: Is there an API how we can help users at this point? I
> would be happy to implement it.

Well, I guess from the user's POW the driver either protects OOB data
with ECC or not. There is no interface for detecting this in MTD, but I
do not see why someone could not create it.

Am I right that we are talking about the situation when OOB and data
areas are covered by different ECCs, or this is about user writing data
+oob at one go, and everything is covered by the same ECC?

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ARM: LPC32XX SLC ECC Handling

[Roland Stigge]

On 08/29/2012 10:33 AM, Artem Bityutskiy wrote:
>>>> the LPC32XX SLC controller has a ECC feature that covers only
>>>> the main data area, but not the OOB data.  Is it the
>>>> responsibility of the user to protect its OOB data via an
>>>> ECC?  The LPC32XX MLC controller on the other hand covers the
>>>> complete OOB data with its ECC.  How can a user determine if
>>>> it has to protect its OOB data?
>>> 
>>> I guess it is good idea to CC the author of the drivers.
>> 
>> Thanks for CC'ing, would have missed it.
>> 
>> Yes, it's exactly as Sebastian described - only the MLC
>> controller covers OOB in ECC.
>> 
>> At this point, I need to give back the question to the MTD 
>> maintainers: Is there an API how we can help users at this point?
>> I would be happy to implement it.
> 
> Well, I guess from the user's POW the driver either protects OOB
> data with ECC or not. There is no interface for detecting this in
> MTD, but I do not see why someone could not create it.
> 
> Am I right that we are talking about the situation when OOB and
> data areas are covered by different ECCs, or this is about user
> writing data +oob at one go, and everything is covered by the same
> ECC?

In the above case of LPC32xx/MLC NAND (not sure if this is common with
other controllers), the controller covers 512 (sub)pages plus some OOB
bytes with a single ECC operation, storing it behind those covered OOB.

Roland

Re: ARM: LPC32XX SLC ECC Handling

[Brian Norris]

Hi,

On Wed, Aug 29, 2012 at 4:52 AM, Roland Stigge <stigge@antcom.de> wrote:
> On 08/29/2012 10:33 AM, Artem Bityutskiy wrote:
>>>>> the LPC32XX SLC controller has a ECC feature that covers only
>>>>> the main data area, but not the OOB data.  Is it the
>>>>> responsibility of the user to protect its OOB data via an
>>>>> ECC?  The LPC32XX MLC controller on the other hand covers the
>>>>> complete OOB data with its ECC.  How can a user determine if
>>>>> it has to protect its OOB data?

I haven't dealt with this question, since I basically don't support
user data in OOB on my system. I'm basically using only UBI. But see
my other comments below.

>>>> I guess it is good idea to CC the author of the drivers.
>>>
>>> Thanks for CC'ing, would have missed it.
>>>
>>> Yes, it's exactly as Sebastian described - only the MLC
>>> controller covers OOB in ECC.
>>>
>>> At this point, I need to give back the question to the MTD
>>> maintainers: Is there an API how we can help users at this point?
>>> I would be happy to implement it.
>>
>> Well, I guess from the user's POW the driver either protects OOB
>> data with ECC or not. There is no interface for detecting this in
>> MTD, but I do not see why someone could not create it.
>>
>> Am I right that we are talking about the situation when OOB and
>> data areas are covered by different ECCs, or this is about user
>> writing data +oob at one go, and everything is covered by the same
>> ECC?
>
> In the above case of LPC32xx/MLC NAND (not sure if this is common with
> other controllers),

By my experience in interacting with the community, few controllers
have support for protecting OOB with ECC, and even fewer drivers
actual implement it. I think my (out-of-tree) driver was the only one
that could ever reported bitflips for OOB transactions. And for
instance, I added the read_oob/read_oob_raw and
write_oob/write_oob_raw clarification in nand_ecc_ctrl, but there are
no in-tree users that differentiate the two...

> the controller covers 512 (sub)pages plus some OOB
> bytes with a single ECC operation, storing it behind those covered OOB.

My controller is basically the same.

Brian