query: nand read/write method for 2048 + 64 byte page

[vimal singh]

On Fri, Jun 26, 2009 at 11:26 AM, David Brownell<david-b at pacbell.net> wrote:
> On Thursday 25 June 2009, vimal singh wrote:
>> >  - Second, I believe that you will see some issues if you
>> >   try to have ECC cover the OOB too.  Problem being that
>> >   the raw_write primitives are used to write OOB data and
>> >   they don't believe it will be ECC protected.
>>
>> My point is to protect OOB too (other than ECC bytes).
>> So, should we implement new OOB area read/write primitives to support this?
>
> It's not so much a case of "can it be done"; you may have
> noticed that ECC_HW_SYNDROME can do that.  While that layout
> is problematic, it certainly allows for "prepad" data to be
> included in the ECC.  For a 2K page, with 7 ECC bytes for
> each 512+9 bytes of data, the page layout is
>
>        4 * (512 bytes data + 9 bytes OOB + 7 bytes ECC)

The problem is that HW ECC engine in BCH mode dose not provide any
possible configuration where we can keep ECC bytes in main area
itself. OOB + ECC data has to be in only spare area.

Would it not be the good idea to perform read/write for full (2112 bytes) page?
And enable HW_ECC before read/write and then call for ecc.calculate or
ecc.correct accordingly. Rest all things can be taken care by
underlying controller driver.

>
> where prepad == 9 ... but such layouts have obvious nasty
> characteristics, since you can't DMA the whole 2K of data
> in one chunk, and since it clobbers manufacturer bad block
> markers.
>
> (FWIW I call such layouts "Infix OOB", where the Out-of-Band
> data is actually not out-of-band in the spare area.)
>
>
> Or if the hardware allows you could just use 521 byte ECC
> chunks (8-bit NAND only!) and when you run out of 2K page
> buffer, roll directly into the OOB data.  You'd have to
> provide i/o methods that manage OOB and ECC data that way,
> but that seems like it'd suffice as a driver-specific kind
> of override, using ECC_HW and your matching ecclayout.
>
>
>> And in that case how will we be handling those cases where spare bytes
>> are protected by clubbing them with main area bytes to generate ECC?
>> (as example in my previous mail)
>
> You haven't addressed my observation that there's software
> out there which is going to be writing the OOB data and yet
> not expecting it to invalidate the ECC... as in, maybe you
> want to change a version byte from 0x0f to 0x10.  That has
> the look of a five bit ECC error!  Or from 0x10 to 0x11,
> well that's an easily corrected single bit error.
>
> - Dave
>
>
>



-- 
---
Regards,
\/ | |\/| /-\ |_

____      __o
------   -\<,
-----  ( )/ ( )