When version.txt does not exist and git describe fails (e.g. in
release archives or environments without git), IDF_VER was set to
the raw git_describe output which resolves to "-128-NOTFOUND",
causing esp_get_idf_version() to return a garbled string.
Add a fallback that constructs the version string from the
IDF_VERSION_MAJOR, IDF_VERSION_MINOR and IDF_VERSION_PATCH
variables when git describe is not available.
Closes https://github.com/espressif/esp-idf/issues/18240
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The minimal build property is simply a shorthand for `set(COMPONENTS
main)`. The issue is that there is currently no check to verify whether
the `main` component actually exists or is known to the build system.
If the `main` component is not present, print an error message along
with suggestions on how to fix this inconsistency.
Closes https://github.com/espressif/esp-idf/issues/18219
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
esp-idf uses imported targets as dummy targets that are never linked.
Previous CMake versions would ignore these and not error on unset
IMPORTED_LOCATION if they are never actually linked. CMake 4.2 and newer
errors during codemodel-v2 api queries when imported targets are missing
IMPORTED_LOCATION, so set a dummy location that would error when
actually linked, which fixes the error during api queries.
Closes https://github.com/espressif/esp-idf/pull/18103
The MINIMAL_BUILD build property and the COMPONENTS variable are both
used to determine the initial component list for the build.
Currently, if the COMPONENTS variable is set, the MINIMAL_BUILD logic
is ignored during component selection, but the MINIMAL_BUILD build
property remains set. This leads to an inconsistent state where
menuconfig displays information indicating MINIMAL_BUILD is active,
even though it was ignored in favor of the COMPONENTS variable.
Fix this by setting the MINIMAL_BUILD property to OFF if the
COMPONENTS variable is used.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This command will allow users to resolve mismatches in default values
between sdkconfig and Kconfig according to a policy specified:
* sdkconfig: Using default values from sdkconfig (backward compatible)
* interactive: User can choose the source for every affected config
option separatedly
* kconfig: Using default values from Kconfig
This change improves build consistency across external projects integrated
through CMake by ensuring that compiler flags defined in configuration files
are passed correctly to the toolchain. It covers the majority of use cases,
as external projects are typically also CMake-based. For projects that use
a custom build system, users will still need to specify the required flags
manually.
The build system keeps track of each component source. Currently
there are four types of sources:
1. "project_components" - project components
2. "project_extra_components" - components from EXTRA_COMPONENT_DIRS
3. "project_managed_components" - custom project dependencies managed by the IDF Component Manager
4. "idf_components" - ESP-IDF built-in components, typically under /components
This can be used to identify the component libraries that are likely to
change during application development and pass them to ldgen as mutable
libraries. Add all components with "project_components" as their source
as mutable.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, the toolchain CMake files use the remove_duplicated_flags
function from utilities.cmake. The cmakev2 implementation also includes
this function for backward compatibility. Move the
remove_duplicated_flags function to a separate file,
deduplicate_flags.cmake, so it can be shared between cmakev1 and
cmakev2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The toolchain files are using the remove_duplicated_flags function from
utilities.cmake. However, we want to avoid mixing utilities from cmakev1
and cmakev2. Use `IDF_BUILD_VER_TAG` to include utilities from the
currently used build system version.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
esp_stdio contains everything the old esp_vfs_console contained (the vfs stdio glue layer)
as well as other functionality related to stdio (previously referred to as console)
Graphviz node ID's are represented as strings, that can only use a
restricted set of characters (characters, digits, and underscores), and
must not match a reserved keyword. These restrictions do not apply when
the string is wrapped in double quotes. This allows for component names
with dashes in them, for example.
Closes https://github.com/espressif/esp-idf/pull/17594
Tools/esp-idf-size: Remove --legacy argument and replace JSON format with JSON2
Closes IDF-8772 and DOC-12437
See merge request espressif/esp-idf!41743
The component validation script was using an incorrect property name
'__COMPONENT_TARGETS' when retrieving component targets. This should be
'__BUILD_COMPONENT_TARGETS' to match the actual property name used
throughout the build system.
This fix ensures the component validation can properly access the list
of component targets and perform validation checks correctly.
There are idf.py hints for helping the user to set component
dependencies properly instead of building sources out-of-component or
including headers from outside the component directory. These are
produced with
tools/idf_py_actions/hint_modules/component_requirements.py.
However, idf.py hints are printed only when the build fails. If the user
starts with a buildable solution then the suggestions to add component
dependencies are not printed.
This commit introduces cmake-level warnings for building source files
from outside the component and including header files without setting up
proper component dependencies.
This commit refactors the flash target creation. Now bootloader and
partition table components add dependencies to the flash target directly
from their component CMakeLists.txt files instead of it being done in
the esptool_py component. The commit also removes the redundant
__esptool_py_setup_main_flash_target() function.
The `-mtune=esp-base` option is identical to the default tuning profile,
except that `slow_unaligned_access` is set to false.
This reduces the instruction count for built-in `memcpy` and improves
performance, since our chips can handle misaligned access with minimal
penalty (without triggering exceptions).
Example:
void load(uint32_t *r, char* x) {
memcpy(r, x, sizeof(uint32_t));
}
void store(char* x, uint32_t v) {
memcpy(x, &v, sizeof(uint32_t));
}
Previously generated code:
load:
lbu a5,2(a1)
lbu a3,0(a1)
lbu a4,1(a1)
sb a5,2(a0)
sb a3,0(a0)
sb a4,1(a0)
lbu a5,3(a1)
sb a5,3(a0)
ret
store:
srli a3,a1,8
srli a4,a1,16
srli a5,a1,24
addi sp,sp,-16
sb a1,0(a0)
sb a3,1(a0)
sb a4,2(a0)
sb a5,3(a0)
addi sp,sp,16
jr ra
With `-mtune=esp-base`:
load:
lw a5,0(a1)
sw a5,0(a0)
ret
store:
sw a1,0(a0)
ret
Inlining behavior
=================
Without `-mtune=esp-base`:
- `memcpy()` is inlined only when the compile-time size is ≤ 12 bytes.
- Maximum cost: ~25 instructions
With `-mtune=esp-base`:
- `memcpy()` is inlined for all compile-time constant sizes.
- Maximum cost: ~14 instructions
As a result, some applications may see reduced code size, while others
may increase slightly. However, performance always improves because
extra `memcpy` calls are eliminated.
Performance results
===================
esp32p4 (Ethernet iperf):
- No noticeable difference
esp32c61 (Wi-Fi iperf):
- ~2 Mb/s increase for TCP and UDP TX (may be within measurement error)
NOTE
====
Applies only to RISC-V chips that do not have the hardware issue marked
by the SOC_CPU_MISALIGNED_ACCESS_ON_PMP_MISMATCH_ISSUE macro.
Roland Dobai
Radim Karniš
Daniel Paul
Fu Hanxi
Alexey Lapshin
Frantisek Hrbata
david zuhn
Ferdinand Bachmann
Marek Fiala
Roland Dobai
Jan Beran
C.S.M
Marius Vikhammer
Vincent-Dalstra
Alexey Gerenkov
Peter Dragun
Sudeep Mohanty