mtd/html/tech nand.html,1.17,1.18

gleixner at infradead.org gleixner at infradead.org
Thu May 6 05:09:29 EDT 2004


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

Modified Files:
	nand.html 
Log Message:
update to match current code better

Index: nand.html
===================================================================
RCS file: /home/cvs/mtd/html/tech/nand.html,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- nand.html	14 Apr 2003 06:58:04 -0000	1.17
+++ nand.html	6 May 2004 09:09:27 -0000	1.18
@@ -12,6 +12,7 @@
 </head>
 
 <body >
+<img src="../images/mtdlogo.png">
 <h1>NAND FLASH</h1>
 <h2>NAND vs. NOR</h2>
 <p>Beside the different silicon cell design, the most important difference between 
@@ -69,17 +70,19 @@
 		
 <h2>NAND technical view</h2>
 <p>The memory is arranged as a array of pages. A page consists of 256 / 512 Byte data 
-and 8 / 16 Byte spare (out of band) area. The spare area is used to store ECC 
-(error correction code), bad block information and filesystem dependend data.
+and 8 / 16 Byte spare (out of band) area. Newer chips have 2048 Bytes data and and 64 
+Bytes spare area sizes. The spare area is used to store ECC (error correction code), 
+bad block information and filesystem dependend data.
 n pages build one block. The read / write access to data is on a per page basis. 
 Erase is done on a per block basis. The commands to read / write / erase the chip 
 is given by writing to the chip with the Command Latch Enable pin high. Address is 
 given by writing with the Address Latch Enable pin high.</p>
 
-<p>There are only a few lines neccecary to access up to 256 MB of Flashmemory.</p>
+<p>There are only a few lines neccecary to access NAND Flashmemory.</p>
+<p>16 bit buswidth chips are supported.</p>
 <table border="1" cellpadding="2" cellspacing="0">
 <tr><td><b>Pin(s) </b></td><td><b>Function </b></td></tr>
-<tr><td>I/O 0-7 </td><td>Data Inputs/Outputs </td></tr>
+<tr><td>I/O 0-7(15)</td><td>Data Inputs/Outputs </td></tr>
 <tr><td>/CE </td><td>Chip Enable </td></tr>
 <tr><td>CLE </td><td>Command Latch Enable </td></tr>
 <tr><td>ALE </td><td>Address Latch Enable </td>	</tr>
@@ -98,7 +101,7 @@
 different chipselects for /RE and /WE, but be aware of data hold time constraints 
 of your NAND chip. Data hold time after rising edge of /WE is different to data hold 
 timeafter rising edge of chipselect lines!</p>
-<p>I/O 0-7 are connected to the databus D0-D7. The /WP pin can be used for write 
+<p>I/O 0-7(15) are connected to the databus D0-D7(D15). The /WP pin can be used for write 
 protection or connected to VCC to enable writes unconditionally. As NAND flash uses 
 a command driven programming and erasing, an  accidential write or erase is not 
 likely to happen. The Ready / Busy output is not neccecary for operation, 
@@ -138,29 +141,134 @@
 reliable filesystems for industrial use on top of NAND Flash.</p>
 
 <hr>
-<h2>Multiple filesystems on different partitions</h2>
+<h2>Technical information for filesystem implementation</h2>
+<h3>Multiple filesystems on different partitions</h3>
 You can mount different filesystems on different partitions of the same chip. 
