mtd/html/tech nand.html,1.7,1.8

[gleixner at infradead.org]

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

Modified Files:
	nand.html 
Log Message:
some updates

Index: nand.html
===================================================================
RCS file: /home/cvs/mtd/html/tech/nand.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- nand.html	29 Aug 2002 21:55:28 -0000	1.7
+++ nand.html	13 Nov 2002 19:42:41 -0000	1.8
@@ -122,7 +122,7 @@
 available in a beta version.</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 a 
+ 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>
@@ -139,8 +139,8 @@
 <tr><td>0x01</td><td>ECC byte 1</td><td>Error correction code byte 1</td></tr>
 <tr><td>0x02</td><td>ECC byte 2</td><td>Error correction code byte 2</td></tr>
 <tr><td>0x03</td><td>reserved</td><td>reserved</td></tr>
-<tr><td>0x04</td><td>ECC valid marker</td><td>If one of the lower 4 bits in 
-this byte is zero, it indicates that this page was written with ECC</td></tr>
+<tr><td>0x04</td><td>reserved</td><td>reserved, was ECC valid marker, which is now
+obsolete</td></tr>
 <tr><td>0x05</td><td>Bad block marker</td><td>If any bit in this byte is zero, 
 then this block is bad. This applies only to the first page in a block. 
 In the remaining pages this byte is reserved</td></tr>
@@ -166,10 +166,8 @@
 lower 256 Bytes of data in this page</td></tr>
 <tr><td>0x03</td><td>ECC byte 3</td><td>Error correction code byte 0 of the 
 upper 256 Bytes of data in this page</td></tr>
-<tr><td>0x04</td><td>ECC valid marker</td><td>If one of the lower 4 bits 
-in this byte is zero, it indicates that the lower 256 byte data in this page 
-were written with ECC. If one of the upper 4 bits in this byte is zero, it 
-indicates that the upper 256 byte data in this page were written with ECC.</td></tr>
+<tr><td>0x04</td><td>reserved</td><td>reserved, was ECC valid marker, which is now
+obsolete</td></tr>
 <tr><td>0x05</td><td>Bad block marker</td><td>If any bit in this byte is zero, 
 then this block is bad. This applies only to the first page in a block. In the 
 remaining pages this byte is reserved</td></tr>
@@ -228,10 +226,10 @@
 <li>Hardware specific driver </li>
 </ol>
 <p>the MTD driver just provides a mount point for JFFS2. The generic NAND 
-driver providesall functions, which are neccecary to identify, read, write 
+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 genering NAND driver.</p>
+functions for the generic NAND driver.</p>
 
 <h3>Hardware driver</h3>
 <p>To implement it on your hardware, you will have to write a new hardware driver. 
@@ -450,10 +448,17 @@
 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. If  your kernel is set for JFFS2 on NAND and ECC is enabled, the 
-data will be written with ECC. </p>
+is the same as the erasesize of your chip. Data will not be written with ECC, which means, that you can get a lot 
+of warnings, when you mount the filesystem.</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 
@@ -464,7 +469,7 @@
 For erase make sure, that you don't erase factory-marked bad blocks. They are marked in the 6th
  byte (offset 0x5) in the out of band area of the first page of a block. The block is bad, if any bit in 
  this byte is zero. If you erase such a block, the bad block information is erased too and lost. Further 
- use of this block will lead to erronous results</p>
+ use of this block will lead to erroneous results</p>
 <p>After the erase it's recommended to programm the JFFS2 erased marker into the out of band area of the 
 first page in each erased block. Do not program it into the data area of the page !</p>
 
@@ -485,10 +490,8 @@
 </table>
 		
 <p>If you copy a filesystem image to the chip, it's recommended to write it with ECC. You can use 
-the ECC code in the nand driver to do this. If you don't use ECC the nand driver will detect this, 
-as long as you leave the eccvalid byte (offset 0x04) in the out of band area in the erased state (0xff).
- If you have a bad block on your chip, just skip this block and copy the data to the next block. 
- JFFS2 is able to handle this gap.</p>
+the ECC code in the nand driver to do this.  If you have a bad block on your chip, just skip this 
+block and copy the data to the next block. JFFS2 is able to handle this gap.</p>
 		
 <hr>