wearleveling filesystem image uploading

[PeterR]

I preferably want the filesystem to be ready when programmed

You can still do that, well with a small boot action addition to your main application.
As I understand it you simply lack the ability to directly place a FatFS image into FLASH whilst preserving wear levelling details.
You can however program a SPIFFS image or some other file system.
Assuming that you have sufficient storage to hold two images then your programming procedure simply programs the SPIFFS image (or which ever FLASHable file system).
When your application boots it checks flags and then copies from programmable file system to FatFS & clears the programmable file sysrem's 'new' flag.
It may be a little slower on first boot but perhaps not that bad?

[AloyseTech]

I understand your idea, but the application already takes a lot of flash and I can't have twice the filesystem memory usage (once for the SPIFFS initial data, and one for the FatFS). I might be able to use the RAM available before any initialization to read and store the SPIFFS data, and then format a Fat partition in place of the SPIFFS but there is a risk of data loss doing so.

Clearly a tool to flash a Fat partition would be the clean solution.
Maybe the existing host side fatfs/wear leveleving test could serve as a basis for this tool ? (https://github.com/espressif/esp-idf/tr ... fatfs_host)

I thought that by creating a partition using mkfs.vfat I would be able to flash a clean partition but I can't mount a filesystem correctly with this method.
I tried to dump an empty partition created on an ESP32 and mount it on my host machine, which works. I can add files to the partition and flash it back to the ESP32. A file can be opened, the size is calculated correctly, but the data are not correct (I suspect a wrong wear leveling API conversion from virtual and real addresses).

[PeterR]

Understood.
I'm empty then. As you are no doubt aware the problem will be 'sharing' format information between a PC upload program & the ESP drivers.
IJDK what that format is.
Hence TFTP or SPIFFS updload gets round the format issue.
The host side tool approach does seem to expose you to version change issues & I am not sure that you gain much.
A first boot program which then uploads on 232 or Ethernet etc does not seem that different in performance. You will be bus bandwidth bound and a few seconds for an extra reboot would not seem a big issue.
Good luck.