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