On Saturday 08 February 2014 06:54:08 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?

No.

The Yaffs1 structure does, but not Yaffs2.

Nor does the Yaffs2 tags structure hold info on the data ECC either.

Yaffs1 layout was specifically done to follow the SmartMedia NAND layout.

It was done this way for a very good reason: the newer devices and chipsets 
and drivers that Yaffs2 works with have varying  OOB layouts and it is 
desirable to provide flexibility.

For example, one driver or chipset might store
2 bytes bad block marker, 20 bytes of ECC and then the rest unused.

and another might store
2 bytes of bad block, then 4 bytes of ECC then 10 bytes of unused then another 
4 bytes of ECC... and so on

Thus, the intention of the Yaffs2 structure is that the driver stores the data 
in the unused bytes where it can and the driver must sort this out.

Yaffs says "store these bytes, I don't care where, just give them back to me 
when I ask".

The Yaffs2 interface also asks the driver to determine whether a block is bad, 
or has ECC issues, etc. Thus it is the driver's job to determine how these 
are marked or achieved.

If this is difficult to achieve (eg. too hard to modify the drivers or too 
little unused space), then you can use inband tags. These store the tags in 
the data area so Yaffs does not use the OOB area and the driver can use it 
all.

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

In your driver figure out the placement you are using, then implement the idea 
as described above.

Please feel free to ask further if you get stuck.

-- CHarles