wearleveling filesystem image uploading

[perryc]

I'm I correct to assume the new wear leveling spiffs would not work with mkspiffs created filesystem images? and if that is correct is anyone working on a new tool or updating mkspiffs?

Perry

[ESP_igrr]

It should be possible to prepare the partition image using the standard tools to generate FAT FS. We plan to have a guide for this, but haven't started on it yet.

[perryc]

Thanks very much for the reply.
Build a 1M FAT image and flashed it to 0x100000 but esp_vfs_fat_spiflash_mount() still triggered a reformat so guess I'll need the experts to be my guide once again.

Perry

[perryc]

Success! Using the partitions.csv shown below I found the fat filesytem created by esp_vfs_fat_spiflash_mount() at 0x111000 (Not 0x110000 as expected). Downloaded the fs with:

Code: Select all

$IDF_PATH/components/esptool_py/esptool/esptool.py --baud 115200 --port com3 read_flash 0x111000 0xF0000 spifat.img

could not figure out how to get msys32's mount work so had to use a real linux box to

Code: Select all

mount -o loop spifat.img mntdir

copied files into mounted fs, umounted and used esptool.py to write back to esp32 and we were good to go.

Code: Select all

# Note: if you change the phy_init or app partition offset, make sure to change the offset in Kconfig.projbuild,,,,
nvs,      data, nvs,     0x9000,  0x6000,
phy_init, data, phy,     0xf000,  0x1000,
factory,  app,  factory, 0x10000, 1M,
storage,  data, fat,0x110000,0xf0000,

[ESP_Sprite]

Fyi, do note that this trick works only when the filesystem is relatively new. Once a bit older, the wear level system will have shuffled some sectors around. You would still be able to mount the flash just fine and you can probably, depending on the state of the wear levelling system, still see the files, but their contents may be corrupted.

[kolban]

PerryC, ESP_Sprite, ESP_Igrr,
This is a very interesting thread. In PerryC's story, he seemed to have dumped an image from Flash that was formatted by esp_vfs_fat_spiflash_mount() and successfully mounted it as a Linux mount point, modified it and flashed it back. This is GREAT ... but I take the warnings seriously that because of wear leveling, things will become "corrupted". However, the core thought to me is "**will** become corrupted" ... does that mean that this is a recipe where I can create an initial image for seeding a file system? For example, if I want my ESP32 to be a web server, I could load up the web files into the file system?

[perryc]

Putting /html content on a fresh system was exactly what we wanted it for but I guess we better build a loader that uses fileio to be safe long term. Can the wear leveling counters be reset so a new fat filesystem can be loaded and can be trusted to work on anything but a fresh module?

Perry

[kolban]

Perry,
For testing, I'm tinkering with a TFTP server that can run in the ESP32. This will allow us to "upload" files to be saved in file FATFS. Its a poor mans story, but it will satisfy my immediate needs. If you or anyone else are interested, ping me.

[ESP_igrr]

For initial loading, the method will work. In fact, it is similar to the method we have considered while designing the wear levelling library. The idea was to create a file system using existing tools such as mkfs.vfat, mount it, load files into it, unmount, add the correct wear levelling metadata at the end of the partition, and then upload the resulting binary to the ESP32.

[kolban]

Unfortunately I couldn't reproduce Perry's tests. I created a partition at 0x30 0000 for 1MB and then used esptool to extract the data. I tried 0x30 0000 for 0x10 0000 and 0x31 0000 for 0x0f 0000 but with neither of the resulting files could I use any mount commands on Linux. Is Perry using the right commands? Are there any suggestions for the commands to use?