Without PSRAM XIP, test_non_cache_irom_reg_execute_violation calls a
flash function through the uncached flash alias and expects an
instruction access fault.
Run test_spiram_heap_execute_violation on every target with a PSRAM
memprot config (ESP32-C5, ESP32-C61, ESP32-P4, ESP32-H4, ESP32-S31), and
the uncached variant in both ESP32-P4 configs. Both tests allocate one
MMU page, so with PSRAM XIP the buffer comes from the main heap and not
from an alignment gap pool.
Add ESP32-P4 rev 3 tests that execute from the PSRAM heap (cached,
uncached and the top of the heap) and from the reserved LP RAM, and that
write to the ROM through the uncached alias. Also run the flash and RTC
tests in memprot_spiram_xip_esp32p4, and four tests on core 1.
The peripheral regions get no execute tests: the hardware already
refuses instruction fetch there, so such a test cannot catch a wrong PMP
permission.
test_non_cache_spiram_xip_heap_execute_violation executes from the
uncached alias of the PSRAM heap, which had no PMP entry before the
previous commit. test_rtc_fast_text_write_violation writes to RTC code
and fails with bootloaders that lock PMP entry 29 (v5.5.5 and v6.0.1 to
v6.1).
The DRAM and RTC_FAST execute cases race the CPU exception against the PMS or
cache interrupt on ESP32-S3 too, so the panic reason is not deterministic.
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 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.
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.
Harshal Patil
gaoxu
Peter Dragun
Roland Dobai
Fu Hanxi
nilesh.kale
Marius Vikhammer