mirror of
				https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
				synced 2025-10-27 08:54:07 +10:00 
			
		
		
		
	Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
		
			
				
	
	
		
			108 lines
		
	
	
		
			4.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			108 lines
		
	
	
		
			4.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| # 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
 |