SRAM_MAIN_END is documented as the 2nd stage bootloader iram_loader_seg start address, but
it still holds the value from before 6b417e9d47, 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
by 261bd160aa, 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
ESP_FAULT_ASSERT(C) was silently deleted by the optimizer when C is a cached
flag/status already proven by a preceding `if (!C) return/goto`: the compiler
folds C to a constant and drops all three checks, removing the fault-injection
protection with no warning.
Commit 69d548c8 ("feat(esp_security): suppoer s31 security clock
management") introduced a new esp_crypto_clk source file in esp_security
but did not add it to the bootloader loader IRAM input sections. As a
result the crypto clock code was not placed in the loader IRAM region,
causing a regression on targets that use it during bootloader load.
Add *libesp_security.a:esp_crypto_clk.* to the bootloader sections
linker fragments for all targets that carry the esp_security.a
dependency (esp32c5, esp32p4, esp32s31), placed alongside
esp_crypto_periph_clk.
Replaced per-target bootloader.ld.in with bootloader.memory.ld.in and
bootloader.sections.ld.in.
Common code moved to file bootloader.sections.common.ld
Unify ESP32-P4 ECO4- and ECO4+ linker scripts into one shared script
Revision-specific code is selected with CONFIG_ESP32P4_SELECTS_REV_LESS_V3
For bin log, reserve the first 4 bytes as zero for variables that are pointed to NULL
and should not be printed in the log. So the esp-idf-monitor will skip printing
those variables.
kxt116
morris
Stefan Stipanovic
Ashish Sharma
harshal.patil
Mahavir Jain
nilesh.kale
Alexey Lapshin
Laukik Hase
Song Ruo Jing
armando
Aditya Patwardhan
wuzhenghui
C.S.M
Konstantin Kondrashov
Marius Vikhammer
laokaiyao
Chen Jichang
gaoxu
Omar Chebib
wanlei