mtd/html/tech faq.html,1.3,1.4

[gleixner at infradead.org]

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

Modified Files:
	faq.html 
Log Message:
Move JFFS2 NAND section. Add some info about image programming

Index: faq.html
===================================================================
RCS file: /home/cvs/mtd/html/tech/faq.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- faq.html	18 Feb 2005 15:20:18 -0000	1.3
+++ faq.html	26 Feb 2005 20:37:18 -0000	1.4
@@ -59,20 +59,6 @@
 driver. The JFFS2 code, which handles the writebuffer and the out of band (spare) area of NAND doesn't support
 32 bit neither.</p>
 
-<h4>How is ensured, that data is written to flash ?</h4>
-<p>As we have to handle a writebuffer for writing only full pages to the chips, there could be a loss of data, 
-when the writebuffer is not flushed before power down. There are some mechanisms to ensure, that the writebuffer 
-is flushed. You can force the flush of the writebuffer by using fsync() or sync() in your application. 
-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 about 5 seconds. The time depends on the cycletime of kupdated, which 
-can be adjusted via <b>/proc/sys/vm/dirty_expire_centisecs</b>. <br>
-When you unmount the filesystem the buffer is flushed too.</p>
-<p>If the partition is being used as a root filesystem, which obviously cannot be dismounted, the filesystem
-should be remounted read only on shutdown. In the case of JFFS2 this will cause the garbage collector to flush
-its write buffers. Failure to do this may cause the filesystem to generate warnings regarding bad CRC.
-These are partially collected garbage blocks which will be rescheduled for garbage collection some time later.
-This kind of behaviour may also be observed after a system crash.</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.
@@ -101,8 +87,8 @@
  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 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>
+<p>For JFFS2 filesystems it's recommended to programm the JFFS2 erased marker into the out of band area of the 
+first page in each erased block after erasing the block. Do not program it into the data area of the page !</p>
 
 <p>For 256 byte pagesize devices program the following data into the out of band area:</p>
 		
@@ -122,9 +108,12 @@
 		
 <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 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>
+block and copy the data to the next block. JFFS2 and other NAND flash aware filesystems handle this gap.</p>
+
+<h4>Can I program NAND via JTAG&nbsp;?</h4>
+<p>Yes, you can. The requirements are the same as for bootloaders</p>
 
-<h2>JFFS2 specifc</h2>
+<h2>JFFS2 specific</h2>
 
 <h4>JFFS2 generates messages, is there a problem ?</h4>
 <p>JFFS2 adopts the philosophy of keeping the user completely appraised of what is going on. This can
@@ -150,6 +139,34 @@
 If you are desperate, then fix jffs2_dump to recreate the filesystem from the image. It's not hard. All the
 basics are done already.</p>
 
+<h4>How is ensured, that data is written to flash ?</h4>
+<p>On <b>NOR FLASH</b> each write goes directly into the FLASH</p>
+<p>On <b>NAND FLASH and NOR ECC FLASH</b> we have a writebuffer for writing only full pages to the chips. 
+There could be a loss of data, when the writebuffer is not flushed before power down. There are some 
+mechanisms to ensure, that the writebuffer is flushed. You can force the flush of the writebuffer by 
+using fsync() or sync() in your application. 
+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 about 5 seconds. The time depends on the cycletime of kupdated, which 
+can be adjusted via <b>/proc/sys/vm/dirty_expire_centisecs</b>. <br>
+When you unmount the filesystem the buffer is flushed too.</p>
+<p>If the partition is being used as a root filesystem, which obviously cannot be dismounted, the filesystem
+should be remounted read only on shutdown. In the case of JFFS2 this will cause the garbage collector to flush
+its write buffers. Failure to do this may cause the filesystem to generate warnings regarding bad CRC.
+These are partially collected garbage blocks which will be rescheduled for garbage collection some time later.
+This kind of behaviour may also be observed after a system crash.</p>
+
+<h4>Howto program an image to FLASH</h4>
+<p>There are several possibilities to do so</p>
+<ul>
+<li>From Linux
+<li>From bootloader
+<li>Via JTAG
+<li>At production time
+</ul>
+<p>
+For <b>NOR FLASH</b> there are no restrictions. For <b>NAND FLASH</b> please read the NAND FAQ section.</p>
+</p>
+
 <hr>
 <a href="../index.html">Back to MTD Homepage</a>.</p>
 <hr>