+<H2>MTD Interface</H2>
+<P>As mentioned before, YAFFS2 requires a chunk-size of at least 1kB
+to get a large enough spare area to support the increased size of the
+tags. This is not really a disadvantage, but should rather be viewed
+as an opportunity to exploit the NAND hardware more effectively. In
+particular:</P>
+<UL>
+ <LI><P>Newer, larger, NAND with 2kB pages can be used in chunks of
+ 2kB. Keeping the relationship of one chunk per page improves
+ robustness and performance (rather than say trying to "fake"
+ 512byte pages). A block comprises 64x2kB pages.</P>
+ <LI><P>Some devices have 512byte pages, but are arranged as multiple
+ "bit planes" which can be programmed and erased in
+ parallel. For example, the Samsung K9K1G08U0M can support 4
+ simultaneous operations. YAFFS2 can exploit this by using 2kB chunks
+ by using groups of 4 pages - one on each bitplane. Virtual blocks
+ would be built which comprise 32x2kB chunks.</P>
+</UL>
+<P>To this end, yaffs_guts is being re-crafted to support arbitrary
+chunk size (power of 2, >= 1024), with arbitrary block size.</P>
+<P>Currently, YAFFS also makes some other assumptions which will need
+to be changed:</P>
+<UL>
+ <LI><P>Spare layout. Might need to be changed. This is relatively
+ simple to shuffle around.</P>
+ <LI><P>Bad block detection. Currently YAFFS uses the SmartMedia
+ detection (checks first two pages for bad block markers). Needs to
+ be more flexible. eg. Sandisk/Toshiba MLC parts mark the last two
+ pages in a block.</P>
+ <LI><P>ECC was on this list, but now seems flexible enough. Thanx
+ Thomas.</P>
+</UL>
+<P>Some of these differences can be absorbed in the yaffs_mtd layer.
+Some will need to be handles inside the mtd itself.</P>
+<P>$Id: yaffs2.html,v 1.3 2003-09-16 06:48:38 charles Exp $</P>