1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
|
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>Linux-MTD NAND FLASH</title>
<STYLE TYPE="text/css">
<!--
body {
font-family: Arial,Helvetica,Geneva,Swiss,SunSans-Regular;
}
-->
</STYLE>
</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
NAND and NOR Flash is the bus interface. NOR Flash is connected to a address / data
bus direct like other memory devices as SRAM etc. NAND Flash uses a multiplexed I/O
Interface with some additional control pins. NAND flash is a sequential access device
appropriate for mass storage applications, while NOR flash is a random access device
appropriate for code storage application.NOR Flash can be used for code storage and
code execution. Code stored on NAND Flash can't be executed frome there. It must be
loaded into RAM memory and executed from there.</p>
<table border="1" cellpadding="2" cellspacing="0">
<tr><td></td><td><b>NOR </b></td><td><b>NAND </b></td></tr>
<tr><td>Interface </td><td>Bus </td><td>I/O </td></tr>
<tr><td>Cell Size </td><td>Large </td><td>Small </td></tr>
<tr><td>Cell Cost </td><td>High </td><td>Low </td></tr>
<tr><td>Read Time </td><td>Fast </td><td>Slow </td></tr>
<tr><td>Program Time single Byte</td><td>Fast </td><td>Slow </td></tr>
<tr><td>Program Time multi Byte</td><td>Slow </td><td>Fast </td></tr>
<tr><td>Erase Time </td><td>Slow </td><td>Fast </td></tr>
<tr><td>Power consumption </td><td>High </td><td>Low, but requires additional RAM </td></tr>
<tr><td>Can execute code </td><td>Yes </td><td>No, but newer chips can execute a small
loader out of the first page</td></tr>
<tr><td>Bit twiddling </td><td>nearly unrestricted </td><td>1-3 times, also known as
"partial page program restriction"</td></tr>
<tr><td>Bad blocks at ship time </td><td>No</td><td>Allowed</td></tr>
</table>
<p>Some facts about write speed. <br>
NAND is typically faster than NOR for large writes. A typical NOR write is 10uS
per word, which results in 1280uS per 512 bytes on a 32-bit bus. A typical NAND
write is 50nS per byte + 10uS page seek + 200uS program which results in 236uS
per 512 bytes on a 8 bit bus.</p>
<p>As NAND Flash is cheaper than NOR Flash and has a very slim interface it was
selected as the optimum solution for large nonvolatile storage applications such
as solid state file storage, digital audio/voice recorder,
digital still camera and portable applications requiring non-volatility.</p>
<hr>
<h2>NAND Types</h2>
<p>There are various types of NAND Flash available.
Bare NAND chips, SmartMediaCards, DiskOnChip.</p>
<p>SmartMediaCards are bare NAND chips covered by thin plastic. They are very common in
digital cameras and MP3 players. The card itself contains nothing smart at all. It gets
smart by software.</p>
<p>DiskOnChip is NAND Flash with additional glue logic as a drop in replacement for NOR
Flash chips. The glue logic provides direct memory access to a small address window,
which contains a boot loader stub, which loads the real boot code from the NAND device.
The logic contains also control registers for the static NAND chip control lines and a
hardware ECC generator.</p>
<hr>
<h2>NAND technical view</h2>
<p>The memory is arranged as an array of pages. A page consists of 256 / 512 Byte 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 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(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>
<tr><td>/RE </td><td>Read Enable </td></tr>
<tr><td>/WE </td><td>Write Enable </td> </tr>
<tr><td>/WP </td><td>Write Protect </td></tr>
<tr><td>/SE </td><td>Spare area Enable </td></tr>
<tr><td>R/B </td><td>Ready / Busy Output </td></tr>
</table>
<p>As it is neccecary to use the spare area, the /SE (Spare area Enable) pin should
be tied to GND. /CE, CLE and ALE should be GPIO pins or latched signals. It's possible
to use address lines for ALE and CLE, but you have to take care about the timing
restrictions of the chip ! </p>
<p>/RE and /WE can be tied to the corresponding lines of the CPU. Make sure, that
they are logicaly combined with the corresponding chipselect. You can also use two
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
time after rising edge of chipselect lines!</p>
<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,
but it can be tied to a GPIO or an interrupt line. </p>
<hr>
<h2>Filesystems supporting NAND</h2>
<p>One major problem for using NAND Flash is, that you cannot write as often as you
want to a page. The consecutive writes to a page, before erasing it again, are
restricted to 1-3 writes, depending on the manufacturers specifications. This applies
similar to the spare area. This makes it neccecary for the filesystem to handle a writebuffer,
which contains data, that is less than a page</p>
<p>At the moment there are only a few filesystems, which support NAND</p>
<ul>
<li>JFFS2 and YAFFS for bare NAND Flash and SmartMediaCards </li>
<li>NTFL for DiskOnChip devices </li>
<li>TRUEFFS from M-Systems for DiskOnChip devices</li>
<li>SmartMedia DOS-FAT as defined by the SSFDC Forum</li>
</ul>
<p>JFFS2 and NTFL are Open Source, while TRUEFFS is a proprietary solution.
SmartMedia DOS-Fat is a specification from SSFDC forum. It is somewhat open under a
non disclosure agreement with Toshiba, who owns all rights on this specifications. NTFL is
designed for the usage of DiskOnChip devices. JFFS2 supports raw NAND chips and
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>.
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. There are some efforts to implement it, but it's
in an early stage. 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 and YAFFS include bad block management, wear leveling, error correction and provide
reliable filesystems for industrial use on top of NAND Flash.</p>
<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>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
pages this byte is reserved</td></tr>
<tr><td>0x07</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>
</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>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
pages this byte is reserved</td></tr>
<tr><td>0x09</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>0x0a</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>0x0b</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>0x0c</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>0x0d</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>0x0e</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>0x0f</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>
<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>
<h2>HOWTO implement NAND support</h2>
<h3>Where can you get the code ?</h3>
<p>The latest changes to JFFS2 and the underlying NAND code are not in the
kernel code at the moment. The latest code is available from
<a href=http://www.linux-mtd.infradead.org>CVS and daily snapshots</a></p>
<p>There are four layers of software</p>
<ol>
<li>JFFS2: filesystem driver</li>
<li>MTD: Memory Technology Devices driver</li>
<li>NAND: generic NAND driver </li>
<li>Hardware specific driver </li>
</ol>
<p>the MTD driver just provides a mount point for JFFS2. The generic NAND
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. For YAFFS applies the same.</p>
<h3>API Documentation</h3>
<p>A complete API documentation is available as DocBook template in the
Documentation/DocBook directory of the MTD source tree.
</p>
<p>Read the API documentation <a href="mtdnand/index.html">online</a>
<h3>Supported chips</h3>
<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_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, 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' '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>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>
<p>Manufacturer codes are scanned during nand_scan too. If the code is one of the
known codes in the manufacturer ID table, the name of the manufacturer is printed out,
else "Unknown" is printed. This happens when your hardware driver
is loaded and calls nand_scan. Add codes, which are new and contact NAND driver
maintainer to include it</p>
<h3>Config settings</h3>
<p>The following config switches have to be set. JFFS2 on NAND <b>does not</b> work,
if one of these settings is missing.</p>
<p>CONFIG_MTD=y<br>
CONFIG_MTD_PARTITIONS=y<br>
CONFIG_MTD_CHAR=y<br>
CONFIG_MTD_BLOCK=y<br>
CONFIG_MTD_NAND=y<br>
CONFIG_MTD_NAND_YOURBOARD=y<br>
CONFIG_JFFS2_FS=y<br>
CONFIG_JFFS2_FS_DEBUG=0<br>
CONFIG_JFFS2_FS_NAND=y</p>
<p>Make sure that fs/Config.in contains the following lines:<br>
dep_tristate 'Journalling Flash File System v2 (JFFS2) support' CONFIG_JFFS2_FS $CONFIG_MTD<br>
if [ "$CONFIG_JFFS2_FS" = "y" -o "$CONFIG_JFFS2_FS" = "m" ] ; then<br>
int 'JFFS2 debugging verbosity (0 = quiet, 2 = noisy)' CONFIG_JFFS2_FS_DEBUG 0<br>
bool 'JFFS2 support for NAND chips' CONFIG_JFFS2_FS_NAND<br>
fi</p>
<hr>
<h2>FAQ</h2>
<h4>Can I boot from NAND Flash?</h4>
<p>Not from a bare NAND chip. You need a glue logic around, which gives you memory access to the
chip on bootup, like the DiskOnChip devices do. This will be a quite complex CPLD. An alternative
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/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 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
on 8 bit NAND. This mean's, if you flush the buffer to ensure, that your data are on disk, you may waste much
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
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 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
NAND 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
oob-layout selection are set for JFFS2. For bad block aware copying, use nandwrite from mtd-utils.<br>
nandwrite -j /dev/mtdX image
</p>
<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>
<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 ?</h4>
<p>Yes, if you use your bootloader to erase the FLASH chip and copy a filesystem image to it.
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 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 256 byte pagesize devices program the following data into the out of band area:</p>
<table border="1" cellpadding="5" cellspacing="0">
<tr><td>Offset</td><td>0x06</td><td>0x07</td></tr>
<tr><td>Data</td><td>0x85</td><td>0x19</td></tr>
</table>
<p>For 512 byte pagesize devices program the following data into the out of band area:</p>
<table border="1" cellpadding="5" cellspacing="0">
<tr><td>Offset</td><td>0x08</td><td>0x09</td><td>0x0a</td><td>0x0b</td><td>0x0c</td><td>0x0d</td>
<td>0x0e</td><td>0x0f</td></tr>
<tr><td>Data</td><td>0x85</td><td>0x19</td><td>0x03</td><td>0x20</td><td>0x08</td><td>0x00</td>
<td>0x00</td><td>0x00</td></tr>
</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 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>
<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>.<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>
<p><a href=http://www.ssfdc.or.jp>SSFDC Forum</a></p>
<p><a href=http://www.m-sys.com>M-Systems</a></p>
<hr>
<h2>Maintainers</h2>
<p>JFFS2 is maintained by David Woodhouse</p>
<p>The generic NAND driver is maintained by Thomas Gleixner</p>
<p>Please don't contact them direct. Ask your questions on the
<a href=http://www.linux-mtd.infradead.org>mtd-mailing-list</a>.</p>
<p>Any suggestions, improvements, bug-reports and bug-fixes are welcome</p>
<hr>
<address><a href="mailto:tglx@linutronix.de">Thomas Gleixner</a></address>
$Id: nand.html,v 1.20 2005/01/19 19:40:40 jwboyer Exp $
</body>
</html>
|
