1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
4 <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
6 <META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Linux)">
7 <META NAME="AUTHOR" CONTENT=" ">
8 <META NAME="CREATED" CONTENT="20021004;15061000">
9 <META NAME="CHANGEDBY" CONTENT=" ">
10 <META NAME="CHANGED" CONTENT="20030906;14584300">
15 <P>The original motivation for YAFFS 2 was to add support for the new
16 NAND with 2kB pages instead of 512-byte pages and strictly sequential
19 <P>To achieve this, a new design is used which also realises the
20 following benefits:</P>
22 <LI><P>zero page rewrites, which means faster operation. (YAFFS1
23 uses a single rewrite in the spare area to delete a page).</P>
24 <LI><P>ability to exploit simultaneous page programming on some
26 <LI><P>improves performance relative to YAFFS1 speed(write:1.5x to
27 5x, delete: 4x, garbage collection: 2x)</P>
28 <LI><P>lower RAM footprint (approx. 25% to 50% of YAFFS1, depending
29 on chunk size used).</P>
30 <LI><P>Can support Toshiba/Sandisk MLC parts.</P>
31 <LI><P>Runtime selection between various chunk sizes.</P>
33 <P>Most of YAFFS and YAFFS2 code is common, therefore the code will
34 likely be kept common with YAFFS vs YAFFS2 being run-time selected.</P>
36 <P>The main philosophical difference between YAFFS and YAFFS2 is how
37 discarded status is tracked. Since we can't do any re-writing, we
38 can't use the "discarded" flags in YAFFS2.</P>
39 <P>Instead YAFFS2 uses two mechanisms to resolve data state.</P>
41 <LI><P>YAFFS2 chunks have more tag information, including a block
42 sequence Id. From that we can determine the chunk sequence Id since
43 the chunks are allocated sequentially in a block. Thus we always
44 know the patch order for all chunks in the system.</P>
45 <LI><P>The above helps us track stale -vs- fresh data, but does not
46 help determine when a file/object is deleted. Deletion is achieved
47 by moving the object to the "unlinked" directory. We also
48 keep track of the number of chunks (both stale and current) in the
49 system for each object. While this number indicates that there are
50 still chunks associated with this object we keep the deletion
51 record. When the last trace of the object has been really erased
52 from NAND, we can forget about the deletion record too.
54 <LI><P>Since there is no deletion, a resize (shrinking) of a file
55 will still have valid data chunks past the end of file on the NAND.
56 However, we write a new ObjectHeader at the time of the resize,
57 therefore this shows the shrunken file size. The ObjectHeader also
58 carries information to say that this is a shrink, for some special
59 handling in the garbage collector.</P>
63 <P>This changes erasure slightly:</P>
65 <LI><P>During garbage collection we can't just look at chunk state
66 flags, instead we must read the tags of each chunk to determine
67 which object's chunk count we must decrement. This step must also be
68 performed when a block is erased (as part of deletion). This is
69 already done in YAFFS by<I> soft deletion.</I></P>
71 <P>This makes erasure & garbage collection more expensive (by
72 adding reads), but remember that ion YAFFS2 we don't need to do page
73 deletions which are much more expensive operations. Thus, all-up
75 <H4>Resize Handling</H4>
76 <P>In YAFFS, soft deletion is ued for everything but resizing
77 (shrinking) a file which has some particularly ugly cases that can
78 complicate garbage collection.</P>
79 <P>As mentioned before, we write a new ObjectHeader to indicate the
80 shrinking. However, it is important that this ObjectHeader does not
81 get destroyed (erased) before the data chunks that were discarded
82 during the shrink are destroyed (erased). If this precaution is not
83 taken then it is possible that the deleted chunks might be brought
85 <P>The modification to the garbage collector is as follows:</P>
87 <LI><P>The block info flags are expanded as follows:</P>
88 <LI><P>containsShrinkObjectHeader: Indicates that one or more of the
89 chunks in the block are object headers to indicate a file shrink.</P>
90 <LI><P>containsShrinkDataChunks: Indicates that one or more of the
91 chunks in the block are data chunks discarded by a file shrink.</P>
94 <LI><P>Before we allow a block with containsShrinkObjectHeader set
95 to be erased (garbage collected), we must first ensure that all the
96 earlier blocks (ie according to the block sequence number) that have
97 containsShrinkDataChunks set are erased (garbage collected) which
98 ensures that the shrunk data chunks are deleted. The mechanisms to
99 do this are as follows:</P>
100 <LI><P>If the garbage collector attempts to select a block with
101 containsShrinkObjectHeader set, we check that the above criterion in
102 met before selecting the block.</P>
103 <LI><P>Periodically select the oldest block with
104 containsShrinkDataChunks for garbage collection.</P>
110 <H4>Tag structure</H4>
111 <P>Each chunk in YAFFS2 has the following information:</P>
112 <TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=3>
126 <P>Size for 1kb chunks</P>
129 <P>Size for 2kB chunks</P>
139 <P>Block state. non-0xFF for bad block</P>
153 <P>32-bit chunk Id</P>
167 <P>32-bit object Id</P>
181 <P>Number of data bytes in this chunk</P>
195 <P>sequence number for this block</P>
209 <P>ECC on tags area</P>
223 <P>ECC, 3 bytes/256 bytes of data</P>
241 <P ALIGN=LEFT><B>30 bytes</B></P>
244 <P><B>42 bytes</B></P>
251 <P>To get enough spare bytes for this tagging structure requires a
252 chunk-size of at least 1kB. YAFFS1 is still used for 512-byte chunk
254 <P>The blockSequence increments each time a block is allocated. (ie.
255 the first block allocated is block 1, and so on).</P>
257 <P>The only reason we need to keep track of data status on NAND is to
258 be able to recreate the file system state during scanning. Since we
259 no longer have chunk deletion status flags we use a slightly
260 different process for scanning a YAFFS2 system.</P>
261 <P>In effect, YAFFS2 recreates its state by "replaying the
262 tape". ie. it scans the chunks in their allocation order (block
263 sequence Id order) rather than in their order on the media. This
264 implies that at start up, the blocks must be read and their block
265 sequence determined.</P>
267 <P>These numbers are indicative of relative performance. These only
268 apply to the NAND data transfer and do not include other overheads.</P>
269 <P>As an example, read/write cycle times of 100nS are used (though
270 NAND can typically do 50nS), "seek time" of 10uS and
271 program time of 200uS. Mileage will vary.</P>
272 <P>NB x16 means using a 16-bit bus. Clearly this cuts down on data
273 transfer time relative to an 8-bit bus.</P>
274 <P>Times for 2kB read(units of 1uS).</P>
275 <TABLE WIDTH=937 BORDER=1 CELLPADDING=4 CELLSPACING=3>
290 <P>YAFFS2 (512b pages)</P>
293 <P>YAFFS2 (2kB pages)</P>
296 <P>YAFFS2(2kB pages, x16)</P>
302 <TD WIDTH=175 VALIGN=TOP>
306 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="40" SDNUM="5129;">
307 <P ALIGN=RIGHT>40</P>
309 <TD WIDTH=177 VALIGN=BOTTOM SDVAL="40" SDNUM="5129;">
310 <P ALIGN=RIGHT>40</P>
312 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="10" SDNUM="5129;">
313 <P ALIGN=RIGHT>10</P>
315 <TD WIDTH=173 VALIGN=BOTTOM SDVAL="10" SDNUM="5129;">
316 <P ALIGN=RIGHT>10</P>
320 <TD WIDTH=175 VALIGN=TOP>
323 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="220" SDNUM="5129;">
324 <P ALIGN=RIGHT>220</P>
326 <TD WIDTH=177 VALIGN=BOTTOM SDVAL="220" SDNUM="5129;">
327 <P ALIGN=RIGHT>220</P>
329 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="220" SDNUM="5129;">
330 <P ALIGN=RIGHT>220</P>
332 <TD WIDTH=173 VALIGN=BOTTOM SDVAL="110" SDNUM="5129;">
333 <P ALIGN=RIGHT>110</P>
337 <TD WIDTH=175 VALIGN=TOP>
340 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="260" SDNUM="5129;">
341 <P ALIGN=RIGHT>260</P>
343 <TD WIDTH=177 VALIGN=BOTTOM SDVAL="260" SDNUM="5129;">
344 <P ALIGN=RIGHT>260</P>
346 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="230" SDNUM="5129;">
347 <P ALIGN=RIGHT>230</P>
349 <TD WIDTH=173 VALIGN=BOTTOM SDVAL="120" SDNUM="5129;">
350 <P ALIGN=RIGHT>120</P>
354 <TD WIDTH=175 VALIGN=TOP>
357 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="7.6" SDNUM="5129;">
358 <P ALIGN=RIGHT>7.6</P>
360 <TD WIDTH=177 VALIGN=BOTTOM SDVAL="7.6" SDNUM="5129;">
361 <P ALIGN=RIGHT>7.6</P>
363 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="8.7" SDNUM="5129;">
364 <P ALIGN=RIGHT>8.7</P>
366 <TD WIDTH=173 VALIGN=BOTTOM SDVAL="16.7" SDNUM="5129;">
367 <P ALIGN=RIGHT>16.7</P>
371 <TD WIDTH=175 VALIGN=TOP>
372 <P>Relative speed</P>
374 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="1" SDNUM="5129;">
377 <TD WIDTH=177 VALIGN=BOTTOM SDVAL="1" SDNUM="5129;">
380 <TD WIDTH=176 VALIGN=BOTTOM SDVAL="1.1" SDNUM="5129;">
381 <P ALIGN=RIGHT>1.1</P>
383 <TD WIDTH=173 VALIGN=BOTTOM SDVAL="2.2" SDNUM="5129;">
384 <P ALIGN=RIGHT>2.2</P>
391 <P>Times for 2kB writes(units of 1uS).</P>
392 <TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=3>
407 <P>YAFFS2 (512b pages)</P>
410 <P>YAFFS2 (2kB pages)</P>
413 <P>YAFFS2(2kB pages, x16)</P>
419 <TD WIDTH=20% VALIGN=TOP>
422 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="40" SDNUM="5129;">
423 <P ALIGN=RIGHT>40</P>
425 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="40" SDNUM="5129;">
426 <P ALIGN=RIGHT>40</P>
428 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="10" SDNUM="5129;">
429 <P ALIGN=RIGHT>10</P>
431 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="10" SDNUM="5129;">
432 <P ALIGN=RIGHT>10</P>
436 <TD WIDTH=20% VALIGN=TOP>
439 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="800" SDNUM="5129;">
440 <P ALIGN=RIGHT>800</P>
442 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="800" SDNUM="5129;">
443 <P ALIGN=RIGHT>800</P>
445 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="200" SDNUM="5129;">
446 <P ALIGN=RIGHT>200</P>
448 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="200" SDNUM="5129;">
449 <P ALIGN=RIGHT>200</P>
453 <TD WIDTH=20% VALIGN=TOP>
456 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="40" SDNUM="5129;">
457 <P ALIGN=RIGHT>40</P>
459 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="40" SDNUM="5129;">
460 <P ALIGN=RIGHT>40</P>
462 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="10" SDNUM="5129;">
463 <P ALIGN=RIGHT>10</P>
465 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="10" SDNUM="5129;">
466 <P ALIGN=RIGHT>10</P>
470 <TD WIDTH=20% VALIGN=TOP>
473 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="220" SDNUM="5129;">
474 <P ALIGN=RIGHT>220</P>
476 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="220" SDNUM="5129;">
477 <P ALIGN=RIGHT>220</P>
479 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="220" SDNUM="5129;">
480 <P ALIGN=RIGHT>220</P>
482 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="110" SDNUM="5129;">
483 <P ALIGN=RIGHT>110</P>
487 <TD WIDTH=20% VALIGN=TOP>
490 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1320" SDNUM="5129;">
491 <P ALIGN=RIGHT>1320</P>
493 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1320" SDNUM="5129;">
494 <P ALIGN=RIGHT>1320</P>
496 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="660" SDNUM="5129;">
497 <P ALIGN=RIGHT>660</P>
499 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="440" SDNUM="5129;">
500 <P ALIGN=RIGHT>440</P>
504 <TD WIDTH=20% VALIGN=TOP>
507 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1.5" SDNUM="5129;">
508 <P ALIGN=RIGHT>1.5</P>
510 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1.5" SDNUM="5129;">
511 <P ALIGN=RIGHT>1.5</P>
513 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="3" SDNUM="5129;">
516 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="4.5" SDNUM="5129;">
517 <P ALIGN=RIGHT>4.5</P>
521 <TD WIDTH=20% VALIGN=TOP>
522 <P>Relative speed</P>
524 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1" SDNUM="5129;">
527 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1" SDNUM="5129;">
530 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="2" SDNUM="5129;">
533 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="3" SDNUM="5129;">
541 <P>Times for 1MB delete (units of 1uS).</P>
542 <TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=3>
557 <P>YAFFS2 (512b pages)</P>
560 <P>YAFFS2 (2kB pages)</P>
563 <P>YAFFS2(2kB pages, x16)</P>
569 <TD WIDTH=20% VALIGN=TOP>
572 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="20480" SDNUM="5129;">
573 <P ALIGN=RIGHT>20480</P>
575 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="0" SDNUM="5129;">
578 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="0" SDNUM="5129;">
581 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="0" SDNUM="5129;">
586 <TD WIDTH=20% VALIGN=TOP>
589 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="409600" SDNUM="5129;">
590 <P ALIGN=RIGHT>409600</P>
592 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="0" SDNUM="5129;">
595 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="0" SDNUM="5129;">
598 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="0" SDNUM="5129;">
603 <TD WIDTH=20% VALIGN=TOP>
606 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="128000" SDNUM="5129;">
607 <P ALIGN=RIGHT>128000</P>
609 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="128000" SDNUM="5129;">
610 <P ALIGN=RIGHT>128000</P>
612 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="16000" SDNUM="5129;">
613 <P ALIGN=RIGHT>16000</P>
615 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="16000" SDNUM="5129;">
616 <P ALIGN=RIGHT>16000</P>
620 <TD WIDTH=20% VALIGN=TOP>
623 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="558080" SDNUM="5129;">
624 <P ALIGN=RIGHT>558080</P>
626 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="128000" SDNUM="5129;">
627 <P ALIGN=RIGHT>128000</P>
629 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="16000" SDNUM="5129;">
630 <P ALIGN=RIGHT>16000</P>
632 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="16000" SDNUM="5129;">
633 <P ALIGN=RIGHT>16000</P>
637 <TD WIDTH=20% VALIGN=TOP>
640 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1.8" SDNUM="5129;">
641 <P ALIGN=RIGHT>1.8</P>
643 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="7.8" SDNUM="5129;">
644 <P ALIGN=RIGHT>7.8</P>
646 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="62.5" SDNUM="5129;">
647 <P ALIGN=RIGHT>62.5</P>
649 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="62.5" SDNUM="5129;">
650 <P ALIGN=RIGHT>62.5</P>
654 <TD WIDTH=20% VALIGN=TOP>
655 <P>Relative speed</P>
657 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1" SDNUM="5129;">
660 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="4" SDNUM="5129;">
663 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="34" SDNUM="5129;">
664 <P ALIGN=RIGHT>34</P>
666 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="34" SDNUM="5129;">
667 <P ALIGN=RIGHT>34</P>
674 <P>Times for 1MB of garbage collection at 50% dirty (units of 1uS).</P>
675 <TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=3>
690 <P>YAFFS2 (512b pages)</P>
693 <P>YAFFS2 (2kB pages)</P>
696 <P>YAFFS2(2kB pages, x16)</P>
702 <TD WIDTH=20% VALIGN=TOP>
705 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="558080" SDNUM="5129;">
706 <P ALIGN=RIGHT>558080</P>
708 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="128000" SDNUM="5129;">
709 <P ALIGN=RIGHT>128000</P>
711 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="16000" SDNUM="5129;">
712 <P ALIGN=RIGHT>16000</P>
714 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="16000" SDNUM="5129;">
715 <P ALIGN=RIGHT>16000</P>
719 <TD WIDTH=20% VALIGN=TOP>
722 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="337920" SDNUM="5129;">
723 <P ALIGN=RIGHT>337920</P>
725 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="337920" SDNUM="5129;">
726 <P ALIGN=RIGHT>337920</P>
728 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="168960" SDNUM="5129;">
729 <P ALIGN=RIGHT>168960</P>
731 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="112640" SDNUM="5129;">
732 <P ALIGN=RIGHT>112640</P>
736 <TD WIDTH=20% VALIGN=TOP>
739 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="896000" SDNUM="5129;">
740 <P ALIGN=RIGHT>896000</P>
742 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="465920" SDNUM="5129;">
743 <P ALIGN=RIGHT>465920</P>
745 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="184960" SDNUM="5129;">
746 <P ALIGN=RIGHT>184960</P>
748 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="128640" SDNUM="5129;">
749 <P ALIGN=RIGHT>128640</P>
753 <TD WIDTH=20% VALIGN=TOP>
756 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1.1" SDNUM="5129;">
757 <P ALIGN=RIGHT>1.1</P>
759 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="2.1" SDNUM="5129;">
760 <P ALIGN=RIGHT>2.1</P>
762 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="5.4" SDNUM="5129;">
763 <P ALIGN=RIGHT>5.4</P>
765 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="7.7" SDNUM="5129;">
766 <P ALIGN=RIGHT>7.7</P>
770 <TD WIDTH=20% VALIGN=TOP>
771 <P>Relative speed</P>
773 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1" SDNUM="5129;">
776 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="1.9" SDNUM="5129;">
777 <P ALIGN=RIGHT>1.9</P>
779 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="4.9" SDNUM="5129;">
780 <P ALIGN=RIGHT>4.9</P>
782 <TD WIDTH=20% VALIGN=BOTTOM SDVAL="7" SDNUM="5129;">
790 <H2>MTD Interface</H2>
791 <P>As mentioned before, YAFFS2 requires a chunk-size of at least 1kB
792 to get a large enough spare area to support the increased size of the
793 tags. This is not really a disadvantage, but should rather be viewed
794 as an opportunity to exploit the NAND hardware more effectively. In
797 <LI><P>Newer, larger, NAND with 2kB pages can be used in chunks of
798 2kB. Keeping the relationship of one chunk per page improves
799 robustness and performance (rather than say trying to "fake"
800 512byte pages). A block comprises 64x2kB pages.</P>
801 <LI><P>Some devices have 512byte pages, but are arranged as multiple
802 "bit planes" which can be programmed and erased in
803 parallel. For example, the Samsung K9K1G08U0M can support 4
804 simultaneous operations. YAFFS2 can exploit this by using 2kB chunks
805 by using groups of 4 pages - one on each bitplane. Virtual blocks
806 would be built which comprise 32x2kB chunks.</P>
808 <P>To this end, yaffs_guts is being re-crafted to support arbitrary
809 chunk size (power of 2, >= 1024), with arbitrary block size.</P>
810 <P>Currently, YAFFS also makes some other assumptions which will need
813 <LI><P>Spare layout. Might need to be changed. This is relatively
814 simple to shuffle around.</P>
815 <LI><P>Bad block detection. Currently YAFFS uses the SmartMedia
816 detection (checks first two pages for bad block markers). Needs to
817 be more flexible. eg. Sandisk/Toshiba MLC parts mark the last two
818 pages in a block.</P>
819 <LI><P>ECC was on this list, but now seems flexible enough. Thanx
822 <P>Some of these differences can be absorbed in the yaffs_mtd layer.
823 Some will need to be handles inside the mtd itself.</P>
824 <P>$Id: yaffs2.html,v 1.3 2003-09-16 06:48:38 charles Exp $</P>