91 lines
3.4 KiB
Plaintext
91 lines
3.4 KiB
Plaintext
|
menu "SPINOR Devices"
|
||
|
|
|
||
|
|
config DRIVERS_SPINOR
|
||
|
|
bool "enable spinor driver"
|
||
|
|
default y
|
||
|
|
|
||
|
|
config HAL_TEST_SPINOR
|
||
|
|
bool "enable spinor hal APIs test command"
|
||
|
|
depends on DRIVERS_SPINOR
|
||
|
|
default n
|
||
|
|
|
||
|
|
config DRIVERS_SPINOR_FREQ
|
||
|
|
int "spinor frequency (MHz)"
|
||
|
|
depends on DRIVERS_SPINOR
|
||
|
|
range 10 100
|
||
|
|
default 50
|
||
|
|
help
|
||
|
|
The frequency for spi master.
|
||
|
|
|
||
|
|
config DRIVERS_SPINOR_4K_SECTORS
|
||
|
|
bool "Use small 4096 B erase sectors"
|
||
|
|
depends on DRIVERS_SPINOR
|
||
|
|
default y
|
||
|
|
help
|
||
|
|
This only tells the upper layer that the block size is 4K and the upper
|
||
|
|
layer can do 4K erase. In fact, the driver still supports 32K or 64K
|
||
|
|
erase and it may try to do 64K or 32K erase as far as possible if you
|
||
|
|
enable cache since it does really improve performance. Erasing should be
|
||
|
|
mush faster when using 64K block instead of 16 * 4K.
|
||
|
|
|
||
|
|
Why we should need this option? Even most filesystems save a file in
|
||
|
|
unit block, which is equal to nor block size generally. The larger block
|
||
|
|
is, the much space waste for a small file. Take an example, to save a 1K
|
||
|
|
size file, the filesystem allocate a block for it and waste 3K size
|
||
|
|
for 4K block size, even 63K size for 64K block size.
|
||
|
|
|
||
|
|
To balance waste-space and performance, we really support to eanble
|
||
|
|
4K block and nor cache to get more operations together.
|
||
|
|
|
||
|
|
If unsure, please says Y.
|
||
|
|
|
||
|
|
config DRIVERS_SPINOR_CACHE
|
||
|
|
bool "Enable spinor cache layer"
|
||
|
|
depends on DRIVERS_SPINOR
|
||
|
|
default n
|
||
|
|
help
|
||
|
|
To improve write performance by merging 4K page erase operation to
|
||
|
|
32K/64K erase operation. This cache layer holds a 64K buffer. It just
|
||
|
|
will cache sequential erase/write operation. There are three ways to
|
||
|
|
flush cache.
|
||
|
|
|
||
|
|
1. block buffer is fullly.
|
||
|
|
2. operate over a block.
|
||
|
|
Once operate over a 64K block, this layer will write-back directly
|
||
|
|
avoiding lose data.
|
||
|
|
3. upper layer call hal_spinor_sync()
|
||
|
|
|
||
|
|
This cache layer with the littlefs turns out no loss of data, but the
|
||
|
|
others need more tested. The upper layer (fs) should takes care of the
|
||
|
|
following issues.
|
||
|
|
|
||
|
|
1. after writing meta data, upper must call hal_spinor_sync() to flush
|
||
|
|
cache. Also, you can flush cache for fatal data too. In a word,
|
||
|
|
sync() is called only immediately after data that affects filesystem
|
||
|
|
consistency is written. The littlefs is checked ok.
|
||
|
|
2. contecting to sync()/fsync() for user in case of user codes writing
|
||
|
|
fatal file.
|
||
|
|
|
||
|
|
If unsure, please says N.
|
||
|
|
|
||
|
|
config DRIVERS_SPINOR_WRITE_LOCK
|
||
|
|
bool "Use nor dynamic write limit if support"
|
||
|
|
depends on DRIVERS_SPINOR
|
||
|
|
default y
|
||
|
|
help
|
||
|
|
Some nor flash support write protection. This feature is much usefull
|
||
|
|
for power lose case to avoid data corruption. Most of them support zone
|
||
|
|
protection, which cost much for status register and to protect
|
||
|
|
a continuous space from head or tail. That's NOT what we need. What this
|
||
|
|
option used, is individual block protection. Before we do write/erase
|
||
|
|
operation, we unlock (unprotect) the individual block we want and still
|
||
|
|
protect other blocks. As you see, the unit to lock/unlock is a block.
|
||
|
|
Beside, it just rewrite a volatile memory, not status register, which
|
||
|
|
has less time and wear costs.
|
||
|
|
|
||
|
|
In a word, It spends very little time to protect data if power lose.
|
||
|
|
|
||
|
|
If unsure, please says Y.
|
||
|
|
|
||
|
|
endmenu
|