This commit adds the ability to set the core affinity for the FreeRTOS
Timer Service task when multi-core configuration is enabled. This commit
also adds a Kconfig option to set the core affinity of the timer task
via the menuconfig.
Closes https://github.com/espressif/esp-idf/issues/10315
From: Arno Moonen <arno.moonen@airios.eu>
Follows original message from Arno Moonen <arno.moonen@airios.eu>
While integrating the ESP-IDF into our existing CMake structure,
I've come across quite some hurdles. Most I've been able to fix
in our CMake files, however this one I could not.
Most of the targets created by the esptool_py component assume
that the EXECUTABLE IDF build property (which contains the name
of the CMake executable target) always equals the name of the
created binary.
This is however not always true. For instance, in our setup we use
CMAKE_EXECUTABLE_SUFFIX_C and CMAKE_EXECUTABLE_SUFFIX_CXX in our
toolchain file (both set to .elf). If we do add_executable(my_app),
the target binary file would actually be my_app.elf.
In order to fix this, I've updated it to use the TARGET_FILE generated
expression. That way we also no longer need the EXECUTABLE_DIR IDF build
property here.
I've fixed this on v5.0.1 (as that's the ESP-IDF version I'm currently
trying to integrate), but I assume it should be easy to apply the same
fix to newer versions and the master branch as well.
Note that this problem might exist in multiple places where EXECUTABLE
is being used. While going through the ESP-IDF code base, I even noticed
that a few places actually already seem to use the TARGET_FILE expression.
To be honest the property name might be somewhat confusing as well, as it
is actually the executable target.
Closes https://github.com/espressif/esp-idf/pull/12558
This commit fixes memory leaks in unity tests when the debug option
CONFIG_FREERTOS_USE_LIST_DATA_INTEGRITY_CHECK_BYTES is enabled. The
commit increases the threshold to 1200 bytes from 1024 bytes.
- Add ECDSA peripheral chapter and instructions to program efuse key block
- Update security guide for ECDSA peripheral mention for device identity
- Link with ESP-TLS guide about using ECDSA peripheral in TLS connection
For ESP32-H2 case, the hardware k mode is always enforced through
efuse settings (done in startup code).
For ESP32-P4 case, the software k mode is not supported in the peripheral
itself and code was redundant.
In ESP32-H2, the ECDSA peripheral by default uses the TRNG (hardware)
generated k value but it can be overridden to software supplied k.
This can happen through by overriding the `ECDSA_SOFTWARE_SET_K` bit
in the configuration register. Even though the HAL API is not exposed
for this but still it could be achieved by direct register
programming. And for this scenario, if sufficiently random k is not
supplied by the software then it could posses a security risk.
In this change, we are unconditionally programming the efuse
`ESP_EFUSE_ECDSA_FORCE_USE_HARDWARE_K` bit during startup security
checks itself. Additionally, same is ensured in the `esp_efuse_write_key`
API as well. This always enforces the hardware k mode in the ECDSA
peripheral and ensures strongest possible security.
This commit adds a taskVALID_CORE_ID() macro, similar to the one offered in
Amazon SMP FreeRTOS.
- Various functions have been updated to use that macro
- Removed some unecessary static asserts of CONFIG_FREERTOS_NO_AFFINITY and
added casting.
- Uncrustify changes
