mtd/html/tech nand.html,1.14,1.15

[gleixner at infradead.org]

Update of /home/cvs/mtd/html/tech
In directory phoenix.infradead.org:/tmp/cvs-serv23608/mtd/html/tech

Modified Files:
	nand.html 
Log Message:
tglx declares himself healed from temporary brain damage and comes back to the original plan of passing
oob-layout structures. This implies minor changes to filesystem layers, but removes file system dependend
code in nand.c/.h. For userspace apps ioctl (MEMSETOOBSEL) can pass a structure with the layout, which 
has to be used for functions  like read/write, which have no knowledge about oob-layout. see util/nandwrite.c
 



Index: nand.html
===================================================================
RCS file: /home/cvs/mtd/html/tech/nand.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- nand.html	18 Feb 2003 20:53:55 -0000	1.14
+++ nand.html	18 Feb 2003 21:04:10 -0000	1.15
@@ -145,26 +145,16 @@
 <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>
-<li>NAND_NONE_OOB</li>
-<li>NAND_JFFS2_OOB</li>
-<li>NAND_YAFFS_OOB</li>
-</ul>
-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. 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>
+of the ECC-data inside the oob area. The parameter is a structure named nand_oobinfo. <br>
+struct nand_oobconfig {<br>
+	int 	useecc;<br>
+	int	eccpos[6];<br>
+}<br>
+With this structure the usage of ecc and the position of ecc-data in the oob area are given.
+If useecc is 0, then eccpos will be ignored, else eccpos arrey gives an index for the ecc data
+inside out of band area.
 </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>
 
 <h4>Read back OOB data together with main area </h4>
 <p>If the fs driver needs to read the oobdata together with the raw data, then the fs-driver has to
@@ -364,26 +354,8 @@
 line or NULL, if you don't have one</i><br>
 this->chip_delay = 20;<i>The delay time (us), after writing a command to the chip, 
 according to datasheet (tR)</i><br>
-yourboard_mtd->oobsel = NAND_JFFS2_OOB; <i> set the default oob-layout for your chip, if
-no partitions are used</i><br>
 SNIP<br>
 }</p>
-<p>If you use paritions, you should initialize the default oob-layout for each partition.<br>
-static struct mtd_partition partition_info16k[] = {<br>
-	{ name: "YOURBOARD flash partition 1",<br>
-	  offset:  0,<br>
-	  size:    8 * SZ_1M, <br>
-	  oobsel:  NAND_JFFS2_OOB },<br>
-	{ name: "YOURBOARD flash partition 2",<br>
-	  offset:  8 * SZ_1M,<br>
-	  size:    8 * SZ_1M,<br>
-	  oobsel:  NAND_YAFFS_OOB }<br>
-};<br>
-These settings are useful, if you write data from userspace to your chip, e.g. a filesystem image.
-The userspace functions don't know anything about NAND oob. A write would not calc ECC. If you 
-set it for your desired fs-type, ECC will be calculated and written at the appropriate place on
-your chip. Same applies for read functions.</p> 
-
 
 <h4>Hardware specific command function</h4>
 
@@ -529,6 +501,14 @@
 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>Can I use mtdutils erase / eraseall</h4>
+<p>Yes, the latest nand driver code forces the protection of bad block information. It's safe to erase a 
+NAND&nbsp;flash with erase(all) /dev/mtdX.
+It's recommended to use eraseall with -j or --jffs2 option set. This will write the cleanmarker to the 
+out of band area. So you can mount the filesystem and no further formatting is needed. This formatting
+is also neccecary before you copy a fs-image to the chip.
+</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 only be written with ECC, if your default settings for
@@ -536,12 +516,10 @@
 nandwrite -j /dev/mtdX image
 </p>
 
-<h4>Can I use mtdutils erase / eraseall</h4>
-<p>Yes, the latest nand driver code forces the protection of bad block information. It's safe to erase a 
-NAND&nbsp;flash with erase(all) /dev/mtdX.
-It's recommended to use eraseall with -j or --jffs2 option set. This will write the cleanmarker to the 
-out of band area. So you can mount the filesystem and no further formatting is needed. This formatting
-is also neccecary before you copy a fs-image to the chip.
+<h4>Can I use seek/read/write on /dev/mtdX ?</h4>
+<p>Yes, as long as your program is aware of bad blocks. Make sure to set the desired ECC layout by
+ioctl (MEMSETOOBSEL). A example for bad block handling and usage of ioctl (MEMOOBSEL) can be found in
+util/nandwrite.c
 </p>
 
 <h4>Must my bootloader be aware of NAND FLASH&nbsp;?</h4>