1) In the ESP32-P4 SoC, we have an eFuse to disable the MSPI access
when in download mode. This commit adds relevant soc cap for esp32p4
chip.
2) Added FE related soc caps
3) Removed unwanted cap from soc_caps
4) esp_hw_support: Enable flash encryption related ll APIs for esp32p4
Sphinx would "smartly" format e.g. double dashes into typographically correct entities,
i.e. a long dash unicode character.
This doesnt always work well for our docs were sometimes a double dash could be a python
argument, which when copied would no longer work.
Fixed assert when LLCP instant passed on ESP32-C3 and ESP32-S3(b8f0db9)
Closes BLERP-298, BLERP-299, BLERP-300, BLERP-301, BLERP-310, BLERP-311, and BLERP-312
See merge request espressif/esp-idf!27477
Previously, documentation sections that were only meant for multicore ESP
targets would use tags that depend on CONFIG_FREERTOS_UNICORE or
CONFIG_ESP_SYSTEM_SINGLE_CORE_MODE. This is not ideal as project configuration
can be changed by the user.
This commit updates those tags to use SOC_HP_CPU_HAS_MULTIPLE_CORES which is
always defined in multicore targets regardless of project configuration.
This commit adds a the SOC_HP_CPU_HAS_MULTIPLE_CORES convenience macro to
soc_caps.h. This is a convenience boolean cap to represent whether or not the
target has multiple cores, and is intended to be used when writing docs for
multiple targets.
- This change will introduce a breaking change for SoCs with the HMAC
peripheral. Turning on flash encryption will no longer enable NVS
encryption automatically.
Closes https://github.com/espressif/esp-idf/issues/12549
MR espressif/esp-idf!27436 added sbom manifest file for fatfs,
but the originator is missing a prefix required by SPDX specification.
This results in malformed SPDX sbom files.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The import_lib example contained a fallback mirror for downloading tinyxml2 sources
but this link was dead. If this mirror was used it would cause the build to fail.
This extension allows running programs in QEMU similar to running
them on a real chip:
- 'idf.py qemu' — builds and runs the program in QEMU. User gets
a QEMU instance launched, and can work with it as a normal QEMU
instance.
- 'idf.py qemu monitor' — same, but QEMU is launched in the
background, and idf_monitor runs in the foreground, showing QEMU
output. Compared to only running 'idf.py qemu' this enables, for
example, automatic backtrace decoding.
- 'idf.py qemu gdb' — launches QEMU in the background and opens an
interactive GDB prompt, connecting it to QEMU.
- 'idf.py qemu --gdb monitor' and 'idf.py gdb' in another shell:
launches QEMU in the background, keeps it suspended until GDB is
connected, and opens idf_monitor. GDB can be used in another shell
to debug the application.
