]>
Commit | Line | Data |
---|---|---|
ec8f24b7 | 1 | # SPDX-License-Identifier: GPL-2.0-only |
1dd78632 HS |
2 | menuconfig MTD_UBI |
3 | tristate "Enable UBI - Unsorted block images" | |
801c135c AB |
4 | select CRC32 |
5 | help | |
2fae1312 | 6 | UBI is a software layer above MTD layer which admits use of LVM-like |
801c135c AB |
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 | ||
1dd78632 HS |
12 | if MTD_UBI |
13 | ||
801c135c AB |
14 | config MTD_UBI_WL_THRESHOLD |
15 | int "UBI wear-leveling threshold" | |
16 | default 4096 | |
17 | range 2 65536 | |
801c135c AB |
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 | |
6e0c84e3 AB |
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 | |
3f502622 | 28 | life-cycle less than 10000, the threshold should be lessened (e.g., |
6e0c84e3 | 29 | to 128 or 256, although it does not have to be power of 2). |
801c135c | 30 | |
8beeb3bb | 31 | config MTD_UBI_BEB_LIMIT |
ba4087e9 RG |
32 | int "Maximum expected bad eraseblock count per 1024 eraseblocks" |
33 | default 20 | |
34 | range 0 768 | |
8beeb3bb SL |
35 | help |
36 | This option specifies the maximum bad physical eraseblocks UBI | |
ba4087e9 RG |
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 | ||
db7e21c2 RG |
55 | This option can be overridden by the "mtd=" UBI module parameter or |
56 | by the "attach" ioctl. | |
edac493d | 57 | |
8beeb3bb | 58 | Leave the default value if unsure. |
801c135c | 59 | |
76ac66e4 RW |
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 | ||
801c135c | 81 | config MTD_UBI_GLUEBI |
2ba3d76a | 82 | tristate "MTD devices emulation driver (gluebi)" |
801c135c | 83 | help |
2ba3d76a DP |
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. | |
801c135c | 90 | |
9d54c8a3 EG |
91 | config MTD_UBI_BLOCK |
92 | bool "Read-only block devices on top of UBI volumes" | |
93 | default n | |
22d3ee5c | 94 | depends on BLOCK |
9d54c8a3 EG |
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 | ||
1dd78632 | 107 | endif # MTD_UBI |