[FEAT] Filesystem implementation #60
Description
Story
As PROVES developers
We would like to be able to store data in non-volatile memory
So that we can persist settings between boots, store log messages for later retrieval, and upload files for over the air updates
Technical Documentation
Initial research shows that there are a large number of zephyr APIs in the filesystem space.
Virtual Filesystem Switch (VFS)
The VFS API is used to mount and unmount filesystems.
The File system Switch decouples the applications from directly accessing an individual file system’s specific API or internal functions by introducing file system registration mechanisms.
Flash Circular Buffer (FCP)
FCP is a FIFO buffer of fixed size that can be used to persist information. We may want to use this to store X amount of previous telemetry or logs that we can send to the ground during a pass. Using a circular buffer we know that we will not run out of flash memory space as we stream logs or telemetry to the filesystem. We would not need a component to run log rotation or cleanup.
Non-Volatile Store (NVS)
NVS is a non-volatile key-value store that is implemented using a circular buffer.
Settings
Key-value store API written as an abstraction on top of any chosen filesystem type: FCB, NVS, ZMS, or any other filesystem.
As of Zephyr release 4.1 the recommended backends for non-filesystem storage are NVS and ZMS.
Zephyr Memory Storage (ZMS)
ZMS is a key-value store that appears to be a replacement for NVS.
Zephyr Memory Storage is a new key-value storage system that is designed to work with all types of non-volatile storage technologies. It supports classical on-chip NOR flash as well as new technologies like RRAM and MRAM that do not require a separate erase operation at all, that is, data on these types of devices can be overwritten directly at any time.
Flash Image API
Documentation scant. Is this they way we create an over the air update system?
Abstraction layer to write firmware images to flash.
Decisions
From this exploration, it appears that we will likely use different filesystem APIs for the parameter database, over-the-air updates, log storage and perhaps blog storage.
Parameter Database
We should use the Settings API backed by ZMS
OTA Updates
Needs more discovery but possibly the Flash Image API?
Log & Telemetry Storage
We should use FCP so we don't need to maintain log rotation/cleanup code
Blob Storage
Needs more discovery but it looks like we have a choice of filesystems
EXT2 filesystem fstab Define ext2 filesystems in the devicetree.
Fatfs filesystem fstab Define fatfs filesystems in the devicetree.
File system manipulation Use file system API with various filesystems and storage devices.
File system shell Access a LittleFS file system partition in flash using the file system shell.
Format filesystem Format different storage devices for different file systems.
LittleFS filesystem Use file system API over LittleFS.
USB Mass Storage Expose board's RAM or FLASH as a USB disk using USB Mass Storage driver.
virtiofs filesystem Use file system API over virtiofs.