* Closes https://github.com/espressif/esp-idf/issues/12849
In former versions of ESP-IDF, the user custom memory data in the retained memory
was taken into account during the CRC calculation. This was changed in a later
commit, the custom memory was ignored, therefore this can seen as a breaking change.
This commit gives the possibility to choose between the former (legacy) or new way of calculating the CRC.
This fix ensures that https://nvd.nist.gov/vuln/detail/CVE-2020-27209 is not
reported by the ESP-IDF SBOM tool. Please note that, this CVE was anyways not
applicable for ESP32 platform, as the bootloader (user of micro-ecc library)
do not perform signing on the device, its only verification that happens in
secure-boot-v1 case.
Simple flash read command is not supported if Secure DL mode is enabled on the target.
Remove reference of this from the relevant docs part.
Related: https://github.com/espressif/esptool/issues/810
Related: ESPTOOL-567
Closes IDF-6468
User's custom data are not taken into account during the CRC calculation anymore.
Which means taht the retained mem structure is not systematically erased
on each reboot anymore.
Adding prop and lit sections to the ELF will let the debugger and the disassembler
have more info about data bytes present in the middle of the Xtensa
instructions, usually used for padding.
The change fixes thread-local-storage size by removing .srodata section
from it. It initially was included in TLS section by mistake.
The issue was found when stack size increased after building applications
with GCC-11.1 compiler. Stack size became bigger because some new data
appeared in .srodata. See more details here:
adce62f53d
The previously used splits between memory allocated for ROM code,
2nd stage bootloader and the app were somewhat safe and conservative.
This resulted in some space being unavailable for static allocation
in the app.
This commit increases the space available for static allocation to the
maximum possible amount.
1. Some of the ROM code static allocation is only used in UART/USB/SPI
download modes. This region ("shared buffers") has been placed at
the lower end of ROM memory area, to be reusable in flash boot
mode. The 2nd stage bootloader linker script is modified to "pack"
all sections exactly up to the end but with roughly 8K margin between
startup stacks.
2. Instead of calculating the sections placement and hardcoding the
addresses in the LD script again, rewrite it to calculate the
start address of each memory region automatically based on the
logic above.
3. Adjust the app memory layout (SRAM_IRAM_END) accordingly,
increasing the space available for static allocation.
Overall these changes increase the space available for static
allocation by about 78kB.
The downside of these changes is that the 2nd stage bootloader .data
segment is now directly adjacent to the startup stack on the PRO CPU.
Previously, there was effectively about 78kB of extra stack space for
the PRO CPU, before the stack would run into the data segment.
ROM code doesn't allow loader stub to be executed in case secure boot in
enabled. Providing --no-stub flag to esptool allows user to flash new
firmware, given download mode hasn't been disabled
- Add to docs & config descriptions
- Change to a "choice" to become self-documenting
- Keep the bootloader_common_check_long_hold_gpio() function for compatibility
Add the possibility to have user bootloader components. This is performed
from an application/project, by creating bootloader components. To do so,
it is required to create a `bootloader_component` directory containing
the custom modules to be compiled with the bootloader.
Thanks to this, two solutions are available to override the bootloader now:
- Using hooks within a user bootloader component
- Using a user defined `main` bootloader component to totally override the
old implementation
Please check the two new examples in `examples/custom_bootloader`
* Closes https://github.com/espressif/esp-idf/issues/7043
