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 1RLtNG-0004tm-Bm for linux-mtd@lists.infradead.org; Thu, 03 Nov 2011 09:14:15 +0000 Message-ID: <4EB25B62.4070502@parrot.com> Date: Thu, 3 Nov 2011 10:14:10 +0100 From: Matthieu CASTET MIME-Version: 1.0 To: Ivan Djelic Subject: Re: [PATCH v2] mtd: nand: Add driver for M-sys / Sandisk diskonchip G4 References: <1320274859-3270-1-git-send-email-mikedunn@newsguy.com> <20111103085824.GA28465@parrot.com> In-Reply-To: <20111103085824.GA28465@parrot.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Cc: "linux-mtd@lists.infradead.org" , Mike Dunn List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, Ivan Djelic a écrit : > On Wed, Nov 02, 2011 at 11:00:59PM +0000, Mike Dunn wrote: > > Hi Mike, > A few comments below: > >> + >> +/* value generated by the HW ecc generator upon reading blank page */ >> +static uint8_t blank_read_hwecc[7] = { >> + 0xcf, 0x72, 0xfc, 0x1b, 0xa9, 0xc7, 0xb9 }; > > Using this blank ecc value to detect blank pages after reading them is not that > reliable, because if a bitflip appears in an erased page, the HW ecc generator > will generate a completely different sequence of bytes. Your driver will think > the page is not blank, it will try to correct errors and fail. And UBIFS will > not appreciate that. > > I can see two cleaner alternatives to solve this issue: > > 1. When you program a page, before writing hwecc to oob, adjust it like this: > > hwecc[i] ^= blank_read_hwecc[i]^0xff; > > The effect of this is that you now get 0xffs as ecc for blank pages, and bitflip > correction on erased pages for free. This is transparent to your controller, > because this "adjustment" cancels itself upon reading when calc_ecc^recv_ecc is > computed. > > 2. Use unprotected spare oob byte 15 as a programmming marker: remove it from > the oob_free list, and force it to 0 when you program a page. Now, you can > easily detect if a page is blank or has been programmed by checking this byte. > You can for instance count the number of bits set to 1 in the byte, and decide > it is blank if that number is greater than 4; this ensures you are robust to > bitflips in the marker byte itself. > > My preference would go to option 2 in your case. > Note that UBIFS except blank page to be 0xff. With option 1 you have nothing to do (ecc correct bit-flips), with option 2 you have to memset the page (data+spare) to 0xff to clear bit-flips. Also with option 2 you don't know how many bit-flip there are in the blank page. Because UBIFS (or mtd) don't check the page after a write , you can end writting a page with too many bit-flips without any error. Matthieu