May conflict with #4987
Should be checked.

May conflict with #4987
Should be checked.

Yup and with #5027, #4854 and #3576 so we should wait for them; then we can simply drop the flashbdev patch from this PR

Thanks for the contribution.

But I guess this will no longer work if #5027 is merged. Because that patch removes calls to the esp.flash_read etc functions and instead uses a Partition object.

Do you know how to make wear levelling work with the IDF partition interface?

I see that wl_mount takes an esp_partition_t*

Actually, looking at the high level API, https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/storage/wear-levelling.html#high-level-api-reference, it seems this is very much supported. Should be able to implement wear levelling as a Partition object that uses the high level API provided here as a middleware.

Edit:

WL doesn't explicitly mention anything about Flash Encryption. Its my assumption that it would be handled transparently if the partition table for a fatfs partition was tagged with encrypted. This would need to be verified.

Last thought:
I think I'm of the opinion that the vfs partitions, via the Partition class, should default to wear-levelling. I'm not sure I see a need otherwise; unless it breaks being able to read and write the fat partition via esptool / creating a fat image on the PC and pushing it to an ESP32.

It would be my preference that wear levelling just works and just happens whenever a read/write partition is mounted.

I see that wl_mount takes an esp_partition_t*

Yes, a partition must be "mounted as wearlevel partition".

Actually, looking at the high level API, https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/storage/wear-levelling.html#high-level-api-reference, it seems this is very much supported. Should be able to implement wear levelling as a Partition object that uses the high level API provided here as a middleware.

The problem here is that we DO NOT use the highlevel API / espressif's vfs but instead build on our own fatfs and vfs implementation. This means no, we can not use that. The partitions must be mounted explicitely through the mid level API (wl*). @dpgeorge's code uses esp_partition_write which relies on spi_flash_write which does not do wear levelling natively.

Edit:

WL doesn't explicitly mention anything about Flash Encryption. Its my assumption that it would be handled transparently if the partition table for a fatfs partition was tagged with encrypted. This would need to be verified.

Wear levelling is completely transparent, as is encryption. You can mount an unencrypted or an encrypted partition as wearlevelling partition:

spi flash <- partition (encrypted or unencrypted) <- wear levelling <- <mapped blocks / partition> <- filesystem

Last thought:
I think I'm of the opinion that the vfs partitions, via the Partition class, should default to wear-levelling. I'm not sure I see a need otherwise;

unless it breaks being able to read and write the fat partition via esptool / creating a fat image on the PC and pushing it to an ESP32.

This is NOT possible with wear levelling currently as esptool writes directly to flash. You must create a wear levelling partition image and flash that. There's a tool for this: https://github.com/TobleMiner/mk_esp32fat

It would be my preference that wear levelling just works and just happens whenever a read/write partition is mounted.

The right way would be dropping our own vfs and fatfs and instead build on espressif's vfs and fatfs which both natively support encryption and wear levelling. This would even make it possible to easily use spiffs or anything else that is getting added to esp-idf in later versions.

Thanks for taking the time to write up the detailed reply, clears a lot of thoughts. 👍

#5027 (use of Partition class as the FS block device) was merged in 31de447, so this PR would need to be reworked against that.

The right way would be dropping our own vfs and fatfs and instead build on espressif's vfs and fatfs which both natively support encryption and wear levelling. This would even make it possible to easily use spiffs or anything else that is getting added to esp-idf in later versions.

I understand the sentiments here, but the idea is that MicroPython is consistent across many different ports/boards/architectures/SoCs/MCUs/etc and so in that light it's important to use the MicroPython-supplied VFS (eg then you can mount custom filesystems the same way on all ports).

Well, it may be possible to merge both worlds by using the VfsPosix class to interface to the ESP-IDF filesystem. Feel free to look into that if you like. Otherwise I'd suggest to find a way to make the Partition class use wear leveling.