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