Repository navigation
Give the 8MB boards a filesystem that fits - #16
Conversation
spiffs on custom_8mb.csv was 1MB, sized back in v1.3.1 when data/ was around 650KB. data/ has since grown to 907KB on v1.7.3, and LittleFS rounds every file up to a 4096-byte block, so the AIO image now lands at roughly 95% full and any further UI work fails to build with "No more free space". Nothing was using the 2.94MB of the 8MB chip past 0x510000, and the layout was lopsided: the 4MB SuperMini already gets 1.4MB of filesystem and the 16MB XIAO S3 Plus gets 2MB, so the 8MB boards had the smallest filesystem of any target. spiffs is now 0x3E0000 (3.875MB), which takes the image to about 25% full, and the last 64KB becomes a coredump partition so panics leave a backtrace. nvs, otadata, app0 and app1 keep their original offsets and sizes, so an OTA app update still lands correctly and saved settings survive. spiffs keeps its 0x410000 offset, so the documented esptool command and the per-release FLASH_INSTRUCTIONS.txt are unchanged. Devices that OTA-update only the app keep their old 1MB table and need one full reflash before they can take a filesystem image built against this one. That needs calling out in the release notes for whichever version ships it. Verified: FPVGateAIO, ESP32S3 and FPVGateSolo all build a 4,063,232 byte image.
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
spiffsoncustom_8mb.csvis 1 MB. It was sized in v1.3.1, whendata/wasaround 650 KB.
data/is now 907 KB on v1.7.3, and LittleFS rounds every file upto a 4096-byte block, so the filesystem image is roughly 95% full and any further
UI work fails to build:
That is not hypothetical — it currently blocks #15.
Why the table, rather than shrinking
data/Nothing was using the 2.94 MB of the 8 MB chip past
0x510000, and the layout waslopsided. The 4 MB SuperMini already gets 1.4 MB of filesystem and the 16 MB
XIAO S3 Plus gets 2 MB, so the 8 MB boards had the smallest filesystem of any
target.
spiffsbecomes0x3E0000(3.875 MB), which takes the image to about 25% full,and the last 64 KB becomes a
coredumppartition so panics leave a backtrace.The table now ends exactly at
0x800000.Compatibility
nvs,otadata,app0andapp1keep their original offsets and sizes, soan OTA app update still lands correctly and saved settings survive.
spiffskeeps its0x410000offset, so the documented esptool command,.github/workflows/manual-release-build.ymland every per-releaseFLASH_INSTRUCTIONS.txtare unchanged.Affects all seven targets using
custom_8mb.csv: FPVGateAIO, FPVGateLCDAIO,FPVGateSolo, ESP32S3, SeeedXIAOESP32S3, LilyGOTEnergyS3, WaveshareESP32S3LCD2.
Release note required
A device that OTA-updates only the app keeps its old 1 MB table, so it cannot take
a filesystem image built against this one. Those users need one full reflash
(bootloader + partitions + firmware + littlefs) to migrate. This must be called
out in the release notes for whichever version ships it.
Verified
FPVGateAIO,ESP32S3andFPVGateSoloall build a 4,063,232 byte image.Flashed to an AIO: the self test reports
LittleFS Total: 3968KB, Used: 1028KB, R/W OKandStorage Type: SD, and the web UI serves normally.