On 10/6/06, Charles Manning <
manningc2@actrix.gen.nz> wrote:
>
> > Yea, I was surprised with that as well, However, after some
> > considerations, I'm close to the conclusion that it's
> > controller-specific. The thing is that the OOB is spread across the
> > page IOT facilitate HW ECC, so it's (512b data, 16b OOB) x 4 actually
> > for each page, so each OOB write is costly. However, such things
> > appear more and more as manufacturers go producing cheaper chips that
> > need stronger ECC.
>
> Well that is a "driver thing" in some ways too. A particular driver that
> is
> unfriendly to oob writing will penalise yaffs2. As always, a streamlined
> custom driver is going to be faster than a generic one, and is the
> approach
> taken by almost all those interested in top performance.
>
I'd like to disagree with you here. It's basically not a "driver thing"
since it's forced by HW. The "weird" layout is due to the need for the
controller to be able to perform HW ECC.
This is a MLC flash chip so it needs strong ECC capabilities, therefore the
other sensible option would be to have standard data and OOB layout and to
use software Reed-Solomon ECC, which is unlikely to be faster (though it 's
likely to show better results for yaffs2 compared to jffs2).
But again, here's how the things are going now. Cheaper chips, more
capacity, stronger and more complicated ECC algorithms, and therefore less
spare OOB left, HW ECC restrictions on the OOB layout...
Vitaly
(text/plain)