1menu "SPINOR Devices"
2
3config DRIVERS_SPINOR
4    bool "enable spinor driver"
5        default y
6
7config HAL_TEST_SPINOR
8    bool "enable spinor hal APIs test command"
9    depends on DRIVERS_SPINOR
10        default n
11
12config DRIVERS_SPINOR_FREQ
13    int "spinor frequency (MHz)"
14    depends on DRIVERS_SPINOR
15    range 10 100
16    default 50
17    help
18      The frequency for spi master.
19
20config DRIVERS_SPINOR_4K_SECTORS
21    bool "Use small 4096 B erase sectors"
22    depends on DRIVERS_SPINOR
23    default y
24    help
25      This only tells the upper layer that the block size is 4K and the upper
26      layer can do 4K erase. In fact, the driver still supports 32K or 64K
27      erase and it may try to do 64K or 32K erase as far as possible if you
28      enable cache since it does really improve performance. Erasing should be
29      mush faster when using 64K block instead of 16 * 4K.
30
31      Why we should need this option? Even most filesystems save a file in
32      unit block, which is equal to nor block size generally. The larger block
33      is, the much space waste for a small file. Take an example, to save a 1K
34      size file, the filesystem allocate a block for it and waste 3K size
35      for 4K block size, even 63K size for 64K block size.
36
37      To balance waste-space and performance, we really support to eanble
38      4K block and nor cache to get more operations together.
39
40      If unsure, please says Y.
41
42config DRIVERS_SPINOR_CACHE
43    bool "Enable spinor cache layer"
44    depends on DRIVERS_SPINOR
45    default n
46    help
47      To improve write performance by merging 4K page erase operation to
48      32K/64K erase operation. This cache layer holds a 64K buffer. It just
49      will cache sequential erase/write operation. There are three ways to
50      flush cache.
51
52      1. block buffer is fullly.
53      2. operate over a block.
54         Once operate over a 64K block, this layer will write-back directly
55         avoiding lose data.
56      3. upper layer call hal_spinor_sync()
57
58      This cache layer with the littlefs turns out no loss of data, but the
59      others need more tested. The upper layer (fs) should takes care of the
60      following issues.
61
62      1. after writing meta data, upper must call hal_spinor_sync() to flush
63         cache. Also, you can flush cache for fatal data too. In a word,
64         sync() is called only immediately after data that affects filesystem
65         consistency is written. The littlefs is checked ok.
66      2. contecting to sync()/fsync() for user in case of user codes writing
67         fatal file.
68
69      If unsure, please says N.
70
71config DRIVERS_SPINOR_WRITE_LOCK
72    bool "Use nor dynamic write limit if support"
73    depends on DRIVERS_SPINOR
74    default y
75    help
76      Some nor flash support write protection. This feature is much usefull
77      for power lose case to avoid data corruption. Most of them support zone
78      protection, which cost much for status register and to protect
79      a continuous space from head or tail. That's NOT what we need. What this
80      option used, is individual block protection. Before we do write/erase
81      operation, we unlock (unprotect) the individual block we want and still
82      protect other blocks. As you see, the unit to lock/unlock is a block.
83      Beside, it just rewrite a volatile memory, not status register, which
84      has less time and wear costs.
85
86      In a word, It spends very little time to protect data if power lose.
87
88      If unsure, please says Y.
89
90endmenu
91