X-Git-Url: http://aleph1.co.uk/gitweb/?a=blobdiff_plain;f=Documentation%2Fyaffs2.html;h=9014465ba399097aa8fa7a64ff0a9899e63e64bd;hb=c668bb26fb948b3dba6a6000ac2334d833e67a80;hp=e83dcc667d8474087320b10245b8e2e97bc082f0;hpb=ce96b5b9742c81cad6d902eaf793b792c1b8943b;p=yaffs%2F.git diff --git a/Documentation/yaffs2.html b/Documentation/yaffs2.html index e83dcc6..9014465 100644 --- a/Documentation/yaffs2.html +++ b/Documentation/yaffs2.html @@ -7,7 +7,7 @@ - +

YAFFS2

@@ -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.

Performance

These numbers are indicative of relative performance. These only +

These numbers are indicative of relative performance. These only apply to the NAND data transfer and do not include other overheads.

As an example, read/write cycle times of 100nS are used (though NAND can typically do 50nS), "seek time" of 10uS and @@ -747,7 +747,41 @@ transfer time relative to an 8-bit bus.

$Id: yaffs2.html,v 1.1 2002-11-26 01:15:37 charles Exp $

MTD Interface

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:

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.
+
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.
+

To this end, yaffs_guts is being re-crafted to support arbitrary +chunk size (power of 2, >= 1024), with arbitrary block size.

Currently, YAFFS also makes some other assumptions which will need +to be changed:

Spare layout. Might need to be changed. This is relatively + simple to shuffle around.
+
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.
+
ECC was on this list, but now seems flexible enough. Thanx + Thomas.
+

Some of these differences can be absorbed in the yaffs_mtd layer. +Some will need to be handles inside the mtd itself.

$Id: yaffs2.html,v 1.2 2003-01-14 23:15:41 charles Exp $