Messages in this thread | | | From | Robert Jarzmik <> | Subject | Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo | Date | Sun, 13 Nov 2011 11:18:16 +0100 |
| |
Mike Dunn <mikedunn@newsguy.com> writes:
> On 11/10/2011 12:05 AM, Robert Jarzmik wrote: >> +static struct nand_ecclayout docg3_oobinfo = { >> + .eccbytes = 8, >> + .eccpos = {7, 8, 9, 10, 11, 12, 13, 14}, >> + .oobfree = {{0, 7}, {15, 1} }, >> + .oobavail = 8, >> +}; >> +
I took a different approach. I check an internal docg3 register to see if the page was written. Or I could had have checked the Hamming code, as I don't think it can be 0xff whatever the pagesize 7 bytes values.
The reason behind is that the Hamming code is Ham(64, 57), ie. Ham(2^6, 2^6-6-1). The means the 6 bits are enough to cover all codewords possibilities, and 0xff is not one of them.
So unless a bitflip in Hamming code, 0xff in it means blank page. And I think the ECC engine is even smarter, with the ECCCONF1_PAGE_IS_WRITTEN.
> > Just FYI, per Ivan's suggestion, I changed this to use the last oob byte as a > "page programmed" flag for the purpose of detecting bit flips when reading a > blank page. Maybe something to keep in mind. You can have a look at the latest > G4 driver patch to see exactly how I use it. I personally think this should be provided by the MTD API. A function is_page_blank(ofs) could tell if the page was written or not. Now if the function is NULL, the upper layer (UBIFS, ...) could decide _by itself_ to assign a free OOB byte to that meaning. But IMHO it's not the drivers duty to take these decisions to restrict the OOB, let it be done at an upper level.
Cheers.
-- Robert
| |