bavis-m
commented
2 years ago Oops, my bad, I'll remove that debug when I'm back at my machine. I can definitely make littlefs try and write to a sector that it believes should be empty but that mklittlefs has written out with 0x00. I haven't had the time to do a full deep dive, but I think it might be related to writing/updating inline files. I can privide a test case if you like where the output of lfs_flash_erase definitely makes it to the output image.
On Sun., Jun. 19, 2022, 9:13 a.m. Earle F. Philhower, III, < @.***> wrote:
@.**** requested changes on this pull request.
Thanks, but it really doesn't matter what lfs_flash_erase is doing here. It could probably be a no-op, in fact. LittleFS calls lfs_flash_erase (because it was built for flash and flash needs erase before write) and then overwrites the erase values completely since it never does partial writes.
There's also a new unneeded debug message in your PR.
— Reply to this email directly, view it on GitHub https://github.com/earlephilhower/mklittlefs/pull/27#pullrequestreview-1011544454, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABXE2KJSZGMCREFE53TULVTVP5BLJANCNFSM5ZF35VIQ . You are receiving this because you authored the thread.Message ID: @.***>
mklittlefs seems to assume it's being used on flash memory that erases to 0xFF (based on the initial contents of s_flashmem), but the lfs_flash_erase call writes 0x00 to the image. Perhaps the two options could be set based on a flag? In any case, it seems like lfs_flash_erase should at least match the initial values of s_flashmem, whether or not it's 0x00 or 0xFF.