From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from co202.xi-lite.net ([149.6.83.202])
	by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux))
	id 1REGnz-0006Uo-3M
	for linux-mtd@lists.infradead.org; Thu, 13 Oct 2011 08:38:19 +0000
Date: Thu, 13 Oct 2011 10:37:04 +0200
From: Ivan Djelic <ivan.djelic@parrot.com>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Subject: Re: [PATCH] Add driver for M-sys / Sandisk diskonchip G4 nand flash
Message-ID: <20111013083704.GA12110@parrot.com>
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> <871uuhl6mq.fsf@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <871uuhl6mq.fsf@free.fr>
Cc: Marek Vasut <marek.vasut@gmail.com>, Mike Dunn <mikedunn@newsguy.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd/>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

On Thu, Oct 13, 2011 at 07:58:53AM +0100, Robert Jarzmik wrote:
> 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

OK, thanks. I had missed a few comments in Mike's code about this.

I'm still a little puzzled as to how this Hamming code works.
If it was meant to correct 1 bitflip in 7 bytes + 1 parity byte, then it
should be at least 12 bits long.
If the idea is to simply detect a single bitflip, then 6 bits are enough.
Maybe the probability of having 2 bitflips in 7 oob bytes is low enough to
allow reading oob using this simple check ?
 
> 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 :)

Nice :)
And kudos to you and Mike for the reverse-engineering...

--
Ivan