About bootloader mmap_mmu_size (IDFGH-14346)

[learnerzcz]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I know the bootloader offset is 0x1000, and flash start flash is 0x3f400000. i found that the bootloader_override demo use function to read bootloader header. it use the FLASH_READ_VADDR to map . why the addr is 0x3f400000 +0x320000

#define MMU_BLOCK0_VADDR SOC_DROM_LOW
#define MMAP_MMU_SIZE (0x320000)
#define MMU_BLOCK50_VADDR (MMU_BLOCK0_VADDR + MMAP_MMU_SIZE)
#define FLASH_READ_VADDR MMU_BLOCK50_VADDR

[ginkgm]

Hi @learnerzcz ,

The code you pasted seems to be a little different if I understand correctly: https://github.com/espressif/esp-idf/blob/master/components/bootloader_support/bootloader_flash/src/bootloader_flash.c#L171

The original code is a bit confusing. What the bootloader does is using one of the page (and only one page) to do the mmap and read from the flash. The address is for the 50th page so it's address is 0x10000 * 50.

[ginkgm]

Which exact page to use doesn't matter that much. I think it's just using the last available page.

[learnerzcz]

Thank you for your reply @ginkgm . But i am still confused ,the api guider descripted the booloader location. like the below screen shot .Can you give me more information ,so that can help me understand the code. Like the vaddr and paddr how to consist the memony map. Thank you !

[learnerzcz]

@ginkgm I reviewed the code that refer the FLASH_READ_VADDR. the function cache_flash_mmu_set have parameters two of them are vaddr and paddr . the description of them are vaddr : virtual address in CPU address space.Can be IRam0, IRam1, IRom0 and DRom0 memory address.Should be aligned by psize. paddr : physical address in Flash. Should be aligned by psize.
Can i understand that we use virtual address to map physical address. the virtual address is D (63) bootloader_flash: map_ptr=3f721000

But the addr in technical_reference_manual is still external flash.

[ginkgm]

some partitions contain images, for example, 2nd bootloader, factory and ota1/2.

each image partition has some segments, these segments are to be loaded to internal RAMs or mapped by the MMU and access by the cache.

Please see: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/bootloader_image_format.html and https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/app_image_format.html for more about image format.

Address of 2nd bootloader image (0x1000) is totally unrelated to the MMU. it's hardcoded in 1st bootloader. 1st bootloader copies the contents from this address to RAM of the given address specified in the segments.

Later in 2nd bootloader, it make use of the 50th MMU page to do calculations and maybe copy data from flash to internal RAMs. Please note that, this MMU page has a fixed virtual address (50th page), this address is unrelated to the segment, physical address of data to read from, or address to copy to. After each step of calculation and copying, the page is unmapped for reuse.

Another major work of the 2nd bootloader is to setup the MMU mmaping for the app. The used MMU pages used is related to the virtual address to mapped to, determined at build time. The linker allocates static const code and data from the first MMU page, until the 49 page. This is why we choose to use the last page in the step above (hence you will never see this virtual address used in any segment). This mapping will not be unmapped, unlike the 50th page, which is recycled after use.

[learnerzcz]

Thank you for your response @ginkgm I already have a basic understanding.