Skip to content

stm32: Generalise flash mounting code so it supports arbitrary FS. #5299

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Nov 25, 2019
Merged

stm32: Generalise flash mounting code so it supports arbitrary FS. #5299

merged 1 commit into from
Nov 25, 2019

Conversation

dpgeorge
Copy link
Member

@dpgeorge dpgeorge commented Nov 6, 2019

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:

  1. the existing flash block device has a partition table at the first block, and littlefs won't work with this
  2. the existing flash block device has a block size of 512 bytes, not the native 4k (or otherwise) of external SPI flash, so littlefs must still go through the block device's cache

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.

@dpgeorge
Copy link
Member Author

dpgeorge commented Nov 6, 2019

@andrewleech the patch here is inspired by your 1c04d8a "stm32/main: Simplify definition of root filesystem."

@andrewleech
Copy link
Contributor

I did wonder what was using the fake partition map, it makes sense that mass storage needs it.
I really like the idea of eventually moving to a ghostfat for the mass storage, eg.
https://github.com/microsoft/uf2-nrf5/blob/master/src/ghostfat.c
https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/master/src/usb/uf2/ghostfat.c

By handling the read_block(), write_block() callbacks, the code in ghostfat.c emulates a 4 MB flash drive formatted with the FAT filesystem (sector size 512). The Blue Pill hardware doesn’t actually have 4 MB of storage. When we copy a UF2 file into the drive for flashing, ghostfat.c will read in 1 sector (512 bytes) from the computer, write the 512 bytes into flash memory, and repeat until the entire UF2 file is processed.

That way littlefs can still be exposed to mass storage, but more safely managed to avoid filesystem contention.
Looking a little closer, I'm not sure it's that easy. Those ghostfat implementations aren't really designed to translate entire filesystems with multiple folders/files, just show a couple of hardcoded template files and accept one new (firmware) file to be written.

But I digress...

I do think the auto-detection is a really nice touch.
Even if micropython eventually went to littlefs as the default then the auto-detect would ease the transition for people upgrading existing boards.

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.

@dpgeorge dpgeorge mentioned this pull request Nov 14, 2019
Merged
@dpgeorge
stm32: Generalise flash mounting code so it supports arbitrary FS.
7723dac 
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.
@dpgeorge dpgeorge force-pushed the stm32-generalise-flash-mount branch from ed8e4de to 7723dac Compare November 25, 2019 07:11
@dpgeorge dpgeorge merged commit 7723dac into micropython:master Nov 25, 2019
@dpgeorge dpgeorge deleted the stm32-generalise-flash-mount branch November 25, 2019 07:42
kamtom480 pushed a commit to kamtom480/micropython that referenced this pull request Sep 6, 2021
@microdev1
Merge pull request micropython#5299 from Neradoc/nera-rework-board-dicts
7ce3f25 
change board dicts to include a common macro with __name__
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
port-stm32
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@dpgeorge @andrewleech
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy