1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
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
|
