[ESP32 Docs]: Partition readblocks / writeblocks extended
The Partition class docs are a bit misleading, if i am right.
These methods implement the simple and extended block protocol defined by uos.AbstractBlockDev.
But the source code of the Partition class is using an internal calculated offset so atm there is just the simple protocol:
STATIC mp_obj_t esp32_partition_readblocks(mp_obj_t self_in, mp_obj_t block_num, mp_obj_t buf_in) { esp32_partition_obj_t *self = MP_OBJ_TO_PTR(self_in); uint32_t offset = mp_obj_get_int(block_num) * BLOCK_SIZE_BYTES; mp_buffer_info_t bufinfo; mp_get_buffer_raise(buf_in, &bufinfo, MP_BUFFER_WRITE); check_esp_err(esp_partition_read(self->part, offset, bufinfo.buf, bufinfo.len)); return mp_const_none; }
Please correct me if I am wrong.
esp32: use wear leveling for vfs partition
This issue is a follow-on to #4999, which attempted to add wear leveling prior to the esp32.Partition class. As far as I can tell, the situation is as follows:
- the esp32
Partitionclass uses the esp-idfesp_partition_xxxfunctions to init, read, write, erase blocks in a partition - the global
bdevgets mapped to the partition called "vfs" inports/esp32/modules/flashbdev.py mp_vfs_autodetectdetects which filesystem type the globalbdevpartition contains and inits that filesystem and mounts it as root filesystem- the esp-idf "mid level" wear leveling API (https://docs.espressif.com/projects/esp-idf/en/v4.0/api-reference/storage/wear-levelling.html#mid-level-api-reference) has basically the same functions as the partition API as far as accessing the partition data concerns.
Given the above it seems to me that the following enhancement would support wear leveling:
- Add a flag to a
Partitionthat specifies whether wear leveling is used or not - If WL is not used, use the
esp_partition_xxxfunctions being used now, else if WL is used, use the correspondingwl_xxxfunctions instead - Init the esp-idf WL layer on a partition upon first access of a block
The one thing that's not entirely clear to me is how to flag a partition to use wear leveling. The two options that seem best to me are:
- Use a custom partition subtype, right now the partition tables in MP use the "FAT" subtype, which is not really appropriate given that the partition can contain a littlefs (which is now the default). There are plenty of unused partition subtypes that could be used.
- Use a convention around partition names, right now the "vfs" partition is mounted as root filesystem, in addition the code could look for a "vfs_wl" partition as well and the
Partitionconstructor could treat any partition with a_wlsuffix to have wear leveling.
Overall all this doesn't sound like a big change unless I missed something (entirely possible!) and should not affect MP compatibility across ports.