| # SPDX-License-Identifier: GPL-2.0-only |
| menuconfig MTD_UBI |
| tristate "Enable UBI - Unsorted block images" |
| select CRC32 |
| help |
| UBI is a software layer above MTD layer which admits use of LVM-like |
| logical volumes on top of MTD devices, hides some complexities of |
| flash chips like wear and bad blocks and provides some other useful |
| capabilities. Please, consult the MTD web site for more details |
| (www.linux-mtd.infradead.org). |
| |
| if MTD_UBI |
| |
| config MTD_UBI_WL_THRESHOLD |
| int "UBI wear-leveling threshold" |
| default 4096 |
| range 2 65536 |
| help |
| This parameter defines the maximum difference between the highest |
| erase counter value and the lowest erase counter value of eraseblocks |
| of UBI devices. When this threshold is exceeded, UBI starts performing |
| wear leveling by means of moving data from eraseblock with low erase |
| counter to eraseblocks with high erase counter. |
| |
| The default value should be OK for SLC NAND flashes, NOR flashes and |
| other flashes which have eraseblock life-cycle 100000 or more. |
| However, in case of MLC NAND flashes which typically have eraseblock |
| life-cycle less than 10000, the threshold should be lessened (e.g., |
| to 128 or 256, although it does not have to be power of 2). |
| |
| config MTD_UBI_BEB_LIMIT |
| int "Maximum expected bad eraseblock count per 1024 eraseblocks" |
| default 20 |
| range 0 768 |
| help |
| This option specifies the maximum bad physical eraseblocks UBI |
| expects on the MTD device (per 1024 eraseblocks). If the underlying |
| flash does not admit of bad eraseblocks (e.g. NOR flash), this value |
| is ignored. |
| |
| NAND datasheets often specify the minimum and maximum NVM (Number of |
| Valid Blocks) for the flashes' endurance lifetime. The maximum |
| expected bad eraseblocks per 1024 eraseblocks then can be calculated |
| as "1024 * (1 - MinNVB / MaxNVB)", which gives 20 for most NANDs |
| (MaxNVB is basically the total count of eraseblocks on the chip). |
| |
| To put it differently, if this value is 20, UBI will try to reserve |
| about 1.9% of physical eraseblocks for bad blocks handling. And that |
| will be 1.9% of eraseblocks on the entire NAND chip, not just the MTD |
| partition UBI attaches. This means that if you have, say, a NAND |
| flash chip admits maximum 40 bad eraseblocks, and it is split on two |
| MTD partitions of the same size, UBI will reserve 40 eraseblocks when |
| attaching a partition. |
| |
| This option can be overridden by the "mtd=" UBI module parameter or |
| by the "attach" ioctl. |
| |
| Leave the default value if unsure. |
| |
| config MTD_UBI_FASTMAP |
| bool "UBI Fastmap (Experimental feature)" |
| default n |
| help |
| Important: this feature is experimental so far and the on-flash |
| format for fastmap may change in the next kernel versions |
| |
| Fastmap is a mechanism which allows attaching an UBI device |
| in nearly constant time. Instead of scanning the whole MTD device it |
| only has to locate a checkpoint (called fastmap) on the device. |
| The on-flash fastmap contains all information needed to attach |
| the device. Using fastmap makes only sense on large devices where |
| attaching by scanning takes long. UBI will not automatically install |
| a fastmap on old images, but you can set the UBI module parameter |
| fm_autoconvert to 1 if you want so. Please note that fastmap-enabled |
| images are still usable with UBI implementations without |
| fastmap support. On typical flash devices the whole fastmap fits |
| into one PEB. UBI will reserve PEBs to hold two fastmaps. |
| |
| If in doubt, say "N". |
| |
| config MTD_UBI_GLUEBI |
| tristate "MTD devices emulation driver (gluebi)" |
| help |
| This option enables gluebi - an additional driver which emulates MTD |
| devices on top of UBI volumes: for each UBI volumes an MTD device is |
| created, and all I/O to this MTD device is redirected to the UBI |
| volume. This is handy to make MTD-oriented software (like JFFS2) |
| work on top of UBI. Do not enable this unless you use legacy |
| software. |
| |
| config MTD_UBI_BLOCK |
| bool "Read-only block devices on top of UBI volumes" |
| default n |
| depends on BLOCK |
| help |
| This option enables read-only UBI block devices support. UBI block |
| devices will be layered on top of UBI volumes, which means that the |
| UBI driver will transparently handle things like bad eraseblocks and |
| bit-flips. You can put any block-oriented file system on top of UBI |
| volumes in read-only mode (e.g., ext4), but it is probably most |
| practical for read-only file systems, like squashfs. |
| |
| When selected, this feature will be built in the UBI driver. |
| |
| If in doubt, say "N". |
| |
| config MTD_UBI_FAULT_INJECTION |
| bool "Fault injection capability of UBI device" |
| default n |
| depends on FAULT_INJECTION_DEBUG_FS |
| help |
| This option enables fault-injection support for UBI devices for |
| testing purposes. |
| |
| If in doubt, say "N". |
| |
| config MTD_UBI_NVMEM |
| tristate "UBI virtual NVMEM" |
| default n |
| depends on NVMEM |
| help |
| This option enabled an additional driver exposing UBI volumes as NVMEM |
| providers, intended for platforms where UBI is part of the firmware |
| specification and used to store also e.g. MAC addresses or board- |
| specific Wi-Fi calibration data. |
| |
| If in doubt, say "N". |
| |
| endif # MTD_UBI |
