From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp1-g21.free.fr ([212.27.42.1]) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1REFG4-0004P5-5E for linux-mtd@lists.infradead.org; Thu, 13 Oct 2011 06:59:13 +0000 From: Robert Jarzmik To: Ivan Djelic Subject: Re: [PATCH] Add driver for M-sys / Sandisk diskonchip G4 nand flash References: <1318258091-12670-1-git-send-email-mikedunn@newsguy.com> <201110101751.19010.marek.vasut@gmail.com> <20111010181210.GA23655@parrot.com> <4E935D5D.4050504@newsguy.com> <20111011115034.GA28920@parrot.com> <4E949642.9020209@newsguy.com> <20111012184903.GA9535@parrot.com> Date: Thu, 13 Oct 2011 08:58:53 +0200 In-Reply-To: <20111012184903.GA9535@parrot.com> (Ivan Djelic's message of "Wed, 12 Oct 2011 20:49:03 +0200") Message-ID: <871uuhl6mq.fsf@free.fr> MIME-Version: 1.0 Content-Type: text/plain Cc: Marek Vasut , Mike Dunn , "linux-mtd@lists.infradead.org" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Ivan Djelic writes: > On Tue, Oct 11, 2011 at 08:17:22PM +0100, Mike Dunn wrote: >> On 10/11/2011 04:50 AM, Ivan Djelic wrote: >> > >> > After a more careful examination, I believe your hardware gives you >> > recv_ecc^calc_ecc >> >> It might be a little more complicated. > > Well, thanks to your ecc samples I have the answer now; the hardware does > provide recv_ecc^calc_ecc, with a little twist: a parity code in inserted into > data before performing BCH remainder computations. > Here is a more precise description: > > writing algorithm: > ----------------- > 1. 512 bytes of data are sent to HW generator > 2. 7 bytes of user data (oob[0] to oob[6]) are sent to HW generator > 3. A Hamming (?) parity byte is generated (from oob[0]...oob[6]?) and sent to > HW generator > 4. The BCH engine completes its polynomial remainder computation on the above > 520 bytes > > Note that the HW generator reads and writes bytes in reversed bit order. > > I don't really know how the parity byte in step 3 is generated, or what its > purpose is; it may be there to allow oob reading without performing a full BCH > decode, but the code seems too small to me to protect anything in a useful way. > The nice thing is, we don't really need this code to perform BCH decoding. Hi Ivan, For the lonely parity byte, I can confirm it's a Hamming parity over 7 bytes. This parity byte is generated by the hardware as well when the page is written : - 512 bytes of data are written into the page - then 7 bytes of OOB are written - then the "Hamming HW register is read" => we get the ECC back => this is the generation you're talking about - then 1 byte of OOB is written => we write the Hamming ECC - then 7 bytes of BCH ECC registers are read - then 7 bytes of BCH ECC are written - then 1 byte (dummy byte) is written The exciting part is that with Mike and your work, I know what the unexplained '7' now means, and that I can add the ECC checks to docg3 :) Cheers. -- Robert