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

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

[David Brownell]

I noticed

 http://lists.infradead.org/pipermail/linux-mtd/2009-June/026133.html

I don't think I understand the question.  But I have two comments
that might help:

 - First, the ECC schemes don't dictate much about how the
   OOB area gets laid out, so what's the problem?  Just pick a
   layout that doesn't clobber manufacturer bad block markers
   and you'll be pretty much OK.  Stick all ECC at the end, to
   keep it simple.

 - 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.

ECC_HW should probably work fine.  You'll just provide your
own ecclayout struct, and set things up so the NAND core knows
the hardware works in 512 byte chunks that give 7 byte each of
ECC data.

- Dave

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

[vimal singh]

On Fri, Jun 26, 2009 at 9:58 AM, David Brownell<david-b@pacbell.net> wrote:
> I noticed
>
>  http://lists.infradead.org/pipermail/linux-mtd/2009-June/026133.html
>
> I don't think I understand the question.  But I have two comments
> that might help:
>
>  - First, the ECC schemes don't dictate much about how the
>   OOB area gets laid out, so what's the problem?  Just pick a
>   layout that doesn't clobber manufacturer bad block markers
>   and you'll be pretty much OK.  Stick all ECC at the end, to
>   keep it simple.
>
>  - 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?

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)

>
> ECC_HW should probably work fine.  You'll just provide your
> own ecclayout struct, and set things up so the NAND core knows
> the hardware works in 512 byte chunks that give 7 byte each of
> ECC data.
>
> - Dave
>



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

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

[David Brownell]

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)

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

Re: 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@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
------   -\<,
-----  ( )/ ( )

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

[David Brownell]

On Friday 26 June 2009, vimal singh wrote:
> 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.

Healthy.  I disike that "infix OOB" myself.  It is however
a standard ECC mode in the NAND framework.  :(

So you're asking about how to map hardware-specific details
to the NAND framework?  That wasn't clear.


> Would it not be the good idea to perform read/write for full (2112 bytes) page?

I'm not sure I can answer that without reading up on that
particular NAND ECC engine.

Recall however that the NAND framework will think in terms
of 2KB reads, with OOB data on the side.  There will be
separate reads for 2K and then 64 bytes.


> 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.

Those sentences seem to elide critical parts of the process.
Like the details of OOB and ECC handling, which seem to be
what you're not sure of...

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

[Amit Kumar Sharma]

Hi Vimal,

> On Friday 26 June 2009, vimal singh wrote:
>> 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.
>
> Healthy.  I disike that "infix OOB" myself.  It is however
> a standard ECC mode in the NAND framework.  :(
>
> So you're asking about how to map hardware-specific 
> details
> to the NAND framework?  That wasn't clear.

I think better you use some of the bytes of OOB area , In 
almoost al NAND you can read 2K page size or 4K page size 
additinal you have to read OOB or spare area of NAND.
>
>
>> Would it not be the good idea to perform read/write for 
>> full (2112 bytes) page?
>
> I'm not sure I can answer that without reading up on that
> particular NAND ECC engine.
>
> Recall however that the NAND framework will think in terms
> of 2KB reads, with OOB data on the side.  There will be
> separate reads for 2K and then 64 bytes.
>
>
>> 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.
I donot think when Hw_ecc is enable some software ECC 
calculation is required.
>
> Those sentences seem to elide critical parts of the 
> process.
> Like the details of OOB and ECC handling, which seem to be
> what you're not sure of...
>
>

Thanks
Amit
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/ 

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

[vimal singh]

On Sat, Jun 27, 2009 at 10:47 AM, Amit Kumar
Sharma<amitsharma.9@samsung.com> wrote:
> Hi Vimal,
>
>> On Friday 26 June 2009, vimal singh wrote:
>>> 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.
>>
>> Healthy.  I disike that "infix OOB" myself.  It is however
>> a standard ECC mode in the NAND framework.  :(
>>
>> So you're asking about how to map hardware-specific
>> details
>> to the NAND framework?  That wasn't clear.

Yes, that's right.

> I think better you use some of the bytes of OOB area , In
> almoost al NAND you can read 2K page size or 4K page size
> additinal you have to read OOB or spare area of NAND.
>>
>>
>>> Would it not be the good idea to perform read/write for
>>> full (2112 bytes) page?
>>
>> I'm not sure I can answer that without reading up on that
>> particular NAND ECC engine.
>>
>> Recall however that the NAND framework will think in terms
>> of 2KB reads, with OOB data on the side.  There will be
>> separate reads for 2K and then 64 bytes.

The question is, how to involve 'main area bytes + OOB bytes (+ ECC
bytes, in case of reads)', while writing / reading a page to/from nand
device.

>>
>>
>>> 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.
> I donot think when Hw_ecc is enable some software ECC
> calculation is required.

You may need SW algo to correct the errors indicated by HW generated ECCs.

>>
>> Those sentences seem to elide critical parts of the
>> process.
>> Like the details of OOB and ECC handling, which seem to be
>> what you're not sure of...

OOB area details are part of filesystem used in question. But we
certainly have control over defining layout for OOB area, which then
can be used by any upper layer SW component.

>>
>>
>
> Thanks
> Amit
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
>



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

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

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

[vimal singh]

I am implementing BCH HW ECC method (present in omap2/3), which can
provide ECC protection
for spare area bytes too, along with main area bytes.
Below are few details:
1. It is a large page NAND device
2. We are looking for upto 4-bit error correction (for each 512 + 9 bytes)

Nand has 2048 + 64 bytes page size. (main area + spare area). The
layout I am creating is:
(all other possible layouts are similar to this only for this HW ECC scheme)

|<------main area, divided into 4-sectors----->|<-----Protected spare
area------>|<----------ECC bytes-------->|
|   512      +    512    +    512    +    512      |    9    +    9
+    9    +    9    |   7   +   7   +   7   +   7    |
|<-- 1st --> <-- 2nd --> <-- 3rd --> <-- 4th -->|<-1st-> <-2nd->
<-3rd-> <-4th->|<1st> <2nd> <3rd> <4th>|

i.e. 7 ECC bytes (52 bits in actual) for each 512 + 9 bytes (main +
spare), to correct up to 4- errors.


My concern is that, none of the present ECC scheme (in nand_base.c)
seems suitable for this.
Do I need to implement new ECC scheme, and hence new read / write API's?

In that case too, main question is: how to handle oob read/write for
such layout? (where spare
area bytes are protected along with main are ECC)

Any suggestion / help is appreciated.
Thanks in advance.

---
Regards,
Vimal