The commit adds and no_explicit_erase capability to flash_parameters,
that indicates whether device is program-erase type device; such
devices, like Flash type devices, require erase prior to writing
random data at any previously programmed location.
This capability should only be set by drivers.

The flash_params_get_erase_cap() function has been added, for parsing
flash_parameters object to obtain erase capabilities of device.
The function returns capabilities as combination of bits representing
them. Currently it will return:
 0 -- no erase capabilities
 FLASH_ERASE_C_EXPLICIT -- erase required before write of random data.
Additional capabilities have been reserved but are not yet used.

There are following Kconfig options added:
 FLASH_HAS_EXPLICIT_ERASE
 FLASH_HAS_NO_EXPLICIT_ERASE
that should be selected by device driver to indicate whether
devices served by driver needs erase prior to write.
The above Kconfigs are used to figure out whether app is built
for hardware that requires erase prior to write.
They can be also used to detect that it is attempted to build
some subsystem that will not work with provided hardware, for example
file system that has not been prepared to work with devices that
do not require erase.

Signed-off-by: Dominik Ermel <[email protected]>
(cherry picked from commit b3c9f95)

…RASE

Select CONFIG_FLASH_HAS_EXPLICIT_ERASE for the NRF driver.

Signed-off-by: Dominik Ermel <[email protected]>
(cherry picked from commit 6d75bc5)

…ty to true

NRF RRAM does not require erase prior to re-programming already
written area.

Signed-off-by: Dominik Ermel <[email protected]>
(cherry picked from commit 127bc5e)

…ty to true

NRF MRAM does not require erase prior to re-programming already
written area.

Signed-off-by: Dominik Ermel <[email protected]>
(cherry picked from commit 0e970c8)

Add a Kconfig.constants file that defines variables for different known
integer minimum and maximum values.

Signed-off-by: Pieter De Gendt <[email protected]>
(cherry picked from commit dfdebc9)

ZMS is the abreviation of Zephyr Memory Storage.
It is a storage developed to target especially the non erasable devices.

The new memory storage system inherit from the NVS storage multiple
features and introduce new ones :
* Inherited features :
 - light key-value based storage
 - cache for entries
 - Wear Leveling of flash memory
 - Resilience to power failures
* New features :
 - cycle counter for non erasable devices (instead of erase emulation)
 - Keys up to 32-bit
 - Built-in support of CRC32 for data
 - Small size data (<= 8 bytes) integrated within entries

Upstream PR: zephyrproject-rtos/zephyr#77930

Signed-off-by: Riadh Ghaddab <[email protected]>
(cherry picked from commit 7bf5d179cc5d586fb3cf4564f92cea7b66b0e964)

List of added tests :
- zms.test_delete
- zms.test_zms_cache_collission
- zms.test_zms_cache_gc
- zms.test_zms_cache_hash_quality
- zms.test_zms_cache_init
- zms.test_zms_corrupted_sector_close_operation
- zms.test_zms_corrupted_write
- zms.test_zms_full_sector
- zms.test_zms_gc
- zms.test_zms_gc_3sectors
- zms.test_zms_gc_corrupt_ate
- zms.test_zms_gc_corrupt_close_ate
- zms.test_zms_mount
- zms.test_zms_write

Upstream PR: zephyrproject-rtos/zephyr#77930

Signed-off-by: Riadh Ghaddab <[email protected]>
(cherry picked from commit 1f4e92c3da4b738d2dd203348d7a93f5ccdb5b99)

This adds a user application that shows the usage of ZMS
The sample app shows three main functions of ZMS:
- read/write/delete key/value pairs
- fill all storage and delete it
- calculate free remaining space

Upstream PR: zephyrproject-rtos/zephyr#77930

Signed-off-by: Riadh Ghaddab <[email protected]>
(cherry picked from commit c479fadad817a84da18ea2f2e1873cebbd9c1f12)

…orage)

This adds the initial backend support for the ZMS storage system.

Upstream PR: zephyrproject-rtos/zephyr#78632

Signed-off-by: Riadh Ghaddab <[email protected]>
(cherry picked from commit 85bc1f8cd205fc3de17ebca2774acaf595cac16c)