1 # $Id: Kconfig,v 1.3 2003/05/28 11:02:23 dwmw2 Exp $
3 menu "Memory Technology Devices (MTD)"
6 tristate "Memory Technology Device (MTD) support"
8 Memory Technology Devices are flash, RAM and similar chips, often
9 used for solid state file systems on embedded devices. This option
10 will provide the generic support for MTD drivers to register
11 themselves with the kernel and for potential users of MTD devices
12 to enumerate the devices which are present and obtain a handle on
13 them. It will also allow you to select individual drivers for
14 particular hardware and users of MTD devices. If unsure, say N.
20 This turns on low-level debugging for the entire MTD sub-system.
21 Normally, you should say 'N'.
23 config MTD_DEBUG_VERBOSE
24 int "Debugging verbosity (0 = quiet, 3 = noisy)"
28 Determines the verbosity level of the MTD debugging messages.
31 tristate "MTD partitioning support"
34 If you have a device which needs to divide its flash chip(s) up
35 into multiple 'partitions', each of which appears to the user as
36 a separate MTD device, you require this option to be enabled. If
39 Note, however, that you don't need this option for the DiskOnChip
40 devices. Partitioning on NFTL 'devices' is a different - that's the
41 'normal' form of partitioning used on a block device.
44 tristate "MTD concatenating support"
47 Support for concatenating several MTD devices into a single
48 (virtual) one. This allows you to have -for example- a JFFS(2)
49 file system spanning multiple physical flash chips. If unsure,
52 config MTD_REDBOOT_PARTS
53 tristate "RedBoot partition table parsing"
54 depends on MTD_PARTITIONS
56 RedBoot is a ROM monitor and bootloader which deals with multiple
57 'images' in flash devices by putting a table in the last erase
58 block of the device, similar to a partition table, which gives
59 the offsets, lengths and names of all the images stored in the
62 If you need code which can detect and parse this table, and register
63 MTD 'partitions' corresponding to each image in the table, enable
66 You will still need the parsing functions to be called by the driver
67 for your particular device. It won't happen automatically. The
68 SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
71 config MTD_CMDLINE_PARTS
72 tristate "Command line partition table parsing"
73 depends on MTD_PARTITIONS
75 Allow generic configuration of the MTD paritition tables via the kernel
76 command line. Multiple flash resources are supported for hardware where
77 different kinds of flash memory are available.
79 You will still need the parsing functions to be called by the driver
80 for your particular device. It won't happen automatically. The
81 SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
84 The format for the command line is as follows:
86 mtdparts=<mtddef>[;<mtddef]
87 <mtddef> := <mtd-id>:<partdef>[,<partdef>]
88 <partdef> := <size>[@offset][<name>][ro]
89 <mtd-id> := unique id used in mapping driver/device
90 <size> := standard linux memsize OR "-" to denote all
94 Due to the way Linux handles the command line, no spaces are
95 allowed in the partition definition, including mtd id's and partition
100 1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
103 Same flash, but 2 named partitions, the first one being read-only:
104 mtdparts=sa1100:256k(ARMboot)ro,-(root)
109 tristate "ARM Firmware Suite partition parsing"
110 depends on ARM && MTD_PARTITIONS
112 The ARM Firmware Suite allows the user to divide flash devices into
113 multiple 'images'. Each such image has a header containing its name
116 If you need code which can detect and parse these tables, and
117 register MTD 'partitions' corresponding to each image detected,
120 You will still need the parsing functions to be called by the driver
121 for your particular device. It won't happen automatically. The
122 'armflash' map driver (CONFIG_MTD_ARMFLASH) does this, for example.
124 comment "User Modules And Translation Layers"
128 tristate "Direct char device access to MTD devices"
131 This provides a character device for each MTD device present in
132 the system, allowing the user to read and write directly to the
133 memory chips, and also use ioctl() to obtain information about
134 the device, or to erase parts of it.
137 tristate "Caching block device access to MTD devices"
140 Although most flash chips have an erase size too large to be useful
141 as block devices, it is possible to use MTD devices which are based
142 on RAM chips in this manner. This block device is a user of MTD
143 devices performing that function.
145 At the moment, it is also required for the Journalling Flash File
146 System(s) to obtain a handle on the MTD device when it's mounted
147 (although JFFS and JFFS2 don't actually use any of the functionality
148 of the mtdblock device).
150 Later, it may be extended to perform read/erase/modify/write cycles
151 on flash chips to emulate a smaller block size. Needless to say,
152 this is very unsafe, but could be useful for file systems which are
153 almost never written to.
155 You do not need this option for use with the DiskOnChip devices. For
156 those, enable NFTL support (CONFIG_NFTL) instead.
159 tristate "Readonly block device access to MTD devices"
160 depends on MTD_BLOCK!=y && MTD
162 This allows you to mount read-only file systems (such as cramfs)
163 from an MTD device, without the overhead (and danger) of the caching
166 You do not need this option for use with the DiskOnChip devices. For
167 those, enable NFTL support (CONFIG_NFTL) instead.
170 tristate "FTL (Flash Translation Layer) support"
173 This provides support for the original Flash Translation Layer which
174 is part of the PCMCIA specification. It uses a kind of pseudo-
175 file system on a flash device to emulate a block device with
176 512-byte sectors, on top of which you put a 'normal' file system.
178 You may find that the algorithms used in this code are patented
179 unless you live in the Free World where software patents aren't
180 legal - in the USA you are only permitted to use this on PCMCIA
181 hardware, although under the terms of the GPL you're obviously
182 permitted to copy, modify and distribute the code as you wish. Just
186 tristate "NFTL (NAND Flash Translation Layer) support"
189 This provides support for the NAND Flash Translation Layer which is
190 used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
191 file system on a flash device to emulate a block device with
192 512-byte sectors, on top of which you put a 'normal' file system.
194 You may find that the algorithms used in this code are patented
195 unless you live in the Free World where software patents aren't
196 legal - in the USA you are only permitted to use this on DiskOnChip
197 hardware, although under the terms of the GPL you're obviously
198 permitted to copy, modify and distribute the code as you wish. Just
202 bool "Write support for NFTL"
205 Support for writing to the NAND Flash Translation Layer, as used
209 tristate "INFTL (Inverse NAND Flash Translation Layer) support"
212 This provides support for the Inverse NAND Flash Translation
213 Layer which is used on M-Systems' newer DiskOnChip devices. It
214 uses a kind of pseudo-file system on a flash device to emulate
215 a block device with 512-byte sectors, on top of which you put
216 a 'normal' file system.
218 You may find that the algorithms used in this code are patented
219 unless you live in the Free World where software patents aren't
220 legal - in the USA you are only permitted to use this on DiskOnChip
221 hardware, although under the terms of the GPL you're obviously
222 permitted to copy, modify and distribute the code as you wish. Just
225 source "drivers/mtd/chips/Kconfig"
227 source "drivers/mtd/maps/Kconfig"
229 source "drivers/mtd/devices/Kconfig"
231 source "drivers/mtd/nand/Kconfig"