Repository navigation
stm32: Generalise flash mounting code so it supports arbitrary FS. - #5299
Conversation
|
@andrewleech the patch here is inspired by your 1c04d8a "stm32/main: Simplify definition of root filesystem." |
|
I did wonder what was using the fake partition map, it makes sense that mass storage needs it.
That way littlefs can still be exposed to mass storage, but more safely managed to avoid filesystem contention. But I digress... I do think the auto-detection is a really nice touch. It might make sense for block devices to have configurable block sizes (another ioctl?) so better manage issues like this where different file systems prefer different sizes. |
This commit refactors and generalises the boot-mount routine on stm32 so that it can mount filesystems of arbitrary type. That is, it no longer assumes that the filesystem is FAT. It does this by using mp_vfs_mount() which does auto-detection of the filesystem type.
ed8e4de to
7723dac
Compare
change board dicts to include a common macro with __name__
2 participants
This PR refactors and generalises the boot-mount routine on stm32 so that it can mount filesystems of arbitrary type. Ie it no longer assumes that the filesystem is FAT.
It does this by using
mp_vfs_mount()which does auto-detection of the filesystem type.The idea with this is that the user could reformat the flash filesystem with littlefs (or other FS type) and then it would "just work". So the could would support both FAT at littlefs, it just depends how the flash is formatted.
But there are two problems with getting this latter part working:
To fix (1) requires splitting out the partition table. Since it's only really needed by the USB MSC, it's possible to split this partition stuff out from the storage driver (storage.c) and put it in the USB driver (usbd_msc_interface.c). That would then free up storage.c to abstract just the blocks on the block device(s).
To fix (2) is difficult. For the auto-mount code it would mean that the block size (and hence the block device) depends on the filesystem type (almost a chicken and egg problem). A simple way forward would be to just use a 512 block size for littlefs, and make it go through the flash write cache (this should work ok). Or switch to 4096 block size, but then FAT FS needs 4k blocks and is rather inefficient (although that's what esp8266 and esp32 do).
Things are simpler if there's no auto-detection. Then the user would need to configure the filesystem type at compile time. This PR would still be useful for that approach.