mirror of
https://github.com/espressif/esp-idf.git
synced 2026-10-18 19:43:17 +03:00
kxt116
015fc10486
SRAM_MAIN_END is documented as the 2nd stage bootloader iram_loader_seg start address, but it still holds the value from before6b417e9d47, which raised bootloader_iram_loader_seg_len from 0x7000 to 0x8000 and moved that address down by 4 KB. That commit updated BOOTLOADER_IRAM_LOADER_SEG_START_EXPECTED in bootloader.memory.ld.in and SRAM_END / SRAM_LOW_END in memory.ld.in, but ld.hp_mem_defs, added two months earlier by261bd160aa, was missed: rev < 3 : asserted 0x4FF2BBD0, SRAM_MAIN_END 0x4FF2CBD0 rev >= 3: asserted 0x4FFADFC0, SRAM_MAIN_END 0x4FFAEFC0 0x4FFADFC0 is derived at link time from bootloader_usable_dram_end minus the stack overhead, dram_seg and iram_loader segments, so it is not an extra reservation - the two constants are meant to be equal, as the comment above the ASSERT states. With CONFIG_ULP_COPROC_RUN_FROM_HP_MEM the ULP HP reservation therefore ends 4 KB inside the bootloader's iram_loader_seg (0x4FFADFC0..0x4FFAEFC0), which that same script declares off limits for the application, and SRAM_END / SRAM_LOW_END, derived from ULP_HP_MEM_START, end 4 KB higher than intended. The default build does not reference SRAM_MAIN_END at all. Also extend the sync comment in bootloader.memory.ld.in to list ld.hp_mem_defs, so the next change to the segment lengths updates every consumer. Verified for L2 128 KB and CONFIG_ULP_COPROC_RESERVE_HP_MEM_BYTES=0x10000: before: ULP block [0x4FF9EFC0, 0x4FFAEFC0) -- overlaps iram_loader_seg by 0x1000 after: ULP block [0x4FF9DFC0, 0x4FFADFC0) -- abuts iram_loader_seg exactly Closes https://github.com/espressif/esp-idf/issues/19133 Merges https://github.com/espressif/esp-idf/pull/19135