Max number of partitions that can be mmaped

[vvb333007]

Hello,

I'd like to mmap() 5 partitions at one time on ESP32-S3. Total partitions size is 8MiB. Am I correct in assumption that ESP32S3 MMU can manage up to 128*64KiB of mmaped data pages at maximum?

My aim is to mmap() 5 partitions and use them as data arrays. The TOTAL size of all partitions is 8Mb. Is this doable?

Also:

Documentation says that there is 24 MiB of INSN virtual space and 8MiB of data. Since my SoC has 8MB of PSRAM - where I can mmap my partitions? Or I completely misumderstood docs.

Docs says that there are 384 records in MMU which yield 24MiB of instruction virtual addresses. The rest (8MiB is for DATA). PSRAM is mmaped to the DATA region. Should I mmap my partitions to the INSN bus? Yes, I'll loose ability for byte-access but it is ok for my project.


Can someone explain this MMU magic?

[RathiSonika]

Hello,

Yes — mapping five partitions totaling 8 MiB on ESP32-S3 is generally possible. There is no fixed limit on the number of partitions; the real constraint is how many free 64 KB MMU pages remain after boot.

The ESP32-S3 has 512 MMU entries and uses 64 KB pages, giving a theoretical maximum of 32 MB of simultaneously mapped external memory (512 × 64 KB). In practice, flash and PSRAM share this same MMU entry pool. Mapping 8 MiB requires about 128 MMU pages, but those pages are also consumed by flash XIP (application code), .rodata, PSRAM (8 MiB PSRAM uses roughly 128 pages), and any additional esp_partition_mmap() / spi_flash_mmap() calls. Five separate mappings may also use more pages than the raw data size because each mapping is rounded up to 64 KB boundaries.

Rather than assuming a fixed limit, check available pages at runtime:

Code: Select all

uint32_t free_pages = spi_flash_mmap_get_free_pages(SPI_FLASH_MMAP_DATA);

Regarding “24 MiB instruction / 8 MiB data”: that model fits original ESP32 better than ESP32-S3. On ESP32-S3, instruction and data accesses use separate virtual address ranges, but both rely on the same underlying MMU page table. For read-only data stored in flash, use ESP_PARTITION_MMAP_DATA rather than ESP_PARTITION_MMAP_INST. ESP_PARTITION_MMAP_DATA supports byte-aligned access, which is appropriate for arbitrary data arrays. ESP_PARTITION_MMAP_INST is intended for instruction-style access and supports only 4-byte-aligned reads.

[vvb333007]

Thanks for the reply!

So if I ran out of free DATA pages it is completely ok to mmap() to the INST pages, just make sure the access is 32-bit only and must be aligned? Thats great news!

[RathiSonika]

Not really — on ESP32-S3 this usually does not give you extra mmap capacity. SPI_FLASH_MMAP_DATA and SPI_FLASH_MMAP_INST are not two independent pools of MMU entries. They use the same underlying MMU/linear address space; the difference is mainly:
* which virtual address range you get (0x3C… for DATA vs 0x42… for INST)
* what access type is allowed

Both spi_flash_mmap_get_free_pages(SPI_FLASH_MMAP_DATA) and spi_flash_mmap_get_free_pages(SPI_FLASH_MMAP_INST) call the same allocator and should normally return the same free budget. You can verify with:

ESP_LOGI("mmap", "DATA pages: %" PRIu32, spi_flash_mmap_get_free_pages(SPI_FLASH_MMAP_DATA));
ESP_LOGI("mmap", "INST pages: %" PRIu32, spi_flash_mmap_get_free_pages(SPI_FLASH_MMAP_INST));

So if DATA pages are exhausted, switching to INST will not magically unlock another 32 MB on ESP32-S3.