incubator-nuttx/fs/nxffs/Kconfig

#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#

config FS_NXFFS
	bool "NXFFS file system"
	default n
	depends on !DISABLE_MOUNTPOINT
	select FS_READABLE
	select FS_WRITABLE
	---help---
		Enable NuttX FLASH file system (NXFF) support.

if FS_NXFFS

config NXFFS_SCAN_VOLUME
	bool "Scan volume"
	default n
	---help---
		Scan the media for bad blocks on start-up.  If too many bad or
		unformatted blocks are found, then re-format the volume.  Otherwise,
		the volume will be reformatted only if no NXFFS file system is
		found.

		Why might you want to do this?  If too many bad blocks accumulate
		over time, then attempting to reformat my be the only way to
		recover.  And what if you power down the device while formatting
		the FLASH so that you have only a partially formatted device?
		Scanning the volume can get you out of these situations.

		The down side is that scanning the volume can adversely affect
		your start-up time.  An option is to just erase the FLASH and
		reboot in these cases.  That can be done with MDIOC_BULKERASE
		IOCTL command.

config NXFFS_NAND
	bool "Enable NAND support"
	default n
	depends on EXPERIMENTAL
	---help---
		NAND differs from other other FLASH types several ways.  For one
		thing, NAND requires error correction (ECC) bytes that must be set
		in order to work around bit failures.  This affects NXFFS in two
		ways:

		First, write failures are not fatal. Rather, they should be tried by
		bad blocks and simply ignored.  This is because unrecoverable bit
		failures will cause read failures when reading from NAND.  Setting
		this option will enable this behavior.

		Secondly, NXFFS will write a block many times.  It tries to keep
		bits in the erased state and assumes that it can overwrite those
 		bits to change them from the erased to the non-erased state.  This
		works will with NOR-like FLASH.  NAND behaves this way too.  But the
		problem with NAND is that the ECC bits cannot be re-written in this
		way.  So once a block has been written, it cannot be modified.  This
		behavior has NOT been fixed in NXFFS.  Currently, NXFFS will attempt
		to re-write the ECC bits causing the ECC to become corrupted because
		the ECC bits cannot be overwritten without erasing the entire block.

		This may prohibit NXFFS from ever being used with NAND.

config NXFFS_REFORMAT_THRESH
	int "Reformat percentage"
	default 20
	range 0 100
	depends on NXFFS_SCAN_VOLUME
	---help---
		This defines the threshold for re-formatting.  Is less than this
		percentage of good blocks are found, then the volume is re-
		formatted.

config NXFFS_PREALLOCATED
	bool "Single, preallocated volume"
	default y
	---help---
		If CONFIG_NXFSS_PREALLOCATED is defined, then this is the single, pre-
		allocated NXFFS volume instance.  Currently required because full,
		dynamic allocation of NXFFS volumes in not yet supporte.

config NXFFS_ERASEDSTATE
	hex "FLASH erased state"
	default 0xff
	---help---
		The erased state of FLASH.
		This must have one of the values of 0xff or 0x00.
		Default: 0xff.

config NXFFS_PACKTHRESHOLD
	int "Re-packing threshold"
	default 32
	---help---
		When packing flash file data,
		don't both with file chunks smaller than this number of data bytes.
		Default: 32.

config NXFFS_MAXNAMLEN
	int "Maximum file name length"
	default 255
	---help---
		The maximum size of an NXFFS file name.
		Default: 255.

config NXFFS_TAILTHRESHOLD
	int "Tail threshold"
	default 8192
	---help---
		Clean-up can either mean packing files together toward the end of
		the file or, if files are deleted at the end of the file, clean up
		can simply mean erasing the end of FLASH memory so that it can be
		re-used again.  However, doing this can also harm the life of the
		FLASH part because it can mean that the tail end of the FLASH is
		re-used too often. This threshold determines if/when it is worth
		erased the tail end of FLASH and making it available for re-use
		(and possible over-wear). Default: 8192.

endif