* ARM: LPC32XX SLC ECC Handling @ 2012-08-08 9:16 Sebastian Huber 2012-08-24 11:38 ` Artem Bityutskiy 0 siblings, 1 reply; 6+ messages in thread From: Sebastian Huber @ 2012-08-08 9:16 UTC (permalink / raw) To: Linux MTD 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: LPC32XX SLC ECC Handling 2012-08-08 9:16 ARM: LPC32XX SLC ECC Handling Sebastian Huber @ 2012-08-24 11:38 ` Artem Bityutskiy 2012-08-24 12:54 ` Roland Stigge 0 siblings, 1 reply; 6+ messages in thread From: Artem Bityutskiy @ 2012-08-24 11:38 UTC (permalink / raw) To: Sebastian Huber, Roland Stigge; +Cc: Linux MTD [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: LPC32XX SLC ECC Handling 2012-08-24 11:38 ` Artem Bityutskiy @ 2012-08-24 12:54 ` Roland Stigge 2012-08-29 8:33 ` Artem Bityutskiy 0 siblings, 1 reply; 6+ messages in thread From: Roland Stigge @ 2012-08-24 12:54 UTC (permalink / raw) To: dedekind1; +Cc: Sebastian Huber, Linux MTD 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: LPC32XX SLC ECC Handling 2012-08-24 12:54 ` Roland Stigge @ 2012-08-29 8:33 ` Artem Bityutskiy 2012-08-29 11:52 ` Roland Stigge 0 siblings, 1 reply; 6+ messages in thread From: Artem Bityutskiy @ 2012-08-29 8:33 UTC (permalink / raw) To: Roland Stigge; +Cc: Sebastian Huber, Linux MTD [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: LPC32XX SLC ECC Handling 2012-08-29 8:33 ` Artem Bityutskiy @ 2012-08-29 11:52 ` Roland Stigge 2012-09-15 3:59 ` Brian Norris 0 siblings, 1 reply; 6+ messages in thread From: Roland Stigge @ 2012-08-29 11:52 UTC (permalink / raw) To: dedekind1; +Cc: Sebastian Huber, Linux MTD 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: LPC32XX SLC ECC Handling 2012-08-29 11:52 ` Roland Stigge @ 2012-09-15 3:59 ` Brian Norris 0 siblings, 0 replies; 6+ messages in thread From: Brian Norris @ 2012-09-15 3:59 UTC (permalink / raw) To: Roland Stigge; +Cc: Sebastian Huber, Linux MTD, dedekind1 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-09-15 3:59 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-08 9:16 ARM: LPC32XX SLC ECC Handling Sebastian Huber 2012-08-24 11:38 ` Artem Bityutskiy 2012-08-24 12:54 ` Roland Stigge 2012-08-29 8:33 ` Artem Bityutskiy 2012-08-29 11:52 ` Roland Stigge 2012-09-15 3:59 ` Brian Norris
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).