FS Cache on internal flash

[victorallume]

For devices with internal flash enabled, micropython compiles in flashbdev.c which includes caching of flash into an area of RAM defined in the linker file at _micropy_hw_internal_flash_storage_ram_cache_start (and end).

What would be the implications of disabling this cache, or if that's not advisable, is reducing it considerably?

I can't find a direct way to do it, but setting _micropy_hw_internal_flash_storage_ram_cache_start and _micropy_hw_internal_flash_storage_ram_cache_end to be the same value should effectively disable it (from my understanding of the code). Does this sound like a reasonable approach?

Why is external flash not similarly cached?

[jimmo]

hi @victorallume

The reason for the flash cache is because the internal flash on STM32 parts uses enormous sector sizes (8-16kiB is not uncommon, but up to 128kiB in some parts), while the filesystem works in blocks that can be more like 512B (e.g. for FAT). So the problem we have is that the filesystem layer issues a write for a block, but we can only erase the entire sector, so first we need to copy the original sector, update the subsection with the block, then write the whole sector out.
That would be extremely inefficient, so we only write the sector out again when either a timer elapses or a write comes in for a block in a different sector.

External flash typically has much smaller erase sizes, however we still do support a cache for these (typically 4kiB). See MICROPY_HW_SPIFLASH_ENABLE_CACHE which is enabled on PYBD for example (and the implementation in drivers/memory/spiflash.h).

With filesystems like LittleFS, it's able to understand this sort of flash geometry, so I don't think the cache is strictly necessary (i.e. it understands that erases are disconnected from writes). But because we support switching at runtime between LittleFS and FAT the cache infrastructure stays there.

Right now, there's actually not much to be gained by disabling the cache because we put it in CCRAM which is currently inaccessible to the heap as it's dis-contiguous from SRAM. This is also what restricts the size of the filesystem on some devices -- in the linker script we assign sectors of flash to either the filesystem or firmware. Only sectors that are smaller or the same size as CCRAM can be used for the filesystem. (Technically we can use larger ones but then the rest of the sector goes wasted as we can only use up to CCRAM bytes from it).

However

1. Since all this was implemented we've added support for "split heap", so it's now possible to have part of the heap in CCRAM.
2. We could also move a bunch of stuff that's currently in .bss and .data (e.g. VM state) into CCRAM.

So it would be very worthwhile to do some experiments with STM32 builds that only support LittleFS on their internal flash that use the CCRAM to gain a performance advantage.

[victorallume]

Thanks for the detailed reply! I am indeed using the split heap feature.

Just to clarify: I'm using the STM32H743, which has a 128kiB sector erase; do I understand correctly that in order to change anything on it's internal flash, micropython needs to read that entire 128kiB sector, change the required bits, then write it all back? So it needs a dedicated 128kiB RAM to perform this operation?

While if I'm using SPI flash with a 4kiB erase instruction, that 4kiB can be dynamically allocated?

[jimmo]

Just to clarify: I'm using the STM32H743, which has a 128kiB sector erase; do I understand correctly that in order to change anything on it's internal flash, micropython needs to read that entire 128kiB sector, change the required bits, then write it all back? So it needs a dedicated 128kiB RAM to perform this operation?

Yep. 🤯 (This is partly why ST added the H7Ax and H7Bx parts, they have 8kiB erase sectors. Their marketing material talks about this being important for OTA updates, which is kind of the same thing as what we're talking about here)

The h743 has 128kiB DTCM so that's why this works.

As to why it has to work this way:

• FAT has no way to deal with anything other than 512B blocks.
• LittleFS can only do its clever thing when the LFS block size matches the erase size. This works great for external flash (4kiB LFS block size). So you could in theory have the LFS block size set to 128kiB. But an LFS block can only store data for one file, so this would be basically useless.

While if I'm using SPI flash with a 4kiB erase instruction, that 4kiB can be dynamically allocated?

It's not dynamic, it's in .bss.