xref: /linux/drivers/mtd/Kconfig (revision eb2bce7f5e7ac1ca6da434461217fadf3c688d2c)
1# $Id: Kconfig,v 1.11 2005/11/07 11:14:19 gleixner Exp $
2
3menuconfig MTD
4	tristate "Memory Technology Device (MTD) support"
5	help
6	  Memory Technology Devices are flash, RAM and similar chips, often
7	  used for solid state file systems on embedded devices. This option
8	  will provide the generic support for MTD drivers to register
9	  themselves with the kernel and for potential users of MTD devices
10	  to enumerate the devices which are present and obtain a handle on
11	  them. It will also allow you to select individual drivers for
12	  particular hardware and users of MTD devices. If unsure, say N.
13
14if MTD
15
16config MTD_DEBUG
17	bool "Debugging"
18	help
19	  This turns on low-level debugging for the entire MTD sub-system.
20	  Normally, you should say 'N'.
21
22config MTD_DEBUG_VERBOSE
23	int "Debugging verbosity (0 = quiet, 3 = noisy)"
24	depends on MTD_DEBUG
25	default "0"
26	help
27	  Determines the verbosity level of the MTD debugging messages.
28
29config MTD_CONCAT
30	tristate "MTD concatenating support"
31	help
32	  Support for concatenating several MTD devices into a single
33	  (virtual) one. This allows you to have -for example- a JFFS(2)
34	  file system spanning multiple physical flash chips. If unsure,
35	  say 'Y'.
36
37config MTD_PARTITIONS
38	bool "MTD partitioning support"
39	help
40	  If you have a device which needs to divide its flash chip(s) up
41	  into multiple 'partitions', each of which appears to the user as
42	  a separate MTD device, you require this option to be enabled. If
43	  unsure, say 'Y'.
44
45	  Note, however, that you don't need this option for the DiskOnChip
46	  devices. Partitioning on NFTL 'devices' is a different - that's the
47	  'normal' form of partitioning used on a block device.
48
49config MTD_REDBOOT_PARTS
50	tristate "RedBoot partition table parsing"
51	depends on MTD_PARTITIONS
52	---help---
53	  RedBoot is a ROM monitor and bootloader which deals with multiple
54	  'images' in flash devices by putting a table one of the erase
55	  blocks on the device, similar to a partition table, which gives
56	  the offsets, lengths and names of all the images stored in the
57	  flash.
58
59	  If you need code which can detect and parse this table, and register
60	  MTD 'partitions' corresponding to each image in the table, enable
61	  this option.
62
63	  You will still need the parsing functions to be called by the driver
64	  for your particular device. It won't happen automatically. The
65	  SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
66	  example.
67
68config MTD_REDBOOT_DIRECTORY_BLOCK
69	int "Location of RedBoot partition table"
70	depends on MTD_REDBOOT_PARTS
71	default "-1"
72	---help---
73	  This option is the Linux counterpart to the
74	  CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
75	  option.
76
77	  The option specifies which Flash sectors holds the RedBoot
78	  partition table.  A zero or positive value gives an absolute
79	  erase block number. A negative value specifies a number of
80	  sectors before the end of the device.
81
82	  For example "2" means block number 2, "-1" means the last
83	  block and "-2" means the penultimate block.
84
85config MTD_REDBOOT_PARTS_UNALLOCATED
86	bool "Include unallocated flash regions"
87	depends on MTD_REDBOOT_PARTS
88	help
89	  If you need to register each unallocated flash region as a MTD
90	  'partition', enable this option.
91
92config MTD_REDBOOT_PARTS_READONLY
93	bool "Force read-only for RedBoot system images"
94	depends on MTD_REDBOOT_PARTS
95	help
96	  If you need to force read-only for 'RedBoot', 'RedBoot Config' and
97	  'FIS directory' images, enable this option.
98
99config MTD_CMDLINE_PARTS
100	bool "Command line partition table parsing"
101	depends on MTD_PARTITIONS = "y" && MTD = "y"
102	---help---
103	  Allow generic configuration of the MTD partition tables via the kernel
104	  command line. Multiple flash resources are supported for hardware where
105	  different kinds of flash memory are available.
106
107	  You will still need the parsing functions to be called by the driver
108	  for your particular device. It won't happen automatically. The
109	  SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
110	  example.
111
112	  The format for the command line is as follows:
113
114	  mtdparts=<mtddef>[;<mtddef]
115	  <mtddef>  := <mtd-id>:<partdef>[,<partdef>]
116	  <partdef> := <size>[@offset][<name>][ro]
117	  <mtd-id>  := unique id used in mapping driver/device
118	  <size>    := standard linux memsize OR "-" to denote all
119	  remaining space
120	  <name>    := (NAME)
121
122	  Due to the way Linux handles the command line, no spaces are
123	  allowed in the partition definition, including mtd id's and partition
124	  names.
125
126	  Examples:
127
128	  1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
129	  mtdparts=sa1100:-
130
131	  Same flash, but 2 named partitions, the first one being read-only:
132	  mtdparts=sa1100:256k(ARMboot)ro,-(root)
133
134	  If unsure, say 'N'.
135
136config MTD_AFS_PARTS
137	tristate "ARM Firmware Suite partition parsing"
138	depends on ARM && MTD_PARTITIONS
139	---help---
140	  The ARM Firmware Suite allows the user to divide flash devices into
141	  multiple 'images'. Each such image has a header containing its name
142	  and offset/size etc.
143
144	  If you need code which can detect and parse these tables, and
145	  register MTD 'partitions' corresponding to each image detected,
146	  enable this option.
147
148	  You will still need the parsing functions to be called by the driver
149	  for your particular device. It won't happen automatically. The
150	  'armflash' map driver (CONFIG_MTD_ARMFLASH) does this, for example.
151
152comment "User Modules And Translation Layers"
153
154config MTD_CHAR
155	tristate "Direct char device access to MTD devices"
156	help
157	  This provides a character device for each MTD device present in
158	  the system, allowing the user to read and write directly to the
159	  memory chips, and also use ioctl() to obtain information about
160	  the device, or to erase parts of it.
161
162config MTD_BLKDEVS
163	tristate "Common interface to block layer for MTD 'translation layers'"
164	depends on BLOCK
165	default n
166
167config MTD_BLOCK
168	tristate "Caching block device access to MTD devices"
169	depends on BLOCK
170	select MTD_BLKDEVS
171	---help---
172	  Although most flash chips have an erase size too large to be useful
173	  as block devices, it is possible to use MTD devices which are based
174	  on RAM chips in this manner. This block device is a user of MTD
175	  devices performing that function.
176
177	  At the moment, it is also required for the Journalling Flash File
178	  System(s) to obtain a handle on the MTD device when it's mounted
179	  (although JFFS and JFFS2 don't actually use any of the functionality
180	  of the mtdblock device).
181
182	  Later, it may be extended to perform read/erase/modify/write cycles
183	  on flash chips to emulate a smaller block size. Needless to say,
184	  this is very unsafe, but could be useful for file systems which are
185	  almost never written to.
186
187	  You do not need this option for use with the DiskOnChip devices. For
188	  those, enable NFTL support (CONFIG_NFTL) instead.
189
190config MTD_BLOCK_RO
191	tristate "Readonly block device access to MTD devices"
192	depends on MTD_BLOCK!=y && BLOCK
193	select MTD_BLKDEVS
194	help
195	  This allows you to mount read-only file systems (such as cramfs)
196	  from an MTD device, without the overhead (and danger) of the caching
197	  driver.
198
199	  You do not need this option for use with the DiskOnChip devices. For
200	  those, enable NFTL support (CONFIG_NFTL) instead.
201
202config FTL
203	tristate "FTL (Flash Translation Layer) support"
204	depends on BLOCK
205	select MTD_BLKDEVS
206	---help---
207	  This provides support for the original Flash Translation Layer which
208	  is part of the PCMCIA specification. It uses a kind of pseudo-
209	  file system on a flash device to emulate a block device with
210	  512-byte sectors, on top of which you put a 'normal' file system.
211
212	  You may find that the algorithms used in this code are patented
213	  unless you live in the Free World where software patents aren't
214	  legal - in the USA you are only permitted to use this on PCMCIA
215	  hardware, although under the terms of the GPL you're obviously
216	  permitted to copy, modify and distribute the code as you wish. Just
217	  not use it.
218
219config NFTL
220	tristate "NFTL (NAND Flash Translation Layer) support"
221	depends on BLOCK
222	select MTD_BLKDEVS
223	---help---
224	  This provides support for the NAND Flash Translation Layer which is
225	  used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
226	  file system on a flash device to emulate a block device with
227	  512-byte sectors, on top of which you put a 'normal' file system.
228
229	  You may find that the algorithms used in this code are patented
230	  unless you live in the Free World where software patents aren't
231	  legal - in the USA you are only permitted to use this on DiskOnChip
232	  hardware, although under the terms of the GPL you're obviously
233	  permitted to copy, modify and distribute the code as you wish. Just
234	  not use it.
235
236config NFTL_RW
237	bool "Write support for NFTL"
238	depends on NFTL
239	help
240	  Support for writing to the NAND Flash Translation Layer, as used
241	  on the DiskOnChip.
242
243config INFTL
244	tristate "INFTL (Inverse NAND Flash Translation Layer) support"
245	depends on BLOCK
246	select MTD_BLKDEVS
247	---help---
248	  This provides support for the Inverse NAND Flash Translation
249	  Layer which is used on M-Systems' newer DiskOnChip devices. It
250	  uses a kind of pseudo-file system on a flash device to emulate
251	  a block device with 512-byte sectors, on top of which you put
252	  a 'normal' file system.
253
254	  You may find that the algorithms used in this code are patented
255	  unless you live in the Free World where software patents aren't
256	  legal - in the USA you are only permitted to use this on DiskOnChip
257	  hardware, although under the terms of the GPL you're obviously
258	  permitted to copy, modify and distribute the code as you wish. Just
259	  not use it.
260
261config RFD_FTL
262        tristate "Resident Flash Disk (Flash Translation Layer) support"
263	depends on BLOCK
264	select MTD_BLKDEVS
265	---help---
266	  This provides support for the flash translation layer known
267	  as the Resident Flash Disk (RFD), as used by the Embedded BIOS
268	  of General Software. There is a blurb at:
269
270		http://www.gensw.com/pages/prod/bios/rfd.htm
271
272config SSFDC
273	tristate "NAND SSFDC (SmartMedia) read only translation layer"
274	depends on BLOCK
275	select MTD_BLKDEVS
276	help
277	  This enables read only access to SmartMedia formatted NAND
278	  flash. You can mount it with FAT file system.
279
280source "drivers/mtd/chips/Kconfig"
281
282source "drivers/mtd/maps/Kconfig"
283
284source "drivers/mtd/devices/Kconfig"
285
286source "drivers/mtd/nand/Kconfig"
287
288source "drivers/mtd/onenand/Kconfig"
289
290source "drivers/mtd/ubi/Kconfig"
291
292endif # MTD
293