Refactor the LP UART multi-device tests to use a single parameterised
helper pair (test_lp_uart_write_cfg / test_lp_uart_read_cfg) instead of
one-off functions per config, and extend coverage to:
- write and read tests for 5-, 6-, 7-bit and even-parity configurations
- negative tests: word-length mismatch (FRAM_ERR recovery on LP side,
garbled receive on HP side)
- LP GPIO Matrix routing tests (SOC_LP_GPIO_MATRIX_SUPPORTED chips only):
swaps the default TX/RX GPIO numbers so both pins go through the LP GPIO
Matrix, covering the lp_gpio_connect_in/out_signal() branch of
lp_uart_config_io() that was previously untested at the data-transfer
level; the same physical cross-wiring as all other LP UART tests is reused
Add rtc_gpio_deinit() cleanup at the end of single-board LP UART tests
so configured pins are returned to HP/digital mode and do not interfere
with subsequent tests that may reuse the same GPIOs.
lp_core_uart_set_pin() unconditionally configured the RTS and CTS GPIO
pins even when flow control was disabled. Only configure the RTS pin
when UART_HW_FLOWCTRL_RTS is set, and the CTS pin when
UART_HW_FLOWCTRL_CTS is set.
On chips with SOC_LP_GPIO_MATRIX_SUPPORTED (esp32p4, esp32s31), when the
default IOMUX pin is used for LP UART, calling rtc_gpio_iomux_func_sel()
alone only selects the IOMUX function on the pad side but does not set
sig_in_sel=0 on the peripheral side. This leaves the LP UART RX input
still reading from the LP GPIO Matrix (where no signal is connected),
causing RX to receive nothing.
Apply the same fix that was already in the HP UART driver: use
rtc_gpio_iomux_input() / rtc_gpio_iomux_output() which additionally
configure the peripheral to bypass the LP GPIO Matrix for IOMUX pins.
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 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>
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>
`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>
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>
Sudeep Mohanty
Zhang Wen Xu
Island
morris
Wang Meng Yang
Roland Dobai
Xu Si Yu
Shu Chen
Marius Vikhammer
Frantisek Hrbata
Mahavir Jain
Euripedes Rocha
Fu Hanxi