Previously, --flash-mmu-page-size was only passed when the configured
MMU page size was not 64KB. This caused an issue for targets with a
configurable MMU page size whose non-64KB size is the actual default.
Remove the 64KB exclusion and always pass the argument for all targets,
including those without a configurable MMU page size. Since ESP-IDF now
always provides the value, esptool can also use it to change the
default MMU page size.
Introduce ESPTOOLPY_FAST_REFLASHING configuration option. It instructs
ldgen to group entity mappings for libraries deemed mutable (prone to
change) separately from those considered immutable (unlikely to change).
Organizing mutable and immutable libraries separately in the linker
script allows the linker to form larger contiguous blocks of data for
immutable libraries in the application's output sections. These blocks
are likely to stay mostly unchanged between application recompilations,
enabling them to be skipped during reflashing.
Separating mutable and immutable libraries in the linker script to
minimize changes in the output sections is insufficient. Padding is
added after the input sections of mutable libraries in the default data
and text output sections. This creates a buffer for the mutable
libraries, allowing additional changes to be made without altering the
layout of the binary image.
Additionally two optimizations currently in use can still mix data from
these libraries, leading to significant changes even within the grouped
immutable libraries.
1. constant merging
Linker will try to merge input sections that have the MERGE and
STRING flags from different libraries (object files) to perform
optimizations like tail merging. For example, adding a string
literal in a mutable library will also change the addresses of
string literals from immutable libraries in such a merged section,
causing changes in the generated code when those literals are
referenced.
Disabled with COMPILER_DISABLE_MERGE_CONSTANTS(-fno-merge-constants)
2. literal pools on Xtensa
As optimization, the linker may merge literal pools from different
libraries (object files) to improve the generated code size. This
has the same effect as constant merging, and changes in mutable
libraries may cause changes in the generated code for immutable
libraries. To get larger unchanged continuous blocks in the text
output sections for immutable libraries, we need to ensure that the
Xtensa literal pools remain close to their references and are not
merged.
Disabled with CONFIG_COMPILER_ENABLE_TEXT_SECTION_LITERALS(-mtext-section-literals)
When ESPTOOLPY_FAST_REFLASHING is enabled, these two optimizations are
disabled to achieve larger unchaged continuous blocks for the grouped
immutable libraries, even though disabling these optimizations results
in slightly larger code.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
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.
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 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.
This commit refactors the esptool_py component to provide utility
functions for flash target management instead of creating the targets
directly. Flash target creation is now moved to the project level in
build.cmake file when idf_build_executable() runs.
The following changes were done in this commit:
- Added __esptool_py_setup_tools(), __esptool_py_setup_estool_py_args()
and __ensure_esptool_py_setup() functions to centralize esptool_py
setup.
- Added __esptool_py_setup_main_flash_target() which is called by
idf_build_executable() to create the flash targets.
- Updated esptool_py_flash_target(), esptool_py_custom_target() to
accept an optional FILENAME_PREFIX argument to enable creation of
build artifacts based on custom names.
- Create placeholder flash targets early in the build process when
idf_build_process() is called for components to add dependencies on
these targets.
- Moved app-flash target creation from esptool_py/CMakeLists.txt to
build.cmake.
- Added function description to esptool_py functions.
- The CMake function esptool_py_partition_needs_encryption() in the esptool_py
component used to mark NVS partition as encrypted, instead it should have marked
the NVS keys partition as encrypted.
- Support SOC ROOT clock source switch
- Support CPU frequency change
- Support RTC SLOW clock source switch
- Support RTC SLOW clock + RC FAST calibration
- Remove FPGA build
- Support SOC ROOT clock source switch
- Support CPU frequency change
- Support RTC SLOW clock source switch
- Support RTC SLOW clock + RC FAST calibration
- Remove FPGA build
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
* All components which won't build (yet) on Linux are excluded.
This enables switching to Linux in an application without
explicitly setting COMPONENTS to main in the main
CMakeLists.txt.
* ESP Timer provides headers for Linux now
* automatically disabling LWIP in Kconfig if it is not available
doc(linux): brought section
"Component Linux/Mock Support Overview" up to date
Jaroslav Burian
Radim Karniš
Mahavir Jain
Frantisek Hrbata
Peter Dragun
Sudeep Mohanty
Marek Fiala
armando
harshal.patil
Laukik Hase
Roland Dobai
Jan Beran
Jakub Kocka
Konstantin Kondrashov
C.S.M
Song Ruo Jing
Ondrej Kosta
laokaiyao
Nebojša Cvetković
wanlei
Arno Moonen
Xiao Xufeng
Jakob Hasse