Hi Naga, + Martin
Naga Sureshkumar Relli <[email protected]> wrote on Tue, 18 Dec 2018 05:33:53 +0000: > Hi Miquel, > > > -----Original Message----- > > From: Miquel Raynal [mailto:[email protected]] > > Sent: Monday, December 17, 2018 10:11 PM > > To: Naga Sureshkumar Relli <[email protected]> > > Cc: Boris Brezillon <[email protected]>; [email protected]; > > [email protected]; linux- > > [email protected]; [email protected]; > > [email protected]; > > [email protected]; Michal Simek <[email protected]>; > > [email protected]; [email protected] > > Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for > > Arasan > > NAND Flash Controller > > > > Hi Naga, > > > > [...] > > > > > Inserted biterror @ 48/7 > > > Successfully corrected 25 bit errors per subpage Inserted biterror @ > > > 50/7 ECC failure, invalid data despite read success > > > root@xilinx-zc1751-dc2-2018_1:~# > > > > > > But even in this case also, driver is saying ECC failure but read success. > > > That means controller is able to detect errors on read page up to 24 bit > > > only. > > > After that there is no way to say to the upper layers that the page is > > > bad because of the > > limitation in the controller. > > > > This is more than a "limitation", the design is broken. I am not sure how > > to support such > > controller, and I am not sure if we even want to. > > The number of errors that are correctable is limited by a parameter 't'(total > number of errors), > If there is a condition that the number of errors greater than 't', then the > controller won't be able to detect that. > I guess this concept is same for other controllers as well. > In Arasan it is limited to 24-bit. > > Even, in case of Hamming, it is 1-bit error correction and 2-bit error > detection. > What will happen if there are multiple errors(greater than 2-bit)? Ok let's use the Hamming comparison in your ECC engine case. -> hamming: * 0 bf: everything is fine * 1 bf: will be detected, corrected, signaled * 2 bf: will be detected, not corrected, signaled * 3+ bf: don't care -> BCH: * 0 bf: everything is fine * 1-24 bf: will be detected, corrected, signaled * 25 bf: everything is fine * 26+ bf: don't care Do you see the problem? In the 25 bf case, the controller is reporting that everything went fine while it should report that it detected an uncorrectable situation. Here are two leads to solve this issue, please investigate them both: 1/ Talk to your colleagues that developed the RTL, ask if there is a hidden/reserved bit for that purpose that is not documented. 2/ Search for a status in the registers that might indicate that an error occurred, for instance "0 bf corrected" and "bf have been detected". NB: I know that, with a BCH ECC engine, error detection at (strength + 1) is not 100% sure but statistically it will almost always be detected and in this case we need the controller to warn the user! Thanks, Miquèl
