mkfatfs

[tobozo]

Related area

package_index.json

Is your feature request related to a problem?

• Official arduino-esp32fs-plugin doesn't support FFat
• In package_index.json, the toolsDependencies and tools groups only list mklittlefs and mkspiffs.

Describe the solution you'd like

See lorol's version which supports FFat, and is currently the only available solution.

Since it depends on the existence of a "mkfatfs" tool in the package_index.json, the suggested solution is to add mklittlefs to the tools list.

Suggested tools:

• https://github.com/lorol/arduino-esp32fatfs-plugin
• https://github.com/earlephilhower/mklittlefs
• https://github.com/labplus-cn/mkfatfs (C)

Tested scopes:

• [x] x86_64-pc-linux-gnu
• [ ] aarch64-linux-gnu
• [ ] arm-linux-gnueabihf
• [ ] i686-pc-linux-gnu
• [ ] x86_64-apple-darwin
• [ ] arm64-apple-darwin
• [ ] i686-mingw32
• [ ] x86_64-mingw32

Describe alternatives you've considered

Alternate tool (in rust but uses different flags):

• https://github.com/software-opal/mkfatfs
• https://github.com/jkearins/ESP32_mkfatfs/tree/master/components/mkfatfs
• esp-idf fatfsgen (python)

I have checked existing list of Feature requests and the Contribution Guide

• [X] I confirm I have checked existing list of Feature requests and Contribution Guide.

[igrr]

Note that there is also fatfs partition generator tool (docs) in IDF. It is written in Python but can be packaged into an executable similar to esptool and others. It supports generation of both plain (read-only) FAT partitions and wear_levelling (read-write) FAT partitions.

[tobozo]

the esp-idf python tool sounds good, does it needs to be edited or wrapped to match the argument names requirements for the alternate arduino-esp32fs-plugin?

the mkfatfs tool from lab-plus already matches those requirements, however as highlighted by @atanisoft it needs static linking, and I have no idea how to produce that.

  mkfatfs  {-c <pack_dir>|-u <dest_dir>|-l|-i} [-d <0-5>] [-b <number>]
            [-p <number>] [-s <number>] [--] [--version] [-t <fstype>] [-h]
            <image_file>

  mklittlefs  {-c <pack_dir>|-u <dest_dir>|-l} [-d <0-5>] [-a] [-b <number>] 
           [-p <number>] [-s <number>] [--] [--version] [-h] 
           <image_file>

  mkspiffs  {-c <pack_dir>|-u <dest_dir>|-l} [-d <0-5>] [-a] [-b <number>] 
           [-p <number>] [-s <number>] [--] [--version] [-h] 
           <image_file>

what would be the shortest path, editing the esp-idf tool or produce statically linked binaries?

[atanisoft]

If it is in python it shouldn't be a problem for Linux / Mac as it can be run as-is natively, only on Windows does an executable need to be provided. If an executable is being provided for mk*fs then it must be statically linked to avoid a number of differences in Linux distributions.

[lbernstone]

I'm the one that originally compiled the tool for @lorol, and I made it clear that I wasn't going to support it or provide exectuables for other platforms. I think using what is provided by IDF is in almost all cases the right solution. If the name needs to be changed, I'm sure lorol will be willing to make a quick PR.

[tobozo]

If the name needs to be changed, I'm sure lorol will be willing to make a quick PR.

Although using IDF tools is obviously the best way to go, it doesn't feel right to transfer the argument names tech debt onto lorol's project as that would break the common pattern the code is using to manage seamlessly all three filesystems.

I don't know fastfsgen.py at all, but if IDF manages almost all cases, then couldn't a simple mklittlefs_py script just proxy between arduino-esp32fs-plugin and fatfsgen?

[igrr]

I am not sure we can completely avoid the knowledge about the underlying tool in arduino-esp32fs-plugin, since each filesystem has some settings specific to it only. For example, when generating SPIFFS we need to specify "page size" and "block size". For FAT, there are no such settings. Instead, we have sector size and allocation unit size (a.k.a. cluster size). I think it is much worse to shoehorn these FS-specific options into options with common names, instead of properly handling this in the FS plugin. It's not difficult to create 3 derived classes for different filesystems with each having knowledge about the underlying FS (and the corresponding tool), and instantiate the right class at run time.