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_FAT
|
|
|
|
bool "FAT 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 FAT filesystem support
|
|
|
|
|
2012-04-11 01:49:13 +02:00
|
|
|
if FS_FAT
|
2016-02-22 23:26:04 +01:00
|
|
|
|
2021-07-04 14:20:45 +02:00
|
|
|
config FAT_COMPUTE_FSINFO
|
|
|
|
bool "FAT compute free space in FSINFO at mount time"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Enables the computation of free clusters at mount time as suggested by the
|
2021-07-04 17:31:21 +02:00
|
|
|
white paper for FAT. The standard behavior of NuttX is to trust the stored
|
2021-07-04 14:20:45 +02:00
|
|
|
value and only recompute it once required. This works if the file system
|
|
|
|
is never mounted to another OS. SD-cards which are mounted to Windows to
|
2021-07-04 17:31:21 +02:00
|
|
|
modify the content might report wrong space after reinserting it to NuttX.
|
2021-07-04 14:20:45 +02:00
|
|
|
It is recommended to activate this setting if the "SD-Card" is swapped
|
|
|
|
between systems.
|
|
|
|
|
2012-04-11 01:01:40 +02:00
|
|
|
config FAT_LCNAMES
|
|
|
|
bool "FAT upper/lower names"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Enable use of the NT-style upper/lower case 8.3
|
|
|
|
file name support.
|
|
|
|
|
|
|
|
config FAT_LFN
|
|
|
|
bool "FAT long file names"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Enable FAT long file names. NOTE: Microsoft claims
|
|
|
|
patents on FAT long file name technology. Please read the
|
2021-04-01 17:16:03 +02:00
|
|
|
disclaimer in the top-level NOTICE file and only enable this
|
2012-04-11 01:01:40 +02:00
|
|
|
feature if you understand these issues.
|
|
|
|
|
|
|
|
config FAT_MAXFNAME
|
|
|
|
int "FAT maximum file name size"
|
|
|
|
depends on FAT_LFN
|
2022-03-07 18:41:02 +01:00
|
|
|
default NAME_MAX
|
2017-12-18 00:43:20 +01:00
|
|
|
range 12 255
|
2012-04-11 01:01:40 +02:00
|
|
|
---help---
|
2013-04-25 23:52:00 +02:00
|
|
|
If FAT_LFN is defined, then the default, maximum long file
|
2012-04-12 23:52:04 +02:00
|
|
|
name is 255 bytes. This can eat up a lot of memory (especially stack
|
|
|
|
space). If you are willing to live with some non-standard, short long
|
|
|
|
file names, then define this value to be something more reasonable. A
|
|
|
|
good choice would be the same value as selected for NAME_MAX which will
|
|
|
|
limit the visibility of longer file names anyway.
|
2012-04-11 01:01:40 +02:00
|
|
|
|
2017-12-15 13:19:14 +01:00
|
|
|
This setting may not exceed NAME_MAX. That will be verified at compile
|
2017-12-18 00:43:20 +01:00
|
|
|
time. The minimum values is 12 due to assumptions in internal logic.
|
2017-12-15 13:19:14 +01:00
|
|
|
|
2018-11-09 14:46:16 +01:00
|
|
|
config FAT_LFN_ALIAS_HASH
|
2019-10-06 05:39:12 +02:00
|
|
|
bool "Use faster method for forming long filename 8.3 alias"
|
|
|
|
depends on FAT_LFN
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Long filenames on FAT filesystems have associated 8.3 character alias
|
|
|
|
short filenames. The traditional form of these is FILENA~1.EXT with
|
|
|
|
a running count of the number of similar names. However creating this
|
|
|
|
unique count can take several seconds if there are many similarly named
|
|
|
|
files in the directory. Enabling FAT_LFN_ALIAS_HASH uses an alternative
|
|
|
|
format of FI0123~1.TXT where the four digits are a hash of the original
|
|
|
|
filename. This method is similar to what is used by Windows 2000 and
|
|
|
|
later.
|
2018-11-09 14:46:16 +01:00
|
|
|
|
2020-07-26 12:52:22 +02:00
|
|
|
config FAT_LFN_UTF8
|
|
|
|
bool "Allow UTF8 long filenames"
|
|
|
|
depends on FAT_LFN
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
UTF8 long filenames are accepted and converted to UCS2.
|
|
|
|
|
2018-11-09 14:46:16 +01:00
|
|
|
config FAT_LFN_ALIAS_TRAILCHARS
|
2019-10-06 05:39:12 +02:00
|
|
|
int "Number of trailing characters to use for 8.3 alias"
|
|
|
|
depends on FAT_LFN
|
|
|
|
default 0
|
|
|
|
---help---
|
|
|
|
Traditional format for long filename 8.3 aliases takes first 6
|
|
|
|
characters of long filename. If this option is set to N > 0,
|
|
|
|
NuttX will instead take first 6-N and last N characters to form
|
|
|
|
the short name. This is useful for filenames like "datafile12.txt"
|
|
|
|
where the first characters would always remain the same.
|
2018-11-09 14:46:16 +01:00
|
|
|
|
2012-04-11 01:01:40 +02:00
|
|
|
config FS_FATTIME
|
|
|
|
bool "FAT timestamps"
|
|
|
|
default n
|
2012-09-11 15:53:44 +02:00
|
|
|
---help---
|
2012-04-11 01:01:40 +02:00
|
|
|
Support FAT date and time. NOTE: There is not
|
|
|
|
much sense in supporting FAT date and time unless you have a
|
|
|
|
hardware RTC or other way to get the time and date.
|
|
|
|
|
2016-02-22 23:26:04 +01:00
|
|
|
config FAT_FORCE_INDIRECT
|
2016-02-23 01:25:58 +01:00
|
|
|
bool "Force direct transfers"
|
|
|
|
default n
|
|
|
|
---help---
|
2016-02-22 23:26:04 +01:00
|
|
|
Normally, the default behavior for the FAT file system is to perform
|
|
|
|
data transfers indirectly though specially allocated sector buffers
|
|
|
|
or, under certain circumstances, directly through user provided
|
|
|
|
buffers . These circumstances are: (1) The transfer is being
|
|
|
|
performed from the beginning of a sector (2) the user-provided
|
|
|
|
buffer will hold the full sector of data.
|
|
|
|
|
|
|
|
Some hardware, however, may require special DMA-capable memory or
|
|
|
|
specially aligned memory in order to perform the transfers. In this
|
|
|
|
case, there may be no circumstance where the user buffer can be used.
|
|
|
|
Selecting this option will disable all attempts to use the user-
|
|
|
|
provided buffer: All transfers will be force to be performed
|
|
|
|
indirectly through the FAT file systems sector buffers.
|
|
|
|
|
|
|
|
Note: This will have the negative impact of: (1) An extra data
|
|
|
|
copy to transfer the data between the user buffer and the FAT file
|
|
|
|
systems internal sector buffers, and (2) A loss of performance
|
|
|
|
because I/O will be limited to one sector at a time.
|
|
|
|
|
2016-02-23 01:25:58 +01:00
|
|
|
This would typically be used with CONFIG_FAT_DMAMEMORY so that
|
|
|
|
special memory allocators are also used and transfers are also
|
|
|
|
performed using only that specially allocated memory.
|
|
|
|
CONFIG_FAT_DMAMEMORY, on the other hand, is often used without
|
|
|
|
CONFIG_FAT_FORCE_INDIRECT when the user memory buffers may come
|
|
|
|
from mixed locations, some of which are DMA-able and some of
|
|
|
|
which are not. But CONFIG_FAT_FORCE_INDIRECT could be used
|
|
|
|
without CONFIG_FAT_DMAMEMORY if there is, for example, only a
|
2020-02-23 09:50:23 +01:00
|
|
|
memory alignment constraints.
|
2016-02-23 01:25:58 +01:00
|
|
|
|
2016-02-23 13:38:51 +01:00
|
|
|
FORCE_ DMA DIRECT EXAMPLE USAGE
|
|
|
|
INDIRECT MEMORY RETRY
|
|
|
|
Y Y * Use specially allocated memory;
|
|
|
|
Never use caller provided buffer
|
|
|
|
Y N * Not recommended
|
|
|
|
N Y ** Special memory required; user memory
|
|
|
|
has mixed capability; sometimes
|
|
|
|
caller memory is not usable
|
|
|
|
N N Y No special memory but there are
|
|
|
|
alignment requirements; return is
|
|
|
|
caller buffer is not properly aligned
|
|
|
|
N N N User memory can always be used for
|
|
|
|
transfer.
|
|
|
|
|
2016-02-24 18:54:02 +01:00
|
|
|
* CONFIG_DIRECT_RETRY cannot be selected with CONFIG_FORCE_INDIRECT
|
|
|
|
** CONFIG_DIRECT_RETRY is automatically selected with CONFIG_DMA_MEMORY
|
|
|
|
|
2012-09-11 15:53:44 +02:00
|
|
|
config FAT_DMAMEMORY
|
|
|
|
bool "DMA memory allocator"
|
|
|
|
default n
|
2016-02-23 01:25:58 +01:00
|
|
|
select FAT_DIRECT_RETRY if !FAT_FORCE_INDIRECT
|
2012-09-11 15:53:44 +02:00
|
|
|
---help---
|
|
|
|
The FAT file system allocates two I/O buffers for data transfer, each
|
|
|
|
are the size of one device sector. One of the buffers is allocated
|
|
|
|
once for each FAT volume that is mounted; the other buffers are
|
|
|
|
allocated each time a FAT file is opened.
|
|
|
|
|
|
|
|
Some hardware, however, may require special DMA-capable memory in
|
2013-08-27 17:40:19 +02:00
|
|
|
order to perform the transfers. If FAT_DMAMEMORY is defined
|
2013-04-20 02:35:06 +02:00
|
|
|
then the architecture-specific hardware must provide the functions
|
2012-09-11 15:53:44 +02:00
|
|
|
fat_dma_alloc() and fat_dma_free(): fat_dmalloc() will allocate
|
|
|
|
DMA-capable memory of the specified size; fat_dmafree() is the
|
|
|
|
corresponding function that will be called to free the DMA-capable
|
|
|
|
memory.
|
|
|
|
|
2016-02-23 13:38:51 +01:00
|
|
|
FORCE_ DMA DIRECT EXAMPLE USAGE
|
|
|
|
INDIRECT MEMORY RETRY
|
|
|
|
Y Y * Use specially allocated memory;
|
|
|
|
Never use caller provided buffer
|
|
|
|
Y N * Not recommended
|
|
|
|
N Y ** Special memory required; user memory
|
|
|
|
has mixed capability; sometimes
|
|
|
|
caller memory is not usable
|
|
|
|
N N Y No special memory but there are
|
|
|
|
alignment requirements; return is
|
|
|
|
caller buffer is not properly aligned
|
|
|
|
N N N User memory can always be used for
|
|
|
|
transfer.
|
|
|
|
|
2016-02-24 18:54:02 +01:00
|
|
|
* CONFIG_DIRECT_RETRY cannot be selected with CONFIG_FORCE_INDIRECT
|
|
|
|
** CONFIG_DIRECT_RETRY is automatically selected with CONFIG_DMA_MEMORY
|
|
|
|
|
2016-02-23 01:25:58 +01:00
|
|
|
config FAT_DIRECT_RETRY
|
|
|
|
bool "Direct transfer retry"
|
|
|
|
default y if FAT_DMAMEMORY
|
|
|
|
default n if !FAT_DMAMEMORY
|
|
|
|
depends on !FAT_FORCE_INDIRECT
|
|
|
|
---help---
|
|
|
|
The FAT file system contains internal, well aligned sector buffers
|
|
|
|
for indirect data transfer. These transfers are indirect in the
|
|
|
|
sense that that the actual transfer occurs into/out of the sector
|
|
|
|
buffers and an additional copy is necessary to/from the user-
|
|
|
|
provided I/O buffers. But under certain conditions, the FAT file
|
|
|
|
system will use the caller-provided I/O buffers directly to improve
|
|
|
|
efficiency. Those conditions are (1) CONFIG_FAT_FORCE_INDIRECT is
|
|
|
|
not defined, (2) The access is to/from the beginning of a sector,
|
|
|
|
and (3) the user provided buffer is large enough to hold an entire
|
|
|
|
sector.
|
|
|
|
|
|
|
|
The lower level SDIO driver may have, certain requirements on the
|
|
|
|
memory buffer in order to perform the transfer. Perhaps special
|
|
|
|
DMA memory should be used (with CONFIG_FAT_DMAMEMORY) or perhaps
|
2020-02-23 09:50:23 +01:00
|
|
|
some special memory alignment is required to interface with the
|
2016-02-23 01:25:58 +01:00
|
|
|
hardware.
|
|
|
|
|
|
|
|
If this option is selected, then the FAT file system will first
|
|
|
|
try the user provided I/O buffer under above conditions. If the
|
|
|
|
transfer fails with -EFAULT. then the FAT file system will try one
|
|
|
|
more time using the internal sector buffers.
|
|
|
|
|
2016-02-23 13:38:51 +01:00
|
|
|
FORCE_ DMA DIRECT EXAMPLE USAGE
|
|
|
|
INDIRECT MEMORY RETRY
|
|
|
|
Y Y * Use specially allocated memory;
|
|
|
|
Never use caller provided buffer
|
|
|
|
Y N * Not recommended
|
|
|
|
N Y ** Special memory required; user memory
|
|
|
|
has mixed capability; sometimes
|
|
|
|
caller memory is not usable
|
|
|
|
N N Y No special memory but there are
|
|
|
|
alignment requirements; return is
|
|
|
|
caller buffer is not properly aligned
|
|
|
|
N N N User memory can always be used for
|
|
|
|
transfer.
|
|
|
|
|
2016-02-24 18:54:02 +01:00
|
|
|
* CONFIG_DIRECT_RETRY cannot be selected with CONFIG_FORCE_INDIRECT
|
|
|
|
** CONFIG_DIRECT_RETRY is automatically selected with CONFIG_DMA_MEMORY
|
|
|
|
|
2016-02-22 23:26:04 +01:00
|
|
|
endif # FAT
|