Re: [Yaffs] Storing of OOD data on NAND

On 02/07/2014 12:54 PM, hcgoffo2@rockwellcollins.com wrote:
> I am in the middle of writing the driver to store the ood data into
> the spare area on flash.
>
> Does the YAFFS2 structure already take into account the bad block
> marker in the first byte? or should I save the data at an offset so
> that the first byte is not touched?
>
> From what I see, the structure of the ood is as follows: (Which is NOT
> what is shown in the Yaffs2 Specification document)
>

> *struct*yaffs_packed_tags2_tags_only*{*
>    *unsigned**int*seq_number*;*
>    *unsigned**int*obj_id*;*
>    *unsigned**int*chunk_id*;*
>    *unsigned**int*n_bytes*;*
> }

>
> This data is passed to the driver to store. Which means that the
> seq_number value ends up being programmed where the bad block marker
> is. which is not good, as ONFI spec says if the bad block marker (
> first byte if the spare area in the first page of a block) is not
> 0XFF, the block is bad and should not be used.
>
> I was thinking of modifying the above structure it add an unsigned int
> to account for the bad block marker position. and whe writting,
> setting it to 0xFF.
>
> Is this correct, or is there another structure I should be looking at?
>
I believe you should separate the metadata layout of YAFFS from the
underlying NAND OOB layout.

Various NAND have different OOB needs for bad block markers and
ECCbytes/layout and its best to hide those requirements within the NAND
layer itself.

As an example in Linux, the OOB layout for a Micron NAND with in-chip
BCH4 ECC is defined as:

ecclayout = {
    eccbytes = 32,
    eccpos = { 8, 9, 10, 11, 12, 13, 14, 15,
        24, 25, 26, 27, 28, 19, 30, 31,
        40, 41, 42, 43, 44, 45, 46, 47,
        56, 57, 58, 59, 60, 61, 62, 63},
    .oobfree = {
        { .offset = 4,
          .length = 4},
        { .offset = 20,
          .length = 4},
        { .offset = 36,
          .length = 4},
        { .offset = 52,
          .length = 4},
    },
};

Where the ECC resides in OOB bytes 8-15, 24-31, 40-47, 56-63 (zero
based). The area of the OOB that can be written with metadata is 4-7,
20-23, 36-39, 52-55. So the first four bytes of the metadata are copied
into/out of bytes 4-7 of the OOB, the next four bytes are copied
into/out of bytes 20-23, etc. Note in this case that the YAFFS tag can
not contain ECC (as there is only 16 bytes of available OOB space), but
since the embedded NAND ECC spans not only the data area, but those 16
bytes of OOB, a 2nd ECC of the metadata is not necessary.

YAFFS wouldn't know of the OOB layout - it has to present a contiguous
buffer that contains the metadata (for pages to be written), for pages
read the underlying NAND driver would copy back a contiguous buffer
containing the metadata in the same order. This allows changing
NAND/ECC w/o needing to modify YAFFS.

--
Peter Barada
peter.barada@logicpd.com