nodemcu / nodemcu-firmware

Lua based interactive firmware for ESP8266, ESP8285 and ESP32
https://nodemcu.readthedocs.io
MIT License
7.64k stars 3.12k forks source link

Simplifying the SPIFFS image parameters #3147

Open TerryE opened 4 years ago

TerryE commented 4 years ago

@jmattsson 's spiffsimg utility was written back in the days when the only module available was the ESP-01 with 4 Mbit /0.5Mbyte parts and long before the position of the SPIFFS was set in the partition table. The command had a lot of options intended to help developers to choose the best FS size, but these are now obsolescent and confusing, IMO.

If the -S option is given then this size is used so long as it is an exact multiple of the flash page size, 4Kb, (even though the FS has to a multiple of the logical block size which is usually 8Kb)

If the -S option is omitted then this size is computed from the used and flash size: If the flash size is < 1MB then the size is the flash less that used by the firmware and 12Kb. Otherwise it is all of the Flash available above the 1MB boundary.

This is because pre SDK 3.0 5 × 4Kb pages were reserved from 0x0FB00 - 0x0FFFF for system pages, and any SPIFFS region must be contiguous, hence SPIFFS either had to sit below this hole or above it. With the introduction of the Partition Table in SDK 3.0, these pages were moved to an unused flash window 0x00B00 - 0x00FFF, making the entire Flash region above the firmware (and LFS) available for SPIFSS. This above or below 1Mb is obsolete.

Hence my recommendation here is that:

  1. We drop the confusing -F and -Uoptions.
  2. The SPIFFS size is set by the c`option (or by the file size if an existing SPIFFS image, but that k,K,m and M suffices are allowed with the conventional meaning.
  3. We drop the option to embed the -U address in the SPIFFS filename. This implies that SPIFFS uses absolute addresses; it doesn't, and some script or node API call will typically compute FS start address anyway; the developers no longer need to work this out themselves.
  4. The code contains Posix (mmap()and MSC (open, read, update, write) variants for accessing the SPIFFS image. The MSC approach works fine on Linux systems so just use this one approach.
  5. The code mallocs temporary buffers without status return checking. Just use static allocation.

Anyway unless anyone objects I will tidy this all up. I suggest we leave this work until after the coming master drop.

jmattsson commented 4 years ago

MSC... Mass Storage Controller, Mobile Switching Center, Microsoft Superior C, umm.. I'm drawing a blank here? If you're referring to fopen() and co, then *Mumble-something* Standard C?

That aside, no objections from me. As you say, this is all for legacy reasons, and if it's no longer of use, then it can certainly be tidied up. Thanks for checking! :)

TerryE commented 4 years ago

MSC = Microsoft C that is compiled to run on a native Window environment rather than WSL etc.

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

TerryE commented 2 years ago

Still an issue