When CONFIG_SECURE_BOOT_V2_ENABLED=y but
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES is not set, produce the
binary directly as bootloader.bin instead of bootloader-unsigned.bin.
This matches the v1 behavior where the intermediate binary name is
conditional: bootloader-unsigned.bin only when build-time signing is
enabled (so the signed output can be named bootloader.bin), otherwise
the output is bootloader.bin directly.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The __init_project_configuration() function in cmakev2's project.cmake
unconditionally applied app-level compiler optimization flags based on
CONFIG_COMPILER_OPTIMIZATION_* Kconfig options. When the bootloader
subproject was built with cmakev2, these app-level flags leaked into the
bootloader compile command alongside the correct bootloader-specific
flags from CONFIG_BOOTLOADER_COMPILER_OPTIMIZATION_*.
For example, with the default configuration (app: DEBUG, bootloader:
SIZE), the bootloader received both "-Og -fno-shrink-wrap" (from app
config) and "-Os -freorder-blocks" (from bootloader config). While GCC
uses the last -O flag (-Os wins), the stray -fno-shrink-wrap persisted.
Introduce a SET_COMPILER_OPTIMIZATION build property that defaults to
YES when unset. Subprojects that manage their own optimization flags
(like the bootloader) can set this to NO before calling
idf_project_init() to prevent the default optimization flags from being
applied. This keeps project.cmake generic without requiring it to know
about specific subproject types.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The idf_path variable was used in -fmacro-prefix-map and
-fdebug-prefix-map flags but never read from the IDF_PATH build
property, resulting in an empty substitution. This caused full
filesystem paths to leak into .rodata instead of being mapped to /IDF.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The bootloader does not use the heap allocator or TLSF, so the ROM
patch files esp_rom_tlsf.c and esp_rom_multi_heap.c are not needed
in the bootloader build.
In the cmakev1 build system this was never an issue because cmakev1
uses an early expansion phase where only Kconfig files for components
listed in BUILD_COMPONENTS are processed. Since the heap component is
not part of the bootloader's component list, its Kconfig options
(CONFIG_HEAP_TLSF_USE_ROM_IMPL, etc.) were never defined and the
conditional compilation of these source files was effectively skipped.
In the cmakev2 build system, Kconfig options from all discovered
components are visible regardless of whether the component is part
of the build. Because the bootloader reuses the main project's
sdkconfig (where CONFIG_HEAP_TLSF_USE_ROM_IMPL defaults to y on
targets with ROM TLSF support like esp32c2), the TLSF patch sources
were being compiled into the bootloader's esp_rom. This caused a
build failure because esp_rom_tlsf.c includes tlsf_block_functions.h
from the heap component, which is not a dependency of esp_rom and is
not part of the bootloader build.
Guard the TLSF and multi_heap ROM patch sources with NOT
BOOTLOADER_BUILD to prevent them from being compiled in the
bootloader context. This fix is compatible with both cmakev1 and
cmakev2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Commit f62f45cf5c changed target_add_binary_data to resolve the
embedded file path relative to the component directory by using
idf_component_get_property to obtain the COMPONENT_DIR. This fixed the
path resolution when target_add_binary_data is called from
idf_component_include, which runs outside the component's directory
context.
However, target_add_binary_data can also be called directly from a
project's CMakeLists.txt with a non-component target, e.g.
target_add_binary_data(app.elf ...) as done in
examples/security/security_features_app. In this case,
idf_component_get_property fails because the target is not a component.
Fix this by moving the path resolution to idf_component_include, where
the embed file paths from EMBED_FILES and EMBED_TXTFILES component
properties are resolved to absolute paths relative to COMPONENT_DIR
before being passed to target_add_binary_data. This way,
target_add_binary_data receives already absolute paths from
idf_component_include and can use plain get_filename_component(ABSOLUTE)
for direct calls, which correctly resolves relative to
CMAKE_CURRENT_SOURCE_DIR.
Fixes: f62f45cf5c ("fix(cmakev2/utilities): add a dependency target for the embedded file")
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
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>
Add a GENERATE_SDKCONFIG build property that controls whether kconfgen
writes the sdkconfig file (--output config) during the configuration
step. It defaults to 1 (enabled).
When building the bootloader as a subproject, the set of components
(and their Kconfig files) differs from the main project. Running
kconfgen with --output config in this context rewrites the main
project's sdkconfig. Even when the content is identical, the timestamp
update causes ninja to detect sdkconfig as newer than build.ninja
outputs (e.g. cmake_install.cmake), triggering an infinite CMake
re-run loop.
Setting GENERATE_SDKCONFIG to 0 in a subproject prevents this,
matching the behaviour of cmakev1's __OUTPUT_SDKCONFIG property.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add the PROJECT_COMPONENTS_SOURCE build property to control how project
components are categorised during component discovery. By default it is
set to "project_components" (priority 3 - highest), preserving the
existing behaviour.
Setting it to "idf_components" (priority 0) before calling
idf_project_init() makes the project's built-in components overridable
by user-supplied components through EXTRA_COMPONENT_DIRS (priority 2).
This is needed for sub-projects like the bootloader, whose built-in
components (e.g. main) are provided by ESP-IDF and should be overridable
by user-supplied components placed in bootloader_components/. The
cmakev1 build system allowed this override because it used a
last-one-wins strategy, but cmakev2 uses strict priority-based component
resolution where project_components always win.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add an optional ALL parameter to idf_build_binary and idf_sign_binary
functions. When specified, the created custom target is included in the
default build target. Without ALL, custom targets created by these
functions are excluded from the default build (add_custom_target
behavior), meaning they won't be built unless explicitly requested or
depended upon by another target in ALL.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add a helper function for printing multi-line post-build messages on a
target. The message lines are joined with newlines, written to a file at
configure time, and printed at build time using a single cmake -E cat
command, replacing the need for repeated cmake -E echo invocations.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add a public API function to check that the bootloader binary does not
overlap the partition table, mirroring the existing idf_check_binary_size
pattern for application binaries.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The KEYFILE argument value was stored in a misspelled variable
"keyfle" instead of "keyfile", causing custom keyfile paths to
be silently ignored.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
`CMAKE_CURRENT_LIST_DIR` is actually `components/bootloader`, so it
doesn’t need to be passed via `EXTRA_COMPONENT_DIRS`: the build already
recognizes it as an esp-idf component.
In **cmakev1**, this is silently ignored: if a component with the same
name already exists, its directory is updated and the previous directory
is stored in the `COMPONENT_OVERRIDEN_DIR` component property.
In **cmakev2**, this is correctly detected and reported.
CMake Warning at /home/fhrbata/work/esp-idf/tools/cmakev2/utilities.cmake:63 (message):
IDF: Component 'bootloader' directory '/home/fhrbata/work/esp-idf/components/bootloader'
with higher priority 'project_extra_components' will be used instead of component directory
'/home/fhrbata/work/esp-idf/components/bootloader' with lower priority 'idf_components'
Call Stack (most recent call first):
/home/fhrbata/work/esp-idf/tools/cmakev2/component.cmake:625 (idf_warn)
/home/fhrbata/work/esp-idf/tools/cmakev2/idf.cmake:411 (__init_component)
/home/fhrbata/work/esp-idf/tools/cmakev2/project.cmake:580 (__init_components)
CMakeLists_v2.txt:28 (idf_project_init)
CMakeLists.txt:19 (include)
Since it doesn’t make sense to explicitly add the bootloader as an extra
component, remove it.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The commonly required components are configured solely for backward
compatibility with cmakev1. Since the bootloader build explicitly sets
commonly required components, we need to support this feature in cmakev2
as well. Ideally, there should be no commonly required components, and
each component should specify its requirements explicitly.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
For the bootloader build, the `priv_include_dirs` variable is
uninitialized, but it is used in the common call to
`idf_component_register`.
Using uninitialized variables is not allowed in cmakev2 because a
component may be evaluated in the context of another component’s
variable scope.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, the bootloader version of the `esp_partition` component sets
`PRIV_INCLUDE_DIRS` using the `private_include_dirs` variable. However,
this variable is not properly initialized, which causes issues in
cmakev2. In cmakev2, components are evaluated recursively, and a
component may be evaluated in the context of another component, so
components must initialize all variables before using them.
Moreover, there are effectively no `PRIV_INCLUDE_DIRS` to set when the
component is evaluated for the bootloader. Therefore, remove
`PRIV_INCLUDE_DIRS` entirely for bootloader and test builds.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
