LP core was unable to boot when system was in deepsleep.
This was due to lp uart init in LP rom using XTAL as clk source,
which is normally powered down during sleep.
This would cause lp uart to get stuck while printing ROM output,
and the app would never boot.
Also fixed wrong wakeup cause used by HP core for ULP wake up
otherwise due to esp-idf using -Werror, we can get errors in code which
uses HAL_ASSERT if for example the compiler believes that a variable is
used uninitialised, or similar.
Inspired by https://github.com/espressif/esp-idf/pull/13256
This commit introduce SOC_MEM_NON_CONTIGUOUS_SRAM flag (that enebled for
esp32p4). If SOC_MEM_NON_CONTIGUOUS_SRAM is enabled:
- LDFLAGS+=--enable-non-contiguous-regions
- ldgen.py replaces "arrays[*]" from sections.ld.in with objects under
SURROUND keyword. (e.g. from linker.lf: data -> dram0_data SURROUND(foo))
- "mapping[*]" - refers to all other data
If SOC_MEM_NON_CONTIGUOUS_SRAM, sections.ld.in file should contain at
least one block of code like this (otherwise it does not make sense):
.dram0.bss (NOLOAD) :
{
arrays[dram0_bss]
mapping[dram0_bss]
} > sram_low
.dram1.bss (NOLOAD) :
{
/* do not place here arrays[dram0_bss] because it may be splited
* between segments */
mapping[dram0_bss]
} > sram_high
This commit replaces the use of portNUM_PROCESSORS and configNUM_CORES
macros in all of ESP-IDF. These macros are needed to realize an SMP
scenario by fetching the number of active cores FreeRTOS is running on.
Instead, a new Kconfig option, CONFIG_FREERTOS_NUMBER_OF_CORES, has been
added as a proxy for the FreeRTOS config option, configNUMBER_OF_CORES.
This new commit is now used to realize an SMP scenario in various places
in ESP-IDF.
[Sudeep Mohanty: Added new Kconfig option CONFIG_FREERTOS_NUMBER_OF_CORES]
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
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.
