- Server can now start from any directory, not just a valid project dir
- Document project_dir argument available on all tools
- Add create-project tool to the list of available tools
Co-authored-by: Cursor <cursoragent@cursor.com>
Mirror the recent EN-side updates in the Chinese External RAM guide:
- Replace "PSRAM 顶部" with "PSRAM 上端(最高物理地址区)" to match the
clarified wording on the EN side.
- Add the verification-helper pointer next to the heap_caps_malloc
example so Chinese readers also learn about esp_psram_ptr_is_no_enc().
Also drop the :cpp:func: cross-reference for esp_psram_ptr_is_no_enc on
the EN side: esp_psram.h is not in any chip-specific Doxyfile, so
Sphinx/Breathe cannot resolve the reference. Use a plain inline code
literal instead, matching the existing reference style for
esp_psram_get_size and other esp_psram functions in the docs.
The previous wording "top of PSRAM" was ambiguous: the carve-out is
actually mapped at the highest physical addresses of PSRAM (after the
rodata, text, and main heap mappings). Update the Kconfig help text for
SPIRAM_ENC_EXEMPT and SPIRAM_ENC_EXEMPT_SIZE, the External RAM
documentation, and the internal layout comment to say "upper end of PSRAM
(highest physical addresses)" instead.
Drivers that allocate from the unencrypted PSRAM carve-out via
MALLOC_CAP_SPIRAM_NO_ENC currently have no way to verify after the fact
which pool a buffer came from. This is particularly relevant for callers
using heap_caps_malloc_prefer(MALLOC_CAP_SPIRAM_NO_ENC, MALLOC_CAP_SPIRAM),
where a silent fallback to encrypted PSRAM would still pass the typical
esp_ptr_external_ram() check.
Expose esp_psram_ptr_is_no_enc() in the public esp_psram.h header. It
performs a range check against the carve-out's virtual-address window and
returns false when PSRAM is not initialized or CONFIG_SPIRAM_ENC_EXEMPT is
disabled, so callers do not need to guard the call site with #if.
Also reference the helper from the External RAM documentation alongside
the heap_caps_malloc(MALLOC_CAP_SPIRAM_NO_ENC) usage example.
Extends the External RAM encryption section to describe
CONFIG_SPIRAM_ENC_EXEMPT and the MALLOC_CAP_SPIRAM_NO_ENC heap
capability, including a security warning and a typical DMA-alignment
use case. Mirrors the change in zh_CN.
Clarify that MALLOC_CAP_DEFAULT describes a memory capability
rather than the malloc() placement policy, so PSRAM-backed
capability allocations are documented correctly when malloc()
remains internal-only by default.
Closes https://github.com/espressif/esp-idf/issues/18391
Made-with: Cursor
This commit introduces a new build property, __OPTIONAL_REQUIRES_MODE,
and uses it to either defer or link immediately, optional requirements
to components that request such linkage via the
idf_component_optional_requires() function in build system v2. The
DEFERRED mode is intended for single-binary projects where in the linking
of optional components happens after the library target is created the
dependency graph is available to the build system, thereby allowing it to
behave like the v1 version of the function.
The idf_component_optional_requires compatibility function in cmakev2
currently attempts to mimic the behavior of cmakev1 by adding a
dependency only if a component is already included in the build. In
cmakev1, this is handled by checking the BUILD_COMPONENTS list, which is
created during an early evaluation phase. Because cmakev2 removed this
early phase to allow for configuration-based component dependencies, the
build system does not inherently know which components will be part of
the build beforehand. To compensate, the current compatibility function
relies on the TARGET_EXISTS generator expression to determine if a
component should be linked.
This approach poses a problem because generator expressions are not
evaluated until the generation phase, but cmakev2 processes linker
scripts during the configuration phase by recursively scanning targets
linked to a library. Because the scanner does not recognize and cannot
evaluate generator expressions, any component linked optionally through
generator expression is skipped. If that component carries a linker
script, the script is never added to the library interface, resulting in
build failures. Since cmakev2 aims to support multiple libraries, a
component might also exist globally, causing TARGET_EXISTS to evaluate
to true, yet still be missed during a specific library's recursive scan,
leading to the same omission of necessary linker scripts.
To resolve this, the implementation of idf_component_optional_requires
is changed to check if a component is known to the build system in
COMPONENTS_DISCOVERED build property. If so, it is explicitly included
and linked directly via its interface target. While this may pull more
components into a build than the previous generator expression method,
potentially increasing build times, it ensures that dependency trees are
fully visible to the library target scanner. This serves as a practical
middle ground that maintains compatibility with existing components and
ensures build stability. This approach allows for the gradual fixing of
idf_component_optional_requires usage in components for cmakev2, with
the eventual goal of removing its usage in cmakev2 entirely.
This change also fixes cases where idf_component_optional_requires is
used to conditionally add requirements based on configuration options.
In cmakev2, the presence of a configuration option does not guarantee[1]
that a component has been included via add_subdirectory, unlike the
behavior in cmakev1. With this change even constructions like
```cmake
if(CONFIG_VFS_SUPPORT_IO)
idf_component_optional_requires(PRIVATE vfs)
endif()
```
will now work in cmakev2, as the updated idf_component_optional_requires
explicitly includes the required component if it is available to the
build system.
Closes https://github.com/espressif/esp-idf/issues/18133
[1] https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system-v2.html#id9
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>