The findItem method was improved to use a hash list in RAM when searching for BLOB data chunks
The findItem method was extended with a parameter that returns the position of an item on the page,
if it is found
The algorithm for matching existing variable-length data (such as strings and BLOBs) with
new values was enhanced by comparing the CRC32 of the data chunks before reading the data from flash
Bootloader NVS decryption uses hardware ROM APIs to decrypt the NVS contents,
but for targets that do not support AES hardware we could benefit by using the
software mbedtls library that is present in the ROM directly.
- When flash encryption is enable to support reading a partition that is not
marked as "encrypted", the `esp_partition_read()` API of bootloader build
should be redirected to the `bootloader_flash_read()` API.
NVS configuration is extended with Kconfig option controlling RAM area for
NVS heap allocation. Either Internal RAM or SPIRAM can be chosen.
Tests were extended to check memory consumption from Internal and SPIRAM pool with respect
to the Kconfig option chosen.
Documentation was extended with notes related to NVS behavior in various situations.
Global.h defines U8, I8, U16, etc. symbols, which are also used in NVS
as a part of custom enum class and this can cause a compilation error
during macro expansion, when sysview is enabled and FreeRTOS.h is included in NVS
Wrong condition gating the hash map use causing performance degradation was corrected
The condition enabling use of hash map when page is searched for Item was modified
to correct the bug introduced by commit addressing delete of any BLOB_INDEX Items.
This correction returns the performance of findItem to the state before previous change.
Function now always rewrites old value under same key
regardless existing data type. Users requiring old API behaviour
can enable it by kconfig option CONFIG_NVS_LEGACY_DUP_KEYS_COMPATIBILITY
Users of the nvs API are likely to have `nvs_handle_t` in all cases, but
not all of them carry around the partition name and namespace name (as
they aren't needed after creating an `nvs_handle_t`).
Allow this common case to use nvs iteration without them tracking
additional data by using the `nvs_handle_t` to locate the namespace
index and the partition name by introducing an alterate to
`nvs_entry_find` called `nvs_entry_find_in_handle`, which operates
similarly except that it is given a `nvs_handle_t` instead of partition
and namespace strings.
This is somewhat more limited than the `nvs_entry_find` API as one
cannot examine all keys in a given partition.
- This features allows the NVS encryption keys to be derived and protected using
the HMAC peripheral. Since the encryption keys are derived at runtime, they
are not stored anywhere in the flash and hence this feature does not require
a separate `nvs_keys` partition.
spi_flash driver knows how to write data from cache (DROM or PSRAM)
into flash, so the extra check in nvs_flash is unnecessary.
Besides, the hardcoded address limit (0x3ff00000) is wrong for some
of the newer chips.
