#
# For a description of the syntax of this configuration file,
# see kconfig-language at https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt
#


comment "MTD Configuration"

menuconfig MTD
	bool "Memory Technology Device (MTD) Support"
	default y
	---help---
		Memory Technology Device (MTD) drivers.  Some simple drivers for
		memory technologies like FLASH, EEPROM, NVRAM, etc.  See
		include/tinyara/fs/mtd.h

		(Note: This is a simple memory interface and should not be
		confused with the "real" MTD developed at infradead.org.  This
		logic is unrelated; I just used the name MTD because I am not
		aware of any other common way to refer to this class of devices).

if MTD
config MTD_PARTITION
	bool "Support MTD partitions"
	default n
	---help---
		MTD partitions are build as MTD drivers that manage a sub-region
		of the FLASH memory.  The contain the original FLASH MTD driver and
		simply manage all accesses to assure that (1) FLASH accesses are
		always offset to the beginning of the partition, and (2) that FLASH
		accesses do not extend outside of the partition.

		A FLASH device may be broken up into several partitions managed,
		each managed by a separate MTD driver.  The MTD partition interface
		is described in:

			os/include/tinyara/fs/mtd.h
			FAR struct mtd_dev_s *mtd_partition(FAR struct mtd_dev_s *mtd,
						off_t firstblock, off_t nblocks, uint16_t tagno);

		Each call to mtd_partition() will create a new MTD driver instance
		managing the sub-region of flash beginning at 'offset' (in blocks)
		and of size 'nblocks' on the device specified by 'mtd'.

config MTD_PARTITION_NAMES
	bool "Support MTD partition naming"
	depends on FS_PROCFS
	depends on MTD_PARTITION
	default n
	---help---
		MTD partitions can be assigned a name for reporting via the procfs
		file system interface.  This adds an API which must be called to
		specify the partition name.

config MTD_PROGMEM
	bool "Enable on-chip program FLASH MTD device"
	default n
	---help---
		Enable to support an MTD device that supports the on-chip
		FLASH using the interfaces defined in include/tinyara/progmem.
		Those interfaces must be exported by chip-specific logic.

config MTD_FTL
	bool "Enable MTD ftl layer"
	default n
	---help---
		Enable to support a MTD FTL layer.

if MTD_FTL

menu "MTD_FTL Configurations"

config FTL_WRITEBUFFER
	bool "Enable write buffering in the FTL layer"
	default n
	depends on DRVR_WRITEBUFFER

config FTL_READAHEAD
	bool "Enable read-ahead buffering in the FTL layer"
	default n
	depends on DRVR_READAHEAD

endmenu
endif

config MTD_CONFIG
	bool "Enable Dev Config (MTD based) device"
	default n
	---help---
		Provides a /dev/config device for saving / restoring application
		configuration data to a standard MTD device or partition.

if MTD_CONFIG

menu "MTD Configurations"

config MTD_CONFIG_RAM_CONSOLIDATE
	bool "Always use RAM consolidation method (work in progress)"
	default n
	---help---
		When the MTD device used for /dev/config contains more than one
		erase block, the "unused entry" consolidation reserves one erase
		block by default for cleanup purposes.  This consumes the minimum
		amount of RAM, however it "wastes" one erase block on the device.
		(For configurations that have only a single erase block assigned
		to the config device, RAM consolidation is the ONLY option.)

		Another approach is to allow the driver to use the entire MTD
		device (or partition) to save config data, and then allocate a
		RAM buffer (the size of one erase block) to perform the
		consolidation.  Enabling this feature basically trades off RAM
		usage for FLASH usage.  If the MTD device used for config data
		has small erase sizes (4K, etc.) and there is plenty of free RAM
		available, then this is probably a good option.

		Another benefit of this option is it reduces code space a bit
		since the "reserved block" consolidate routine is not needed.

config MTD_CONFIG_ERASEDVALUE
	hex "Erased value of bytes on the MTD device"
	default 0xff
	---help---
		Specifies the value of the erased state of the MTD FLASH.  For
		most FLASH parts, this is 0xff, but could also be zero depending
		on the device.

