Moved the following kconfig options out of the target component:
* CONFIG_ESP*_DEFAULT_CPU_FREQ* -> esp_system
* ESP*_REV_MIN -> esp_hw_support
* ESP*_TIME_SYSCALL -> newlib
* ESP*_RTC_* -> esp_hw_support
Where applicable these target specific konfig names were merged into
a single common config, e.g;
CONFIG_ESP*_DEFAULT_CPU_FREQ -> CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ
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
Additionally, always enable the partition MD5 check if flash encryption is on in
Release mode. This ensures the partition table ciphertext has not been modified
(CVE-2021-27926).
The exception is pre-V3.1 ESP-IDF bootloaders and partition tables, which
don't have support for the MD5 entry.
* Patched longjmp to be context-switch safe
longjmp modifies the windowbase and windowstart
registers, which isn't safe if a context switch
occurs during the modification. After a context
switch, windowstart and windowbase will be
different, leading to a wrongly set windowstart
bit due to longjmp writing it based on the
windowbase before the context switch. This
corrupts the registers at the next window
overflow reaching that wrongly set bit.
The solution is to disable interrupts during
this code. It is only 6 instructions long,
the impact shouldn't be significant.
The fix is implemented as a wrapper which
replaces the original first instructions of
longjmp which are buggy. Then, it jumps back
to execute the rest of the original longjmp
function.
Added a comparably reliable test to the
test apps.
