mtd/html/tech nand.html,1.9,1.10
gleixner at infradead.org
gleixner at infradead.org
Sun Nov 24 16:07:40 EST 2002
Update of /home/cvs/mtd/html/tech
In directory phoenix.infradead.org:/tmp/cvs-serv31766
Modified Files:
nand.html
Log Message:
tglx blames himself for not saving before commit
Index: nand.html
===================================================================
RCS file: /home/cvs/mtd/html/tech/nand.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- nand.html 24 Nov 2002 15:45:21 -0000 1.9
+++ nand.html 24 Nov 2002 21:07:36 -0000 1.10
@@ -118,21 +118,23 @@
SmartMediaCards at the moment. A JFFS2 support for DiskOnChip devices, based on the
NAND code, is planned. There are some other Open Source projects for NAND filesystem
support, but there's no other working solution than JFFS2 and YAFFS at the moment of this writing.
-YAFFS is available from <a href=http://www.aleph1.co.uk/armlinux/projects/yaffs>YAFFS-Homepage</a></p>
+YAFFS is available from <a href=http://www.aleph1.co.uk/armlinux/projects/yaffs>YAFFS-Homepage</a>.
+YAFFS is faster than JFFS2 and consumes less RAM, JFFS2 provides on the fly file compression and
+decompression, which is very helpfull for small FLASHs.</p>
<p> There is currently no support for the wide spread SmartMedia DOS-FAT filesystem,
mainly because it's not a reliable filesystem for industrial usage. It's ok for
multimedia applications. The hardware support layer is designed to support an
implementation of SmartMedia DOS-FAT, but nobody has made an attempt to implement
it really. There are a couple of SmartMedia Card adaptors for USB, PCMCIA, FireWire
... with Linux drivers available, which support the SmartMedia DOS-FAT. </p>
-<p>JFFS2 includes bad block management, wear leveling, error correction and provides
-a reliable filesystem on top of NAND Flash.</p>
+<p>JFFS2 and YAFFS include bad block management, wear leveling, error correction and provide
+reliable filesystems on top of NAND Flash.</p>
<h2>Multiple filesystems on different partitions</h2>
-<p>This is technical information for filesystem implementation</p>
-<p>The generic NAND driver allows you to mount different filesystems on different partitions
-of the same chip. As the OOB usage of the filesystem differs, the OOB usage can be
-selected on runtime from the filesystem driver. The parameter is given in the functions
+You can mount different filesystems on different partitions of the same chip.
+<h3>Technical information for filesystem implementation</h3>
+<p>As the OOB usage of the filesystems differs, the OOB usage can be
+selected on runtime from the filesystem driver. The parameter is given to the functions
mtd->read_ecc and mtd->write_ecc. This parameter specifies the location
of the ECC-data inside the oob area. Currently there are three values supported:
<ul>
@@ -143,16 +145,40 @@
NAND_NONE_OOB disables the ECC-calculation of the NAND driver and writes either nothing or an
OOB buffer, which is supplied by the filesystem driver, to the oob area of the chip. This can
be useful, if the filesystem driver does the ECC calculation self or the ECC is not used by
-the driver. <br>
-NAND_JFFS2_OOB calculates the ECC with the function, which is selected for the chip and places
-the results in the defined locations for JFFS2. <br>
-NAND_YAFFS_OOB calculates the ECC with the function, which is selected for the chip and places
-the results in the defined locations for YAFFS. <br>
+the driver. On read the ecc calculation and error correction is skipped.<br>
+NAND_JFFS2_OOB calculates the ECC with the function, which is selected for the chip. write_ecc places
+the results in the defined locations for JFFS2. read_ecc uses the ECC from the defined locations
+for error checking and correction.<br>
+NAND_YAFFS_OOB calculates the ECC with the function, which is selected for the chip. write_ecc places
+the results in the defined locations for JFFS2. read_ecc uses the ECC from the defined locations
+for error checking and correction.<br>
</p>
<p>All non ecc functions like mtd->read and mtd->write default to NAND_NONE_OOB.</p>
<p>To add a yet unsupported filesystem, the oobconfig array has to be extended and a new selection
constant has to be defined.</p>
+<p>If the fs driver needs to read the oobdata together with the raw data, then the fs-driver has to
+supply a big enough buffer. <br>
+size = 12 bytes * number of pages to read (256B pagesize) or 24 bytes* number of pages to read (512B pagesize) <br>
+The buffer contains 8/16 byte oobdata and 4/8 byte returncode from correct_ecc <br>
+oobbuf [0-15] oob-data 1st read page <br>
+oobbuf [16-19] return code from correct_ecc byte 0-255 <br>
+oobbuf [20-23] return code from correct_ecc byte 256-511 <br>
+oobbuf [24-39] oob-data 2nd read page <br>
+oobbuf [40-31] return code from correct_ecc byte 0-255 <br>
+..... <br>
+The returnvalue of read_ecc is -EIO, if any correct_ecc returned -1. But
+retlen is equal to the requested length, so fs-driver can decide what to do. <br>
+
+Oob data can be given from filesystem to program them in one go together
+with the raw data. ECC codes are filled in at the place selected by oobsel.
+This supports multipage programming. <br>
+oobbuf[0-15] 1st page to write <br>
+oobbuf[16-31] 2nd page to write <br>
+..... <br>
+ECC is filled in at the appropriate place selected by the above mentioned constants.
+</p>
+
<h2>JFFS2 specific information <h2>
<h3>JFFS2 Out of Band usage</h3>
@@ -255,7 +281,7 @@
driver provides all functions, which are neccecary to identify, read, write
and erase NAND Flash. The hardware dependend functions are provided by
the hardware driver. They provide mainly the hardware access informations and
-functions for the generic NAND driver.</p>
+functions for the generic NAND driver. For YAFFS applies the same.</p>
<h3>Hardware driver</h3>
<p>To implement it on your hardware, you will have to write a new hardware driver.
@@ -474,13 +500,6 @@
JFFS2 has a timed flush of the write buffer, which forces the flush of the buffer to flash, if there are no
writes to the filesystem for more than 2 seconds. When you unmount the filesystem the buffer is flushed too.</p>
-<h4>I have problems to mount partitions larger than 46MB</h4>
-<p>The reason is, that the requested memorysize for the block-structures is greater than 128K for big partitions,
-due to the usual 16kB size of an eraseblock on NAND. We will reduce the structuresize and incorporate virtual
-64KB eraseblocks, which consist of 4 physical FLASH blocks. Until this is done and tested, you can change the
-allocation of the block-structure memory in jffs2_do_mount_fs() from kmalloc to vmalloc. Don't forget to change
-lso kfree to vfree in jffs2_put_super().</p>
-
<h4>Can I copy a JFFS2 Image to NAND via /dev/mtdX ?</h4>
<p>Yes, as long as your chip does not contain bad blocks. Make sure, that the erasesize you set to mkfs.jffs2
is the same as the erasesize of your chip. Data will not be written with ECC, which means, that you can get a lot
@@ -523,7 +542,8 @@
<h2>References:</h2>
<h3>Open Source</h3>
-<p>JFFS2 and NTFL are located on this <a href=http://www.linux-mtd.infradead.org> website</a></p>
+<p>JFFS2 and NTFL are located on this <a href=http://www.linux-mtd.infradead.org> website</a>.<br>
+YAFFS is located at <a href=http://www.aleph1.co.uk/armlinux/projects/yaffs>YAFFS-Homepage</a>.</p>
<h3>Hardware</h3>
<p><a href=http://www.toshiba.com/taec/>Toshiba</a></p>
<p><a href=http://samsungelectronics.com/>Samsung</a></p>
More information about the linux-mtd-cvs
mailing list