endmenu
endif # MTD_CONFIG


config MTD_BYTE_WRITE
	bool "Byte write"
	default y
	---help---
		Some devices (such as the EON EN25F80) support writing an arbitrary
		number of bytes to FLASH. This setting enables MTD interfaces to
		support such writes.  The SMART file system can take advantage of
		this option if it is enabled.

comment "MTD Device Drivers"

config MTD_M25P
        bool "SPI-based M25P FLASH"
        default n
        select SPI
        ---help---
                Build support for M25PX family of flash.

if MTD_M25P
source fs/driver/mtd/m25px/Kconfig
endif

config RAMMTD
       bool "RAM-based MTD driver"
       default n
       ---help---
               Build support for a RAM-based MTD driver.

if RAMMTD
source fs/driver/mtd/rammtd/Kconfig
endif

config MTD_SMART
	bool "Sector Mapped Allocation for Really Tiny (SMART) Flash support"
	default y
	---help---
		The MP25x series of Flash devices are typically very small and have a very large
		erase block size.  This causes issues with the standard Flash Translation Layer
		block driver since it tries to allocate a RAM block the size of a flash erase
		block, which is typically 64K.  This block driver uses a different approach
		to sacrifice performance for RAM memory footprint by saving data in sectors
		(typically 2K - 4K based on memory size) and relocating sectors as needed when
		an erase block needs to be erased.

if MTD_SMART

menu "SMART Device options"

config MTD_SMART_SECTOR_SIZE
	int "SMART Device sector size"
	default 1024
	---help---
		Sets the size of a single allocation on the SMART device.  Larger sector sizes
		reduce overhead per sector, but cause more wasted space with a lot of smaller
		files.

config MTD_SMART_WEAR_LEVEL
	bool "Support FLASH wear leveling"
	depends on MTD_SMART
	default y
	---help---
		Adds extra logic and RAM to guarantee equal wear leveling of the FLASH
		device by recording and monitoring erase block operations and selecting
		sector allocations to ensure all erase blocks are worn evenly.  This will
		evenly wear both dynamic and static data on the device.

config MTD_SMART_ENABLE_CRC
	bool "Enable Sector CRC error detection"
	depends on MTD_SMART
	default n
	---help---
		Enables logic to compute and validate a CRC for logical sectors.  The
		CRC is calculated for all bytes in the logical sector.  The CRC size is
		selectable (8-bit, 16-bit, 32-bit).  For added protection, larger CRCs should
		be used with larger (2K - 4K) sector sizes.  Enabling CRC protection will
		cause increased sector relocation and increased erase block erasures since
		directory and wear-level status updates can no longer be performed in-place
		and mandate re-writing the information to a new sector.

		An 8-bit CRC protection scheme can be added to an existing non-CRC formatted
		SMART volume without needing to reformat the drive.  As sectors are re-written
		or relocated, they will be converted to CRC protected sectors.

choice
	prompt "CRC level selection"
	depends on MTD_SMART_ENABLE_CRC
	default SMART_CRC_8
	---help---
		Select the level of CRC protection implemented in the SMART MTD layer.
		Smaller CRC selection uses less overhead per logical sectors, but also has
		a higher probability of not detecting multiple bit errors.  Devices with
		larger logical sector sizes should use a larger CRC.

config SMART_CRC_8
	bool "CRC-8"

config SMART_CRC_16
	bool "CRC-16"

endchoice

config MTD_SMART_SECTOR_ERASE_DEBUG
	bool "Track Erase Block erasure counts"
	depends on MTD_SMART
	default n
	---help---
		Allocates an Erase Block erase count array and keeps track of the number
		of erases per erase block.  This data is then presented on the procfs
		interface.

config MTD_SMART_ALLOC_DEBUG
	bool "RAM Allocation Debug"
	depends on MTD_SMART
	default n
	---help---
		Records all SMART MTD layer allocations for debug purposes and makes them
		accessible from the ProcFS interface if it is enabled.

endmenu

endif # MTD_SMART
endif # MTD
