2012-04-06 17:49:35 +02:00
|
|
|
#
|
|
|
|
# For a description of the syntax of this configuration file,
|
2015-06-28 16:08:57 +02:00
|
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
2012-04-06 17:49:35 +02:00
|
|
|
#
|
2012-04-11 01:01:40 +02:00
|
|
|
|
|
|
|
config FS_NXFFS
|
|
|
|
bool "NXFFS file system"
|
|
|
|
default n
|
2012-04-11 01:49:13 +02:00
|
|
|
depends on !DISABLE_MOUNTPOINT
|
2012-04-11 01:01:40 +02:00
|
|
|
---help---
|
|
|
|
Enable NuttX FLASH file system (NXFF) support.
|
|
|
|
|
2012-04-11 01:49:13 +02:00
|
|
|
if FS_NXFFS
|
2013-04-30 23:54:02 +02:00
|
|
|
|
2013-12-03 00:19:22 +01:00
|
|
|
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
|
2016-06-02 18:44:13 +02:00
|
|
|
reboot in these cases. That can be done with MDIOC_BULKERASE
|
|
|
|
IOCTL command.
|
2013-12-03 00:19:22 +01:00
|
|
|
|
2013-12-03 20:11:11 +01:00
|
|
|
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
|
2023-05-09 15:12:42 +02:00
|
|
|
bits to change them from the erased to the non-erased state. This
|
2013-12-03 20:11:11 +01:00
|
|
|
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.
|
|
|
|
|
2013-12-03 00:19:22 +01:00
|
|
|
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.
|
|
|
|
|
2013-04-30 23:54:02 +02:00
|
|
|
config NXFFS_PREALLOCATED
|
|
|
|
bool "Single, preallocated volume"
|
2013-09-12 17:42:34 +02:00
|
|
|
default y
|
2013-04-30 23:54:02 +02:00
|
|
|
---help---
|
|
|
|
If CONFIG_NXFSS_PREALLOCATED is defined, then this is the single, pre-
|
2013-09-12 17:42:34 +02:00
|
|
|
allocated NXFFS volume instance. Currently required because full,
|
2018-07-09 02:24:45 +02:00
|
|
|
dynamic allocation of NXFFS volumes in not yet supported.
|
2013-04-30 23:54:02 +02:00
|
|
|
|
2012-04-11 01:01:40 +02:00
|
|
|
config NXFFS_ERASEDSTATE
|
2012-10-04 20:42:28 +02:00
|
|
|
hex "FLASH erased state"
|
|
|
|
default 0xff
|
2013-09-12 17:42:34 +02:00
|
|
|
---help---
|
2014-04-14 00:22:22 +02:00
|
|
|
The erased state of FLASH.
|
2012-04-11 01:01:40 +02:00
|
|
|
This must have one of the values of 0xff or 0x00.
|
|
|
|
Default: 0xff.
|
|
|
|
|
|
|
|
config NXFFS_PACKTHRESHOLD
|
2012-10-04 20:42:28 +02:00
|
|
|
int "Re-packing threshold"
|
|
|
|
default 32
|
2012-04-11 01:01:40 +02:00
|
|
|
---help---
|
|
|
|
When packing flash file data,
|
|
|
|
don't both with file chunks smaller than this number of data bytes.
|
|
|
|
Default: 32.
|
|
|
|
|
|
|
|
config NXFFS_MAXNAMLEN
|
2012-10-04 20:42:28 +02:00
|
|
|
int "Maximum file name length"
|
|
|
|
default 255
|
2013-09-12 17:42:34 +02:00
|
|
|
---help---
|
2012-04-11 01:01:40 +02:00
|
|
|
The maximum size of an NXFFS file name.
|
|
|
|
Default: 255.
|
|
|
|
|
|
|
|
config NXFFS_TAILTHRESHOLD
|
2012-10-04 20:42:28 +02:00
|
|
|
int "Tail threshold"
|
|
|
|
default 8192
|
2013-09-12 17:42:34 +02:00
|
|
|
---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.
|
2012-04-11 01:01:40 +02:00
|
|
|
|
2012-04-11 01:49:13 +02:00
|
|
|
endif
|