Define per-target SDIO slave descriptor buffer limits in the LL layer and validate queued send buffers against the 4-byte aligned effective maximum. Update the public docs to describe the chip-dependent limit instead of hardcoding 4092 bytes.
Co-authored-by: Cursor <cursoragent@cursor.com>
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.
If the virtual-address pool is exhausted when reserving the unencrypted
PSRAM carve-out (the warning at L388 may already have fired for the main
mapping), esp_mmu_map_reserve_block_with_caps() returns an error rather
than aborting. Convert the previous assert() into a logged fallback that
disables the carve-out for this boot, mirroring the SPIRAM_ENC_EXEMPT_SIZE
>= psram_available_size path.
Also extend esp_psram_extram_test() to run the standard memory test on
the carve-out region when CONFIG_SPIRAM_ENC_EXEMPT is enabled, so the
unencrypted mapping is exercised on startup like the other PSRAM regions.
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.
Adds CONFIG_SPIRAM_ENC_EXEMPT, available on chips that support per-page
PSRAM encryption configuration (esp32c5, esp32c61, esp32p4). When
enabled, esp_psram carves CONFIG_SPIRAM_ENC_EXEMPT_SIZE off the top of
PSRAM and maps it via the new mmu_hal_map_region_no_enc() helper, which
writes MMU entries without the SENSITIVE bit. The region is registered
as a separate heap pool reachable only through the new
MALLOC_CAP_SPIRAM_NO_ENC capability bit, so default SPIRAM allocations
cannot accidentally land there.
PSRAM encryption imposes alignment constraints that some DMA engines
(e.g. 2D-DMA) cannot satisfy. This option lets such workloads place
their buffers in unencrypted PSRAM while keeping the rest of PSRAM
(and flash) encrypted. Default disabled; security implications are
documented in the Kconfig help text.
Fix esp_vfs_fat_unregister_path possible leak, incorrect check in esp_vfs_register_fs_common and optimize memory usage (v5.5)
See merge request espressif/esp-idf!49639
morris
Jiang Jiang Jian
wuzhenghui
Mahavir Jain
Ashish Sharma
Laukik Hase
yanzihan@espressif.com
zhangyanjiao
Jack
Xu Si Yu
yinqingzhao
C.S.M
harshal.patil
Rahul Tank
Kapil Gupta
Martin Vychodil
Samuel Obuch