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