[esp-storage]: Add partitions support and allowed memory ranges

[AnthonyGrondin]

Motivations

Currently, esp-storage gives an API to access memory with a read write access, but when initialized with esp_storage::FlashStorage::new(), it gives readable / writable access to the complete SoC flash. This enables many footgun like accidentally writing over multiple partitions.

Solution

1. Provide a range to limit the amount of flash memory esp-storage has access to. (I.E. keep start: u32. end: u32 in FlashStorage and throw an invalid range error when trying to access memory outside of the range)
2. Use something like bjoernQ/esp32c3-ota-experiment@9c60dd1 to handle partitions from a provided partition table and limit access to a specific partition.

Alternatives

To be discussed...

Additional context

N/A

[Dominaezzz]

Couldn't this be easily DIYed with a wrapper?

[AnthonyGrondin]

embedded-storage provides a Region trait. So we might as well make use of it.

This is totally fixable with a DIY wrapper, but providing it with the library itself makes it more user-friendly for newcomers and reduces the amount of work needed to get something working.

esp-storage provides a low-level feature itself for low-level operations, so I believe the current API can provide a little bit more of desirable functionalities.

[Dominaezzz]

embedded-storage can provide a sub region struct then to solve this problem.

I'd rather not artificially limit what FlashStorage is capable of for something that can be done externally.
Perhaps an additional struct.

[bjoernQ]

I agree with @Dominaezzz that we should not artificially limit the things it can do - providing Regionss might be a possible solution

But one thing I'm also concerned about is that while currently we only support esp-idf's bootloader and partition-table that might (and most probably will) change in future (we will keep what we currently support but want to add at least MCUboot - maybe others in future)

We can ofc introduce features and/or configs but e.g. in #3124 (review) we are considering having specific crates for that

[AnthonyGrondin]

That's a good point. Using partition related data might be too specific to the IDF bootloader. But it could be offered optionally.

My view on this, isn't to limit esp_storage's capabilities in any way, but rather enhance it, by allowing the user to provide guards over which memory regions it has access to. Integrating regions and new APIs, while not touching what's already there is a good solution, to offer both a very permissive access to the flash storage, and a "protected" access that would prevent the developer (or user provided input) to read / write memory region it shouldn't.

[bjoernQ]

I am considering having a esp-bootloader-support-esp-idf crate (or similar ... naming is hard) which will offer access to the partition table, OTA functionality, supply the app-descriptor needed for latest esp-idf bootloaders (and more) - I guess such functionality would be a good fit there?

Later we can have e.g. esp-bootloader-support-mcu-boot etc.