The bootloader subproject's full Kconfig discovery resolves CONFIG_SPIRAM=y
when the parent app has it enabled, even though esp_psram is not linked
into the bootloader (the CMake gate is
'if(NOT non_os_build) if(CONFIG_SPIRAM) idf_component_optional_requires(PRIVATE esp_psram)').
Shared sources in esp_hw_support that #include esp_psram private headers
or call esp_psram functions guarded only by '#if CONFIG_SPIRAM' then fail
to compile in the bootloader with
"fatal error: esp_private/esp_psram_extram.h: No such file or directory".
Mirror the CMake gate in source guards: every '#if CONFIG_SPIRAM' block in
a bootloader-compiled source that touches esp_psram becomes
'#if !BOOTLOADER_BUILD && CONFIG_SPIRAM'. The leaked CONFIG_SPIRAM value
in the bootloader's sdkconfig.h is then harmless because every dependent
block evaluates to false.
Sites updated:
- esp_memory_utils.c: include of esp_psram_extram.h and all
esp_psram_check_ptr_addr() call sites
- port/esp32{c5,c61,p4,s31}/cpu_region_protect.c: include of
esp_psram_extram.h (inner SPIRAM_FETCH/RODATA/PRE_CONFIGURE blocks are
already inside outer !BOOTLOADER_BUILD guards)
- port/esp32{p4,s31}/pmu_sleep.c: include of esp_psram_impl.h and
esp_psram_impl_{enter,exit}_halfsleep_mode() call sites
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
fix(esp_crt_bundle): fixes verification failures with cross signed certificates
Closes IDFGH-17582 and IDFGH-17627
See merge request espressif/esp-idf!47966
`i2c_master_isr_handler_default()` may set HPTaskAwoken to pdTRUE via
`xQueueSendFromISR()` (event_queue), `xSemaphoreTakeFromISR()` and
`xSemaphoreGiveFromISR()` on `bus_lock_mux`. When the device list lookup
returns no matching device, the function returned directly, skipping
the `portYIELD_FROM_ISR()` at the bottom of the handler. A higher-
priority task waiting on the bus mux or the event queue would then have
to wait for the next scheduler tick instead of being preempted into
immediately, inflating worst-case event latency.
Replace the early return with a goto to the existing yield check at the
end of the ISR.
Merges https://github.com/espressif/esp-idf/pull/18569
Cannot write to any bitscrambler registers after clock is disabled in
release_channel().
(cherry picked from commit 39a131617d82e3641d8f0b03b4ec5e5ef1051fd6)
On SOC_LP_GPIO_MATRIX_SUPPORTED targets, use lp_gpio_matrix_input and
lp_gpio_matrix_output instead of lp_gpio_connect_* so matrix outputs use
rtcio_hal_matrix_out (LP GPIO IOMUX applied in HAL).
LP UART remapped pins: drop rtc_gpio_iomux_func_sel(pin, 1); rtc_gpio_init
already selects RTCIO_LL_PIN_FUNC.
Non-matrix LP I2C: select dedicated LP I2C RTC IOMUX via rtc_gpio_iomux_output
(same mux register write as rtc_gpio_iomux_func_sel; matches HAL naming for
peripheral-owned output enable on dedicated mux functions).
The build system currently suffers from a bug where custom configuration
settings are lost when the component manager is invoked multiple times.
During an initial reconfigure or set-target command, the component
manager may return no managed components. Because the build system lacks
the Kconfig definitions for these components at this stage, it
automatically prunes any related configuration symbols—specifically
those defined in managed component Kconfig files—from the sdkconfig
file. By the time the component manager finishes downloading the
dependencies in a subsequent run, these original settings have already
been overwritten and discarded because they were previously unrecognized
by the build system.
To resolve this, the generation of the final sdkconfig should be
deferred until all component manager resolution cycles are complete. We
need to ensure that the build system does not treat missing Kconfig
definitions as invalid until the full dependency graph is loaded. A
potential fix involves using a temporary configuration file for
intermediate component manager passes to prevent the main sdkconfig from
being prematurely scrubbed of valid user settings that belong to
yet-to-be-resolved components.
Edit:
Added cleanup of sdkconfig.cm file and comments
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Edited by: Daniel Paul <daniel.paul@espressif.com>
