Kconfig 4.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107
  1. # SPDX-License-Identifier: GPL-2.0-only
  2. menuconfig MTD_UBI
  3. tristate "Enable UBI - Unsorted block images"
  4. select CRC32
  5. help
  6. UBI is a software layer above MTD layer which admits use of LVM-like
  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. if MTD_UBI
  12. config MTD_UBI_WL_THRESHOLD
  13. int "UBI wear-leveling threshold"
  14. default 4096
  15. range 2 65536
  16. help
  17. This parameter defines the maximum difference between the highest
  18. erase counter value and the lowest erase counter value of eraseblocks
  19. of UBI devices. When this threshold is exceeded, UBI starts performing
  20. wear leveling by means of moving data from eraseblock with low erase
  21. counter to eraseblocks with high erase counter.
  22. The default value should be OK for SLC NAND flashes, NOR flashes and
  23. other flashes which have eraseblock life-cycle 100000 or more.
  24. However, in case of MLC NAND flashes which typically have eraseblock
  25. life-cycle less than 10000, the threshold should be lessened (e.g.,
  26. to 128 or 256, although it does not have to be power of 2).
  27. config MTD_UBI_BEB_LIMIT
  28. int "Maximum expected bad eraseblock count per 1024 eraseblocks"
  29. default 20
  30. range 0 768
  31. help
  32. This option specifies the maximum bad physical eraseblocks UBI
  33. expects on the MTD device (per 1024 eraseblocks). If the underlying
  34. flash does not admit of bad eraseblocks (e.g. NOR flash), this value
  35. is ignored.
  36. NAND datasheets often specify the minimum and maximum NVM (Number of
  37. Valid Blocks) for the flashes' endurance lifetime. The maximum
  38. expected bad eraseblocks per 1024 eraseblocks then can be calculated
  39. as "1024 * (1 - MinNVB / MaxNVB)", which gives 20 for most NANDs
  40. (MaxNVB is basically the total count of eraseblocks on the chip).
  41. To put it differently, if this value is 20, UBI will try to reserve
  42. about 1.9% of physical eraseblocks for bad blocks handling. And that
  43. will be 1.9% of eraseblocks on the entire NAND chip, not just the MTD
  44. partition UBI attaches. This means that if you have, say, a NAND
  45. flash chip admits maximum 40 bad eraseblocks, and it is split on two
  46. MTD partitions of the same size, UBI will reserve 40 eraseblocks when
  47. attaching a partition.
  48. This option can be overridden by the "mtd=" UBI module parameter or
  49. by the "attach" ioctl.
  50. Leave the default value if unsure.
  51. config MTD_UBI_FASTMAP
  52. bool "UBI Fastmap (Experimental feature)"
  53. default n
  54. help
  55. Important: this feature is experimental so far and the on-flash
  56. format for fastmap may change in the next kernel versions
  57. Fastmap is a mechanism which allows attaching an UBI device
  58. in nearly constant time. Instead of scanning the whole MTD device it
  59. only has to locate a checkpoint (called fastmap) on the device.
  60. The on-flash fastmap contains all information needed to attach
  61. the device. Using fastmap makes only sense on large devices where
  62. attaching by scanning takes long. UBI will not automatically install
  63. a fastmap on old images, but you can set the UBI module parameter
  64. fm_autoconvert to 1 if you want so. Please note that fastmap-enabled
  65. images are still usable with UBI implementations without
  66. fastmap support. On typical flash devices the whole fastmap fits
  67. into one PEB. UBI will reserve PEBs to hold two fastmaps.
  68. If in doubt, say "N".
  69. config MTD_UBI_GLUEBI
  70. tristate "MTD devices emulation driver (gluebi)"
  71. help
  72. This option enables gluebi - an additional driver which emulates MTD
  73. devices on top of UBI volumes: for each UBI volumes an MTD device is
  74. created, and all I/O to this MTD device is redirected to the UBI
  75. volume. This is handy to make MTD-oriented software (like JFFS2)
  76. work on top of UBI. Do not enable this unless you use legacy
  77. software.
  78. config MTD_UBI_BLOCK
  79. bool "Read-only block devices on top of UBI volumes"
  80. default n
  81. depends on BLOCK
  82. help
  83. This option enables read-only UBI block devices support. UBI block
  84. devices will be layered on top of UBI volumes, which means that the
  85. UBI driver will transparently handle things like bad eraseblocks and
  86. bit-flips. You can put any block-oriented file system on top of UBI
  87. volumes in read-only mode (e.g., ext4), but it is probably most
  88. practical for read-only file systems, like squashfs.
  89. When selected, this feature will be built in the UBI driver.
  90. If in doubt, say "N".
  91. endif # MTD_UBI