-<h3>Technical information for filesystem implementation</h3>
-<h4>OOB usage</h4>
+<h3>OOB usage</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. The parameter is a structure named nand_oobinfo. <br>
 struct nand_oobconfig {<br>
 	int 	useecc;<br>
-	int	eccpos[6];<br>
+	int	eccbytes<br>
+	int	eccpos[24];<br>
+	int	oobfree[8][2];<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 array gives an index for the ecc data
-inside out of band area.
+The content of useecc selects the ecc operation mode:
+<ul>
+<li>MTD_NANDECC_OFF<br>Do not use ECC</li>
+<li>MTD_NANDECC_PLACE<br>Use ECC and place the ECC bytes at the position given by the eccpos 
+array</li>
+<li>MTD_NANDECC_AUTOPLACE<br>Use ECC and place the ECC bytes at the position given by the
+autoplacement defaults in the nand driver</li>
+</ul>
 </p>
 <p>All non ecc functions like mtd->read and mtd->write use an internal structure, which can be set 
-by an ioctl.<br>
+by an ioctl. This structure is preset to the autoplacement default<br>
 ioctl (fd, MEMSETOOBSEL, oobsel);, where oobsel is a pointer to a user supplied structure of type
 oobconfig. The contents of this structure must match the criteria of the filesystem, which will
 be used. See an example in utils/nandwrite.c.
 </p>
+<h3>OOB autoplacement layout</h3>
+<h4>Nand chips with 256 byte pagesize and 8 byte OOB size</h4>
+<table border="1" cellpadding="2" cellspacing="0">
+<tr><td><b>Offset</b></td><td><b>Content</b></td><td><b>Comment</b></td></tr>
+<tr><td>0x00</td><td>ECC byte 0</td><td>Error correction code byte 0</td></tr>
+<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>Autoplace 0</td><td></td></tr>
+<tr><td>0x04</td><td>Autoplace 1</td><td></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>
+<tr><td>0x06</td><td>Autoplace 2</td><td></td></tr>
+<tr><td>0x07</td><td>Autoplace 3</td><td></td></tr>
+</table>
+		
+<h4>Nand chips with 512 byte pagesize and 16 byte OOB size</h4>
+		
+<table border="1" cellpadding="2" cellspacing="0">
+<tr><td><b>Offset</b></td><td><b>Content</b></td><td><b>Comment</b></td></tr>
+<tr><td>0x00</td><td>ECC byte 0</td><td>Error correction code byte 0 of the 
+lower 256 Byte data in this page</td></tr>
+<tr><td>0x01</td><td>ECC byte 1</td><td>Error correction code byte 1 of the 
+lower 256 Bytes of data in this page</td></tr>
+<tr><td>0x02</td><td>ECC byte 2</td><td>Error correction code byte 2 of the 
+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>reserved</td><td>reserved</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>
+<tr><td>0x06</td><td>ECC byte 4</td><td>Error correction code byte 1 of the 
+upper 256 Bytes of data in this page</td></tr>
+<tr><td>0x07</td><td>ECC byte 5</td><td>Error correction code byte 2 of the 
+upper 256 Bytes of data in this page</td></tr>
+<tr><td>0x08 - 0x0F</td><td>Autoplace 0 - 7</td><td></td></tr>
+</table>
+
+<h4>Nand chips with 2048 byte pagesize and 64 byte OOB size</h4>
+		
+<table border="1" cellpadding="2" cellspacing="0">
+<tr><td><b>Offset</b></td><td><b>Content</b></td><td><b>Comment</b></td></tr>
+<tr><td>0x00</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>
+<tr><td>0x01</td><td>Reserved</td><td>Reserved</td></tr>
+<tr><td>0x02-0x27</td><td>Autoplace 0 - 37</td><td></td></tr>
+<tr><td>0x28</td><td>ECC byte 0</td><td>Error correction code byte 0 of the 
+first 256 Byte data in this page</td></tr>
+<tr><td>0x29</td><td>ECC byte 1</td><td>Error correction code byte 1 of the first 256 Bytes of data in this page</td></tr>
+<tr><td>0x2A</td><td>ECC byte 2</td><td>Error correction code byte 2 of the 
+first 256 Bytes data in this page</td></tr>
+<tr><td>0x2B</td><td>ECC byte 3</td><td>Error correction code byte 0 of the 
+second 256 Bytes of data in this page</td></tr>
+<tr><td>0x2C</td><td>ECC byte 4</td><td>Error correction code byte 1 of the 
+second 256 Bytes of data in this page</td></tr>
+<tr><td>0x2D</td><td>ECC byte 5</td><td>Error correction code byte 2 of the 
+second 256 Bytes of data in this page</td></tr>
+<tr><td>0x2E</td><td>ECC byte 6</td><td>Error correction code byte 0 of the 
+third 256 Bytes of data in this page</td></tr>
+<tr><td>0x2F</td><td>ECC byte 7</td><td>Error correction code byte 1 of the 
+third 256 Bytes of data in this page</td></tr>
+<tr><td>0x30</td><td>ECC byte 8</td><td>Error correction code byte 2 of the 
+third 256 Bytes of data in this page</td></tr>
+<tr><td>0x31</td><td>ECC byte 9</td><td>Error correction code byte 0 of the 
+fourth 256 Bytes of data in this page</td></tr>
+<tr><td>0x32</td><td>ECC byte 10</td><td>Error correction code byte 1 of the 
+fourth 256 Bytes of data in this page</td></tr>
+<tr><td>0x33</td><td>ECC byte 11</td><td>Error correction code byte 2 of the 
+fourth 256 Bytes of data in this page</td></tr>
+<tr><td>0x34</td><td>ECC byte 12</td><td>Error correction code byte 0 of the 
+fifth 256 Bytes of data in this page</td></tr>
+<tr><td>0x35</td><td>ECC byte 13</td><td>Error correction code byte 1 of the 
+fifth 256 Bytes of data in this page</td></tr>
+<tr><td>0x36</td><td>ECC byte 14</td><td>Error correction code byte 2 of the 
+fifth 256 Bytes of data in this page</td></tr>
+<tr><td>0x37</td><td>ECC byte 15</td><td>Error correction code byte 0 of the 
+sixt 256 Bytes of data in this page</td></tr>
+<tr><td>0x38</td><td>ECC byte 16</td><td>Error correction code byte 1 of the 
+sixt 256 Bytes of data in this page</td></tr>
+<tr><td>0x39</td><td>ECC byte 17</td><td>Error correction code byte 2 of the 
+sixt 256 Bytes of data in this page</td></tr>
+<tr><td>0x3A</td><td>ECC byte 18</td><td>Error correction code byte 0 of the 
+seventh 256 Bytes of data in this page</td></tr>
+<tr><td>0x3B</td><td>ECC byte 19</td><td>Error correction code byte 1 of the 
+seventh 256 Bytes of data in this page</td></tr>
+<tr><td>0x3C</td><td>ECC byte 20</td><td>Error correction code byte 2 of the 
+seventh 256 Bytes of data in this page</td></tr>
+<tr><td>0x3D</td><td>ECC byte 21</td><td>Error correction code byte 0 of the 
+eigth 256 Bytes of data in this page</td></tr>
+<tr><td>0x3E</td><td>ECC byte 22</td><td>Error correction code byte 1 of the 
+eigth 256 Bytes of data in this page</td></tr>
+<tr><td>0x3F</td><td>ECC byte 23</td><td>Error correction code byte 2 of the 
+eigth 256 Bytes of data in this page</td></tr>
+</table>
 
+<h3>OOB access</h3>
 <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
 supply a big enough buffer.  <br>
@@ -188,20 +296,12 @@
 <hr>
 <h2>JFFS2 specific information </h2>
 <h3>JFFS2 Out of Band usage</h3>
+<p>JFFS2 uses the default autoplacement scheme. The only JFFS2 specific usage of the oob
+area is the storage of the cleanmarker</p>
 
 <h4>Nand chips with 256 byte pagesize and 8 byte OOB size</h4>
-
 <table border="1" cellpadding="2" cellspacing="0">
 <tr><td><b>Offset</b></td><td><b>Content</b></td><td><b>Comment</b></td></tr>
-<tr><td>0x00</td><td>ECC byte 0</td><td>Error correction code byte 0</td></tr>
-<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>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>
 <tr><td>0x06</td><td>Clean marker byte 0</td><td>This byte indicates that a 
 block was erased under JFFS2 control. If the page was succesfully erased 
 this byte in the first page of a block is programmed to 0x85. In the remaining 
@@ -216,23 +316,6 @@
 		
 <table border="1" cellpadding="2" cellspacing="0">
 <tr><td><b>Offset</b></td><td><b>Content</b></td><td><b>Comment</b></td></tr>
-<tr><td>0x00</td><td>ECC byte 0</td><td>Error correction code byte 0 of the 
-lower 256 Byte data in this page</td></tr>
-<tr><td>0x01</td><td>ECC byte 1</td><td>Error correction code byte 1 of the 
-lower 256 Bytes of data in this page</td></tr>
-<tr><td>0x02</td><td>ECC byte 2</td><td>Error correction code byte 2 of the 
-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>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>
-<tr><td>0x06</td><td>ECC byte 4</td><td>Error correction code byte 1 of the 
-upper 256 Bytes of data in this page</td></tr>
-<tr><td>0x07</td><td>ECC byte 5</td><td>Error correction code byte 2 of the 
-upper 256 Bytes of data in this page</td></tr>
 <tr><td>0x08</td><td>Clean marker byte 0</td><td>This byte indicates that a 
 block was erased under JFFS2 control. If the page was succesfully erased 
 this byte in the first page of a block is programmed to 0x85. In the remaining 
@@ -266,6 +349,44 @@
 this byte in the first page of a block is programmed to 0x00. In the remaining 
 pages this byte is reserved</td></tr>
 </table>
+
+<h4>Nand chips with 2048 byte pagesize and 64 byte OOB size</h4>
+		
+<table border="1" cellpadding="2" cellspacing="0">
+<tr><td><b>Offset</b></td><td><b>Content</b></td><td><b>Comment</b></td></tr>
+<tr><td>0x10</td><td>Clean marker byte 0</td><td>This byte indicates that a 
+block was erased under JFFS2 control. If the page was succesfully erased 
+this byte in the first page of a block is programmed to 0x85. In the remaining 
+pages this byte is reserved</td></tr>
+<tr><td>0x11</td><td>Clean marker byte 1</td><td>This byte indicates that a 
+block was erased under JFFS2 control. If the page was succesfully erased 
+this byte in the first page of a block is programmed to 0x19. In the remaining 
+pages this byte is reserved</td></tr>
+<tr><td>0x12</td><td>Clean marker byte 2</td><td>This byte indicates that a 
+block was erased under JFFS2 control. If the page was succesfully erased 
+this byte in the first page of a block is programmed to 0x03. In the remaining 
+pages this byte is reserved</td></tr>
+<tr><td>0x13</td><td>Clean marker byte 3</td><td>This byte indicates that a 
+block was erased under JFFS2 control. If the page was succesfully erased 
+this byte in the first page of a block is programmed to 0x20. In the remaining 
+pages this byte is reserved</td></tr>
+<tr><td>0x14</td><td>Clean marker byte 4</td><td>This byte indicates that a 
+block was erased under JFFS2 control. If the page was succesfully erased 
+this byte in the first page of a block is programmed to 0x08. In the remaining 
+pages this byte is reserved</td></tr>
+<tr><td>0x15</td><td>Clean marker byte 5</td><td>This byte indicates that a 
+block was erased under JFFS2 control. If the page was succesfully erased 
+this byte in the first page of a block is programmed to 0x00. In the remaining 
+pages this byte is reserved</td></tr>
+<tr><td>0x16</td><td>Clean marker byte 6</td><td>This byte indicates that a 
+block was erased under JFFS2 control. If the page was succesfully erased 
+this byte in the first page of a block is programmed to 0x00. In the remaining 
+pages this byte is reserved</td></tr>
+<tr><td>0x17</td><td>Clean marker byte 7</td><td>This byte indicates that a 
+block was erased under JFFS2 control. If the page was succesfully erased 
+this byte in the first page of a block is programmed to 0x00. In the remaining 
+pages this byte is reserved</td></tr>
+</table>
 		
 <hr>
 		
@@ -299,11 +420,14 @@
 <li>Init function</li>
 </ol>
 To provide enough flexibilty for all kind of devices, there can be supplied additional
-functions optionally.
+functions optionally. Almost everything can be overridden.
 <ol>
 <li>Hardware specific command function</li>
 <li>Hardware specific wait function</li>
 <li>Hardware ECC functions</li>
+<li>Hardware specific chip select function, which supports chiparrays</li>
+<li>Hardware specific read, write and verify functions</li>
+<li>Hardware specific bad block management</li>
 </ol></p>
 
 <h4>Hardware specific control function</h4>
@@ -431,22 +555,33 @@
 
 <p><b>All the function pointers must be set in yourboard_init before calling nand_scan.</b></p>
 
+<h4>Hardware specific chip select function for chip arrays</h4>
+<p>The driver supports chip arrays, which share the I/O lines and
+the controllines. There is no support for arrays which extend the
+buswidth.
+</p>
+<p>The hw specific chip select function is called with the chipnr (0 - n-1) or
+with -1. -1 indicates that the chips must be deselected. 
+</p>
+
 <h3>Supported chips</h3>
-<p>Most NAND chips actually available from 2 to 128MB should be supported by the current code. 
+<p>Most NAND chips actually available should be supported by the current code. 
 If you have a chip, which is not supported, you can easily add it by extending the chiplist in 
-drivers/mtd/nand/nand.c. The chip name does not longer contain cryptic part numbers, as the device
+drivers/mtd/nand/nand_ids.c. The chip name does not longer contain cryptic part numbers, as the device
 ID is just an information about size, erase block size, pagesize and operating voltage.
 Add an entry, which contains following information: <br>
 				
-{ name, id, chipshift, erasesize, page256 }</p>
+{ name, id, pagesize, chipsize, erasesize, options }</p>
 <table border="1" cellpadding="2" cellspacing="0">
 <tr><td><b>ref</b></td>	<td><b>comment</b></td></tr>
-<tr><td>name</td><td>string: "NAND 'size' 'voltage'" </td></tr>
+<tr><td>name</td><td>string: "NAND 'size' 'voltage' 'bus-width'" </td></tr>
 <tr><td>id</td><td>chip device code. This code is read during nand_scan. Check datasheet 
 for the code of your chip</td></tr>
-<tr><td>chipshift</td><td>chip size indicator. Chip size = (1 << chipshift)</td></tr>
-<tr><td>erasesize</td><td>the erasesize of your chip in bytes. Consult datasheet for proper 
-<tr><td>page256</td><td>set this to 1, if your chip has pagelength 256 byte, else set it to 0.</td></tr>
+<tr><td>pagesize</td><td>Page size (0,256,512). 0 indicates that the pagesize can be
+read out from the chip in the extended ID</td></tr>
+<tr><td>chipsize</td><td>The total size of the chip in MiB</td></tr> 
+<tr><td>erasesize</td><td>the erasesize of your chip in bytes. 0 for chips with extended ID</td></tr>
+<tr><td>options</td><td>Options. Bitfield to enable chip specific options. See nand.h</td></tr>
 </table>
 
 <p>Please contact NAND driver maintainer to include it in the public source tree. </p>
@@ -486,12 +621,12 @@
 is to use a small e.g. 1MB NOR Flash, which contains the boot code and maybe a compressed kernel
 image. Then you can use JFFS2 on NAND as your root filesystem</p>
 <p>Some newer chips make the first page available for reading after power up. This could be
-helpful for starting a small 256/512 byte bootcode. At the time of this writing there is no
+helpful for starting a small 256/512/2048 byte bootcode. At the time of this writing there is no
 tested implementation of this.</p>
 <p>Samsungs S3C2410 ARM based SOC-CPU provides a mechanism to boot from NAND flash.</p>
 
-<h4>Is there support for 16/32bit wide NAND Flash ?</h4>
-<p>No. The generic NAND driver supports 8 bit wide NAND Flash only. 16 or 32 bit NAND Flash can
+<h4>Is there support for 32bit wide NAND Flash ?</h4>
+<p>No. The generic NAND driver supports 8/16 bit wide NAND Flash only. 32 bit NAND Flash can
 be built by using 2 or 4 chips and connect them to D0-7, D8-D15, D16-D23 and D24-D31 on the data bus.
 You can tie all corresponding control signals together. But you have to build a new nand16 or nand32 driver,
 which can be derived from the existing nand.c. Be aware, that the writebuffer size is 2 or 4 times as big as
@@ -499,7 +634,7 @@
 more memory space than on 8 bit NAND. Another point is bad block handling. When a block on 1 chip is bad, the
 corresponding blocks on the other chips are lost too, as you present them as one big block to the filesystem
 driver. The JFFS2 code, which handles the writebuffer and the out of band (spare) area of NAND doesn't support
-16 / 32 bit neither.</p>
+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, 
@@ -507,6 +642,11 @@
 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 2 seconds. 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 
@@ -528,6 +668,25 @@
 ioctl (MEMSETOOBSEL). A example for bad block handling and usage of ioctl (MEMOOBSEL) can be found in
 util/nandwrite.c
 </p>
+<p>Recent changes to the NAND layer now make it possible to read/write across a block boundary.</P>
+
+<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
+catch out the unwary novice. The following messages can be moved to a higher log level once you are sure
+that they are benign.</p>
+
+<code>Empty flash at 0xXXXXXXXX ends at 0xXXXXXXXX</code>
+<p>This message is generated if a block of data is partially written. It is generally not a sign of any
+problem.</p>
+
+<code>jffs2: Erase block size too small (XXKiB). Using virtual blocks size(XXKiB) instead</code>
+<p>Output for larger NAND devices to reduce memory allocation.</p>
+
+<code>jffs2: No clean, dirty _or_ erasable blocks to GC from! Where are they all?</code><br>
+<code>jffs2: Couldn't find erase block to garbage collect!</code>
+<p>These two messages are generally output together. They are usually output on dismount and simply
+indicate that the garbage collector has nothing to do. This is more likely to be seen for filesystems which
+have few files or no activity.</p>
 
 <h4>Must my bootloader be aware of NAND FLASH&nbsp;?</h4>
 <p>Yes, if you use your bootloader to erase the FLASH chip and copy a filesystem image to it. 




More information about the linux-mtd-cvs mailing list