Replaced per-target bootloader.ld.in with bootloader.memory.ld.in and
bootloader.sections.ld.in.
Common code moved to file bootloader.sections.common.ld
Unify ESP32-P4 ECO4- and ECO4+ linker scripts into one shared script
Revision-specific code is selected with CONFIG_ESP32P4_SELECTS_REV_LESS_V3
Add CMakeLists_v2.txt to the bootloader subproject, implementing the
bootloader build using the new cmakev2 IDF build framework.
The file covers the full bootloader build pipeline:
- Sets PROJECT_COMPONENTS_SOURCE to "idf_components" so that the
subproject's built-in components (main/, components/) are treated as
IDF components (priority 0) rather than project components (priority
3). This preserves the cmakev1 behaviour where user-supplied
components in bootloader_components/ can override the built-in ones.
- Registers optional user-supplied bootloader components from the
application project's bootloader_components/ directory, with support
for selectively excluding individual components via
IGNORE_EXTRA_COMPONENT.
- Bootstraps the cmakev2 framework (idf.cmake) and initialises the
project with BOOTLOADER_BUILD and NON_OS_BUILD properties, which are
also exposed as C preprocessor definitions.
- Sets GENERATE_SDKCONFIG to 0 to prevent the bootloader subproject
from regenerating the main project's sdkconfig, as the bootloader
has a different set of components and hence different Kconfig files.
- Sets the common implicit component dependencies shared by every
bootloader component (log, esp_rom, esp_common, esp_hw_support,
esp_libc, arch-specific component).
- Applies the compiler options specific for bootloader
- Selects the correct target-specific linker script, including a
separate script for ESP32-P4 silicon revisions < v3.
- Links the bootloader ELF via idf_build_executable and then converts it
to a flat binary via one of three paths depending on the secure boot
configuration:
* No secure boot: plain binary + size check + metadata.
* Secure Boot V1 one-time-flash: plain binary with post-build
instructions showing the esptool.py flash command.
* Secure Boot V1 reflashable: derives the symmetric eFuse key from
the ECDSA signing key, produces the reflash-digest image, and
prints burn/flash instructions.
* Secure Boot V2: produces an unsigned binary, optionally signs it
with the configured signing key (RSA-PSS 3072, ECDSA P-256, or
ECDSA P-384) via idf_sign_binary, and prints flash/multi-key
signing instructions.
- Adds comprehensive inline documentation explaining each section's
purpose, the rationale behind individual flags, and the relationships
between Kconfig symbols and generated artefacts.
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)
The bootloader build script incorrectly used the `DEPENDS` keyword with the
`add_custom_command(TARGET ...)` signature. This is unsupported, causes
warnings with modern CMake versions enforcing the CMP0175 policy.
This commit also updates the POST_BUILD messages generated during the
bootloader build to depend on more precise CMake targets rather than
depending on the generic bootloader.elf target.
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.
Unlike COMPILE_OPTIONS, COMPILE_DEFINITIONS CMake property assumes
values without the -D prefix, such as NAME or NAME=VAL.
Previously, IDF build system was passing COMPILE_DEFINITIONS build
property to CMake COMPILE_OPTIONS property, so -D prefix was not
a problem.
Now that COMPILE_DEFINITIONS CMake property is used, -D prefix has
to be removed.
(Note that this doesn't affect 'target_compile_definitions' function,
which strips -D prefix before adding the definition to the property.)
This updates the minimal supported version of CMake to 3.16, which in turn enables us to use more CMake features and have a cleaner build system.
This is the version that provides most new features and also the one we use in our latest docker image for CI.
Add the possibility to have user bootloader components. This is performed
from an application/project, by creating bootloader components. To do so,
it is required to create a `bootloader_component` directory containing
the custom modules to be compiled with the bootloader.
Thanks to this, two solutions are available to override the bootloader now:
- Using hooks within a user bootloader component
- Using a user defined `main` bootloader component to totally override the
old implementation
Please check the two new examples in `examples/custom_bootloader`
* Closes https://github.com/espressif/esp-idf/issues/7043
* Target components pull in xtensa component directly
* Use CPU HAL where applicable
* Remove unnecessary xtensa headers
* Compilation changes necessary to support non-xtensa gcc types (ie int32_t/uint32_t is no
longer signed/unsigned int).
Changes come from internal branch commit a6723fc
Konstantin Kondrashov
Alexey Lapshin
Frantisek Hrbata
armando
morris
Aditya Patwardhan
Xiao Xufeng
Marius Vikhammer
Peter Dragun
Marek Fiala
Sudeep Mohanty
Omar Chebib
Laukik Hase
harshal.patil
Ivan Grokhotkov
Djordje Nedic
0xFEEDC0DE64
Angus Gratton
Renz Bagaporo
Li Shuai
Supreet Deshpande
Renz Christian Bagaporo