change(build): drop BUILD_COMPONENTS support and migrate test_apps to not use it for buildv2
Closes IDF-15859
See merge request espressif/esp-idf!51695
sdkconfig.ci.memprot_esp32s3 was built but listed in no CONFIGS_MEMPROT_*, so
the S3 PMS panic path was never exercised.
expect_gme() takes an optional core, for panics with no attributable core.
The BUILD_COMPONENTS build property only exists when building through the
Build system v1 compatibility shim. Query the executable library
interface's linked-components list instead, so the app does not depend on
compatibility-only properties.
The BUILD_COMPONENTS build property only exists when building through the
Build system v1 compatibility shim. Query the executable library
interface's linked-components list instead, so the app does not depend on
compatibility-only properties.
The bootloader programs only unlocked PMA entries (no PMP), so the layout is
not a bootloader<->application ABI; the application resets all entries, programs
them in ascending order from IRAM, and locks everything. Verified on ESP32-H4 v0.1.
Both PSRAM layouts were mapped as a single RWX window, so everything in external
RAM - the heap included - was executable.
PSRAM used as data only is now RW, and under XIP-from-PSRAM it is split per
section as ESP32-P4 does: .text RX, .rodata read-only, and the MMU-page
alignment gaps and the reclaimed heap RW, so neither is executable.
Both describe the layout that esp_psram_init() produces, and the entries are
locked, so - again as on ESP32-P4 - they are only narrowed when
CONFIG_SPIRAM_PRE_CONFIGURE_MEMORY_PROTECTION says that layout applies. Without
it the application owns the region and PSRAM stays RWX.
The per-section entries cost one PMP entry more than the 16 available, so the CPU
subsystem and peripheral windows are chained as TOR entries, taking one entry
instead of three.
soc.h is corrected against the S31 bus address map: the peripheral window base
was 1 MB too low, and the LP peripheral top, derived from a register base plus a
size rather than from the map, was 16 KB short. SOC_NON_CACHEABLE_OFFSET_FLASH
is added.
Trim bootloader size by moving some logs to DEBUG. Allows
compiling bootloader on P4 with CONFIG_ESPTOOLPY_FLASHMODE_QIO
without changing partition table offset
Move the following modules from the hal component into a new dedicated
esp_hal_debug_assist component, following the esp_hal_timg pattern:
- assist_debug (hal + target-specific LL headers)
- debug_probe (types + target-specific LL headers)
- riscv_trace (hal + types + source + target-specific LL headers)
- trace_ll (esp32/esp32s2/esp32s3 target-specific LL headers)
Update the following components to depend on esp_hal_debug_assist:
esp_system, riscv, bootloader_support, esp_hw_support, esp_riscv_trace
Remove riscv_trace_hal.c from the hal component.
Keep legacy ULP apps on the CMake v1 build path while buildv2 coverage
is limited to full_subproject ULP apps.
Also add the missing esp_driver_gpio dependency to the esp_pm test app
so buildv2 dependency checks see driver/rtc_io.h explicitly.
Build ULP full subprojects through a dedicated entry file,
components/ulp/cmake/ulp_project.cmake, that wraps tools/cmakev2/idf.cmake
and layers a small ULP API on top, mirroring the cmakev2 layering:
ulp_project_init like idf_project_init (init, detect the ULP type,
reset the compile/link options inherited from the app)
ulp_build_executable like idf_build_executable, plus the embeddable
.bin/.h/.ld artifacts
ulp_project_default like idf_project_default (single-executable case)
A child project now includes this one file instead of idf.cmake and calls
these helpers directly, so idf_build_executable is used as-is for the
multi-binary case and the module-path indirection (include(IDFULPProject)
resolved via -DCMAKE_MODULE_PATH) is gone.
As a result:
- IDFULPProjectv2.cmake is removed; its setup moves into the wrapper.
- IDFULPProject.cmake becomes the CMake v1-only entry point.
- The ULP component no longer registers a POST_ELF callback; the binary
artifacts are produced by ulp_build_executable.
- The v2 full-subproject examples (lp_core, riscv, fsm, multi_binary,
combined) are updated to the new API.
- The ULP subproject API is documented in build-system-v2.rst.
Also fix a latent bug this exercises: idf_build_library emitted linker
scripts as "-T <name>" relying on a following "-L" search directory. GNU
ld only searches -L directories that precede -T, so the direct
esp32ulp-elf-ld link used for ULP FSM failed to open the script. Emit the
absolute path instead, matching what the CMake v1 ULP build already does.
Finally, replace the parent-argument bypass loop that used to live in
IDFULPProjectv2.cmake with --no-warn-unused-cli on the child configure,
and stop passing the unused IDF_PARENT_BUILD_DIR.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add an opt_os_lto configuration to the startup test app that enables size
optimization together with link-time and compile-time LTO, and run it across
the supported targets so the LTO build is exercised on real hardware in CI.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Remove ~50 duplicate local definitions of ALIGN_UP/ALIGN_DOWN/ALIGN_UP_BY/
ALIGN_DOWN_BY across the codebase and replace them with canonical
ESP_ALIGN_UP/ESP_ALIGN_DOWN from esp_macros.h.
These tests enable features they do not use -- the VFS console, Wi-Fi task core pinning, and
the DS peripheral -- which shift memory layout, interrupt allocation, and peripheral access
enough to fail them. Override the unused options in each test's sdkconfig and ignore the
resulting unknown-symbol build warnings.
The spiram-xip IROM/DROM alignment tests assumed the XIP region always
leaves an alignment gap before the next MMU page: they executed into the
gap and expected an instruction access fault followed by a register dump.
When the section ends exactly on an MMU page boundary there is no gap - the
device prints "<IROM/DROM> alignment gap not added into heap" and returns,
the framework restarts cleanly (esp_restart_noos, no panic), and the test
timed out waiting for a register dump.
fix(mmap): fixed mmap read data wrong when flash being erased/written and cache not disabled
Closes IDFGH-14084
See merge request espressif/esp-idf!29804
Add KASAN support for detecting heap memory safety bugs (buffer
overflows, underflows, use-after-free) at runtime using compiler
instrumentation and shadow memory. Gated behind
CONFIG_IDF_EXPERIMENTAL_FEATURES, with touch points kept to esp_system
and heap so other components stay untouched.
- Core runtime (esp_system/kasan.c, esp_kasan.h): nibble-based shadow
memory in DRAM, poison/unpoison, per-access validation, and __asan_*
stubs; hot-path stubs in IRAM so they stay valid with the flash cache
off. Shadow init runs before heap bring-up.
- Heap integration (heap/heap_kasan*.c): alloc/free hooks add redzones,
a quarantine FIFO, and shadow updates.
- Panic handling: disable checks once at the panic handler entry so
backtrace and stack dumps can read redzones without nested reports.
- Build system: -fsanitize=kernel-address for app code, with HAL, SoC,
esp_rom, SPI flash, esp_hw_support, bootloader_support, FreeRTOS, and
heap internals excluded from instrumentation.
- Test app (tools/test_apps/system/kasan_test): Unity tests for
overflow, underflow, use-after-free, and all sized __asan_* stubs,
with halt and no-halt configurations.
- Docs: document KASAN in the heap memory debugging guide (EN and CN).
Before:
The cache won't be disabled when XIP on psram. But during flash
erasing/programming, read data will be courrupt.
When XIP in psram is enabled, the image is not mapped to the cache so
usually there will be no flash access. The only way to read from flash
is via the driver or use mmap. The driver has protection during erasing,
while th mmap region not.
Now:
Mmap APIs provide a flag to make mmap->unmap region mutually exclusive
to flash erase/programming when XIP from psram. SPI Flash write APIs
will benefit from this. When the flag is used, no concurrent access to
mapped region will happen while writing; otherwise the cache will be
disable to avoid data corruption.
Most ESP-IDF APIs calls mmap with this flag. As for users calling
mmap-like APIs directly, they can choose whether to enable this by a
flag.
Closes https://github.com/espressif/esp-idf/issues/14897
