Some additional checks related to secure version of the application in
anti-rollback case have been added to avoid any attempts to boot lower
security version but valid application (e.g., passive partition image).
- Read secure_version under sha256 protection
- First check has been added in the bootloader to ensure correct secure
version after application verification and loading stage. This check
happens before setting up the flash cache mapping and handling over
the final control to application. This check ensures that application
was not swapped (e.g., to lower security version but valid image) just
before the load stage in bootloader.
- Second check has been added in the application startup code to ensure
that currently booting app has higher security version than the one
programmed in the eFuse for anti-rollback scenario. This will ensure
that only the legit application boots-up on the device for
anti-rollback case.
1. Fix deep sleep wakeup IOs can not be unhold issue
2. Correct hold related APIs' description
3. Fix gpio_force_hold_all API
docs: Add GPIO wakeup source to sleep_modes doc for ESP32C3
Before this fix, when we call esp_pm_configure after gpio_wakeup_enable,
the configuration of GPIO in sleep state in gpio_wakeup_enable will be
overwritten by esp_pm_configure.
When stack check is enabled, certain functions (sometimes placed in RAM)
are being decorated with stack guards and a call to __stask_chk_fail() in
case ofr stack corruption. For this reason, __stack_chk_fail() must be
placed in RAM too.
Add stack check config in heap tests on all targets to find eventual flash to RAM
calls due to stack checks when running callgraph_check.py
If a windowoverflow8 happened after changing the SP, the exception handler would look for
the extra save area by looking at the previous frame's SP. This SP would be a garbage value
and could cause the windowoverflow exception to write to invalid memory ares.
sizeof(time_t) was previously switched from 4 to 8, ROM functions that use
time_t or dependent types (such as "struct stat") are no longer called due as
they still treat sizeof(time_t) as 4 (see commit
24c20d18).
However, there is a ROM callpath that was left out. If putchar is the first
stdio print related call, the call path will result in cantwrite() ->
__swsetup_r() -> __smakebuf_r() -> __swhatbuf_r() using the ROM "struct stat"
(where sizeof(time_t)==4).
Instead of removing all printf related ROM newlib functions (which will result
in increased binary size), this commit adds a workaround to setup the stdio
files before any print related calls occur.
This results in cantwrite() always returning false, thus the callpath described
above never being reached.
Closes https://github.com/espressif/esp-idf/issues/9269
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.
Functions used for burning this efuse would log, but at this point
esp_log is not initialized. Moved to a later point in the startup process.
Closes https://github.com/espressif/esp-idf/issues/9457
Was: Backtrace: N:M N:M N:M ...
Now: Backtrace:N:MN:M N:M ...
The problem with the new format is that it is hard to parse and
breaks the parser that is used by PlatformIO. The old format
is much more reasonable. I do not see how the pattern in IDFDUT.py
can work with the new format, due to the missing space after the :
1. Rename MACROs SYSTEM_WIFI_RST_EN register bit fields to be more recognizable
2. reset Bluetooth baseband and MAC bits to fix the issue of task watchdog triggered during controller initialization due to invalid hardware state
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.
