# # 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