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.
This commit adds new CMake APIs for the build system, viz.,
idf_build_add_post_elf_dependency() and
idf_build_get_post_elf_dependencies().
These APIs allow components to add post-ELF processing hooks before the
binary file is generated.
Closes https://github.com/espressif/esp-idf/issues/17251
This commit trims the idf_build_executable() logic and refactors flash
target creation, utility target creation and post-build target creation
into their own separate cmake files/or functions.
This commit global variables such as ESPTOOLPY, ESPSECUREPY, ESPEFUSEPY,
ESPMONITOR and ESPTOOLPY_CHIP from the project_include.cmake file of
esptool_py component. All other components which use these variables
have been updated to fetch the same from esptool_py component's
properties.
This commit refactors the esptool_py component to provide utility
functions for creating utility targets such as erase_flash, merge-bin
and monitor.
The following changes were done in this commit:
- Added __esptool_py_setup_utility_targets() to create utility targets.
- Utility target creation now happens in idf_build_executable() in
build.cmake.
- Removed more global scope processing and variables from esptool_py
component project_include.cmake.
This commit refactors the esptool_py component to move the
flasher_args.json file generation to the main project level cmake file
when idf_build_executable() runs.
This commit refactors the esptool_py component to provide utility
functions for binary file generation targets instead of creating the
targets. Binary generation targets are now moved to the respective
projects.
The following changes were done in this commit:
- Added __idf_build_binary() function to esptool_py to create the binary
file generation target.
- Added __idf_build_secure_binary() as the secure boot equivalent of the
above function.
- Top level project build now creates its own binary targets in
idf_build_executable() in build.cmake.
- Bootloader and esp_tee subprojects create their binary file generation
targets in their respective CMakeLists.txt files.
- All post-build targets such as the app_size_check target are now
created by the respective projects and not esptool_py.
- General clean-up of the esptool_py cmake files.
Frantisek Hrbata
Marek Fiala
Roland Dobai
Daniel Paul
Alexey Lapshin
Jan Beran
C.S.M
Roland Dobai
Marius Vikhammer
Vincent-Dalstra
Alexey Gerenkov
Peter Dragun
Sudeep Mohanty
Fu Hanxi
Ivan Grokhotkov