apache
drivers/mtd:init commit of power-loss resilient cfg
Signed-off-by: 田昕 [email protected]
Summary
MTD non-volatile storage was originally implemented in Zephyr by Laczen. We made several modification to the original design. The main purpose of those modification was:
- support C-string key in nvs API(Original design only support uint16_t as key)
- Meanwhile achieve better performance by limiting flash read times(Theoratically better than Zephyr subsys/settings, which is based on original NVS).
This is the initial commit, I have tested its set/unset/get/list/erase with https://github.com/apache/incubator-nuttx-apps/tree/master/system/cfgdata, the result shows no obvious bug.
More tests on power-loss behavior are needed, and I plan to add those test cases into apps/testing in the next patch
Impact
config data only.
Testing
set/unset/get/list/erase tested on ESP32C3.
In general I'm a bit lost in architecture here. The MTD layer is designed to provide unified "continuous" access across the underlying physical layer, so I expect that all alignment or any other hardware related stuff is hidden "under" MTD device, but here I observe an opposite when the MTD caller handle alignment and other stuff. I mean that if MTD is implemented on top of flash that is what I expect, but not implementing a flash on top of MTD what I see here. I will submit a negative feedback until all design points are not clarified
Basically, MTD like a block device(but need erase before write, wear leveling and ECC), which is hard to use from user application. To fix this problem, we normally have two approach:
- Build a complex filesystem on top of MTD to support a tree like structure(e.g. spiffs, smartfs and littlefs).
- Build a simple key value storage on top of MTD
NVS(and cfgdata) is the second approach. @pkarashchenko do you get the idea?
In general I'm a bit lost in architecture here. The MTD layer is designed to provide unified "continuous" access across the underlying physical layer, so I expect that all alignment or any other hardware related stuff is hidden "under" MTD device, but here I observe an opposite when the MTD caller handle alignment and other stuff. I mean that if MTD is implemented on top of flash that is what I expect, but not implementing a flash on top of MTD what I see here. I will submit a negative feedback until all design points are not clarified
Basically, MTD like a block device(but need erase before write, wear leveling and ECC), which is hard to use from user application. To fix this problem, we normally have two approach:
1. Build a complex filesystem on top of MTD to support a tree like structure(e.g. spiffs, smartfs and littlefs). 2. Build a simple key value storage on top of MTDNVS(and cfgdata) is the second approach. @pkarashchenko do you get the idea?
@xiaoxiang781216 we already have KVS on top of MTD and that is mtdconfig. Could you please bring some more light on key differences between mtdconfig and NVS?
The major difference is power failure safe, it's very hard to support this feature on mtdconfig without breaking the binary combability. Since NVS share the same external interface with mtdconfig, the user could select which one to use.
I have found a few bugs, and will keep on fixing. So I convert this to draft.
Though this is a draft, please review it. Much appreciation to anyone helps to review it.
Alright, I have fixed the bugs and passed zephyr test cases. Please review.
test cases are here:https://github.com/apache/incubator-nuttx-apps/pull/1288