projects / yaffs / .git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
*** empty log message ***
[yaffs/.git] / Documentation / yaffs2.html
diff --git a/Documentation/yaffs2.html b/Documentation/yaffs2.html
index e83dcc667d8474087320b10245b8e2e97bc082f0..9014465ba399097aa8fa7a64ff0a9899e63e64bd 100644 (file)
--- a/Documentation/yaffs2.html
+++ b/Documentation/yaffs2.html
@@ -7,7 +7,7 @@
        <META NAME="AUTHOR" CONTENT=" ">
        <META NAME="CREATED" CONTENT="20021004;15061000">
        <META NAME="CHANGEDBY" CONTENT=" ">
-       <META NAME="CHANGED" CONTENT="20021126;13574600">
+       <META NAME="CHANGED" CONTENT="20021206;6000500">
 </HEAD>
 <BODY>
 <H1>YAFFS2</H1>
@@ -224,7 +224,7 @@ sequence Id order) rather than in their order on the media. This
 implies that at start up, the blocks must be read and their block
 sequence determined.</P>
 <H4>Performance</H4>
-<P>These  numbers are indicative of relative performance. These only
+<P>These numbers are indicative of relative performance. These only
 apply to the NAND data transfer and do not include other overheads.</P>
 <P>As an example, read/write cycle times of 100nS are used (though
 NAND can typically do 50nS), &quot;seek time&quot; of 10uS and
@@ -747,7 +747,41 @@ transfer time relative to an 8-bit bus.</P>
 </TABLE>
 <P><BR><BR>
 </P>
-<P>$Id: yaffs2.html,v 1.1 2002-11-26 01:15:37 charles Exp $</P>
+<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 &quot;fake&quot;
+       512byte  pages). A block comprises 64x2kB pages.</P>
+       <LI><P>Some devices have 512byte pages, but are arranged as multiple
+       &quot;bit planes&quot; 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, &gt;= 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.2 2003-01-14 23:15:41 charles Exp $</P>
 <P><BR><BR>
 </P>
 <P><BR><BR>
YAFFS1, Archived repository.