Doubt regarding mtd test ( mtd_oobtest ) interpretation of oob data !

Artem Bityutskiy dedekind1 at gmail.com
Wed Sep 16 06:50:23 EDT 2009


On Wed, 2009-09-16 at 15:50 +0530, Murali N wrote:
> Hi Artem, can you please explain me a bit more about OOB_PLACE mode?.
> Also in mtd tests i have seen there is ooboffs field being used in
> OOB_AUTO mode.My doubt here was why AUTO mode cares about ooboffs
> field.ECC layout structure is defined clearly in the AUTO mode? am i
> correct? then what is the significance of ooboffs field?
> 
> i am not caring the ooboffs when the AUTO mode is selected in my
> driver? i was bit confused where it is mentioned in the MTD
> specification? can you please point to me if you have any info!!!

I do not remember all the glory details, but in short, OOB_PLACE is
used when you want to put your date to a specific _physical_ offset
withing the OOB. Very simple and straightforward. But I consider this
as legacy and I think no one should ever use this, and this should
be forbidden. I might be wrong, though.

OOB_AUTO is the sanest thing. Your OOB area may contain N small unused
regions of different length. E.g., see OneNAND's onenand_oob_64.
Different flashes have different layout. And OOB_AUTO is about
abstracting this, so all these small regions look like a contiguous
buffer to the applications. Size of this buffer is
mtd->ecclayout->oobavail bytes. You may write data do different offsets
of this buffer, and they will be automatically placed to corresponding
_physical_ offsets within the OOB. So applications do not care about
the OOB fragmentation, and always work with this _logical_ OOB_AUTO
buffer.

In OOB_AUTO case you cannot access the ECC bytes, because they are
hidden from you.

In OOB_PLACE you can, and I think it is a bad idea because it is not
applications' business to deal with ECCs. This should be hidden.

That's all I remember at this point. Nowadays we do not use OOB much.
E.g., UBI/UBIFS does not use it. Using OOB is bad, because modern
flashes may utilize _whole_ OOB for ECCs.

HTH.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)




More information about the linux-mtd mailing list