Thomas Gleixner | ec8f24b | 2019-05-19 13:07:45 +0100 | [diff] [blame] | 1 | # SPDX-License-Identifier: GPL-2.0-only |
H Hartley Sweeten | 1dd7863 | 2010-08-19 17:28:50 -0700 | [diff] [blame] | 2 | menuconfig MTD_UBI |
| 3 | tristate "Enable UBI - Unsorted block images" |
Artem B. Bityutskiy | 801c135 | 2006-06-27 12:22:22 +0400 | [diff] [blame] | 4 | select CRC32 |
| 5 | help |
Andrew F. Davis | 2fae131 | 2017-01-05 14:44:49 -0600 | [diff] [blame] | 6 | UBI is a software layer above MTD layer which admits use of LVM-like |
Artem B. Bityutskiy | 801c135 | 2006-06-27 12:22:22 +0400 | [diff] [blame] | 7 | logical volumes on top of MTD devices, hides some complexities of |
| 8 | flash chips like wear and bad blocks and provides some other useful |
| 9 | capabilities. Please, consult the MTD web site for more details |
| 10 | (www.linux-mtd.infradead.org). |
| 11 | |
H Hartley Sweeten | 1dd7863 | 2010-08-19 17:28:50 -0700 | [diff] [blame] | 12 | if MTD_UBI |
| 13 | |
Artem B. Bityutskiy | 801c135 | 2006-06-27 12:22:22 +0400 | [diff] [blame] | 14 | config MTD_UBI_WL_THRESHOLD |
| 15 | int "UBI wear-leveling threshold" |
| 16 | default 4096 |
| 17 | range 2 65536 |
Artem B. Bityutskiy | 801c135 | 2006-06-27 12:22:22 +0400 | [diff] [blame] | 18 | help |
| 19 | This parameter defines the maximum difference between the highest |
| 20 | erase counter value and the lowest erase counter value of eraseblocks |
| 21 | of UBI devices. When this threshold is exceeded, UBI starts performing |
| 22 | wear leveling by means of moving data from eraseblock with low erase |
Artem Bityutskiy | 6e0c84e | 2008-03-27 17:18:45 +0200 | [diff] [blame] | 23 | counter to eraseblocks with high erase counter. |
| 24 | |
| 25 | The default value should be OK for SLC NAND flashes, NOR flashes and |
| 26 | other flashes which have eraseblock life-cycle 100000 or more. |
| 27 | However, in case of MLC NAND flashes which typically have eraseblock |
Shinya Kuribayashi | 3f50262 | 2010-05-06 19:21:47 +0900 | [diff] [blame] | 28 | life-cycle less than 10000, the threshold should be lessened (e.g., |
Artem Bityutskiy | 6e0c84e | 2008-03-27 17:18:45 +0200 | [diff] [blame] | 29 | to 128 or 256, although it does not have to be power of 2). |
Artem B. Bityutskiy | 801c135 | 2006-06-27 12:22:22 +0400 | [diff] [blame] | 30 | |
Shmulik Ladkani | 8beeb3b | 2012-07-04 11:06:00 +0300 | [diff] [blame] | 31 | config MTD_UBI_BEB_LIMIT |
Richard Genoud | ba4087e | 2012-07-10 18:23:41 +0200 | [diff] [blame] | 32 | int "Maximum expected bad eraseblock count per 1024 eraseblocks" |
| 33 | default 20 |
| 34 | range 0 768 |
Shmulik Ladkani | 8beeb3b | 2012-07-04 11:06:00 +0300 | [diff] [blame] | 35 | help |
| 36 | This option specifies the maximum bad physical eraseblocks UBI |
Richard Genoud | ba4087e | 2012-07-10 18:23:41 +0200 | [diff] [blame] | 37 | expects on the MTD device (per 1024 eraseblocks). If the underlying |
| 38 | flash does not admit of bad eraseblocks (e.g. NOR flash), this value |
| 39 | is ignored. |
| 40 | |
| 41 | NAND datasheets often specify the minimum and maximum NVM (Number of |
| 42 | Valid Blocks) for the flashes' endurance lifetime. The maximum |
| 43 | expected bad eraseblocks per 1024 eraseblocks then can be calculated |
| 44 | as "1024 * (1 - MinNVB / MaxNVB)", which gives 20 for most NANDs |
| 45 | (MaxNVB is basically the total count of eraseblocks on the chip). |
| 46 | |
| 47 | To put it differently, if this value is 20, UBI will try to reserve |
| 48 | about 1.9% of physical eraseblocks for bad blocks handling. And that |
| 49 | will be 1.9% of eraseblocks on the entire NAND chip, not just the MTD |
| 50 | partition UBI attaches. This means that if you have, say, a NAND |
| 51 | flash chip admits maximum 40 bad eraseblocks, and it is split on two |
| 52 | MTD partitions of the same size, UBI will reserve 40 eraseblocks when |
| 53 | attaching a partition. |
| 54 | |
Richard Genoud | db7e21c | 2012-08-20 18:00:15 +0200 | [diff] [blame] | 55 | This option can be overridden by the "mtd=" UBI module parameter or |
| 56 | by the "attach" ioctl. |
Richard Genoud | edac493 | 2012-08-20 18:00:14 +0200 | [diff] [blame] | 57 | |
Shmulik Ladkani | 8beeb3b | 2012-07-04 11:06:00 +0300 | [diff] [blame] | 58 | Leave the default value if unsure. |
Artem B. Bityutskiy | 801c135 | 2006-06-27 12:22:22 +0400 | [diff] [blame] | 59 | |
Richard Weinberger | 76ac66e | 2012-09-26 17:51:50 +0200 | [diff] [blame] | 60 | config MTD_UBI_FASTMAP |
| 61 | bool "UBI Fastmap (Experimental feature)" |
| 62 | default n |
| 63 | help |
| 64 | Important: this feature is experimental so far and the on-flash |
| 65 | format for fastmap may change in the next kernel versions |
| 66 | |
| 67 | Fastmap is a mechanism which allows attaching an UBI device |
| 68 | in nearly constant time. Instead of scanning the whole MTD device it |
| 69 | only has to locate a checkpoint (called fastmap) on the device. |
| 70 | The on-flash fastmap contains all information needed to attach |
| 71 | the device. Using fastmap makes only sense on large devices where |
| 72 | attaching by scanning takes long. UBI will not automatically install |
| 73 | a fastmap on old images, but you can set the UBI module parameter |
| 74 | fm_autoconvert to 1 if you want so. Please note that fastmap-enabled |
| 75 | images are still usable with UBI implementations without |
| 76 | fastmap support. On typical flash devices the whole fastmap fits |
| 77 | into one PEB. UBI will reserve PEBs to hold two fastmaps. |
| 78 | |
| 79 | If in doubt, say "N". |
| 80 | |
Artem B. Bityutskiy | 801c135 | 2006-06-27 12:22:22 +0400 | [diff] [blame] | 81 | config MTD_UBI_GLUEBI |
Dmitry Pervushin | 2ba3d76 | 2009-05-31 18:32:59 +0400 | [diff] [blame] | 82 | tristate "MTD devices emulation driver (gluebi)" |
Artem B. Bityutskiy | 801c135 | 2006-06-27 12:22:22 +0400 | [diff] [blame] | 83 | help |
Dmitry Pervushin | 2ba3d76 | 2009-05-31 18:32:59 +0400 | [diff] [blame] | 84 | This option enables gluebi - an additional driver which emulates MTD |
| 85 | devices on top of UBI volumes: for each UBI volumes an MTD device is |
| 86 | created, and all I/O to this MTD device is redirected to the UBI |
| 87 | volume. This is handy to make MTD-oriented software (like JFFS2) |
| 88 | work on top of UBI. Do not enable this unless you use legacy |
| 89 | software. |
Artem B. Bityutskiy | 801c135 | 2006-06-27 12:22:22 +0400 | [diff] [blame] | 90 | |
Ezequiel Garcia | 9d54c8a | 2014-02-25 13:25:22 -0300 | [diff] [blame] | 91 | config MTD_UBI_BLOCK |
| 92 | bool "Read-only block devices on top of UBI volumes" |
| 93 | default n |
Ezequiel Garcia | 22d3ee5 | 2014-03-03 13:42:40 -0300 | [diff] [blame] | 94 | depends on BLOCK |
Ezequiel Garcia | 9d54c8a | 2014-02-25 13:25:22 -0300 | [diff] [blame] | 95 | help |
| 96 | This option enables read-only UBI block devices support. UBI block |
| 97 | devices will be layered on top of UBI volumes, which means that the |
| 98 | UBI driver will transparently handle things like bad eraseblocks and |
| 99 | bit-flips. You can put any block-oriented file system on top of UBI |
| 100 | volumes in read-only mode (e.g., ext4), but it is probably most |
| 101 | practical for read-only file systems, like squashfs. |
| 102 | |
| 103 | When selected, this feature will be built in the UBI driver. |
| 104 | |
| 105 | If in doubt, say "N". |
| 106 | |
H Hartley Sweeten | 1dd7863 | 2010-08-19 17:28:50 -0700 | [diff] [blame] | 107 | endif # MTD_UBI |