forked from Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
107 lines
4.5 KiB
107 lines
4.5 KiB
# 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". |
|
|
|
endif # MTD_UBI
|
|
|