Validate linked RISC-V executables when
CONFIG_COMPILER_ENABLE_RISCV_ZCMP is enabled on affected chips.
Disassemble each function and reject mstatus.MIE clears that lack an
earlier mintthresh write of 0xff.
Handle csrrci, csrrw, and register-mask csrrc patterns while ignoring
csrrs. Add build-only coverage for valid and invalid sequences with
CMake v1 and v2.
Stop the hardware stack guard before switching stacks during restart,
and keep ZCMP disabled for TEE test apps that still require the
workaround.
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
Correct "802.154" to "802.15.4" and change the EUI-64 derivation notation
from base_mac[0:3]/base_mac[3:6] to the inclusive base_mac[0:2]/base_mac[3:5]
in the esp32h2/esp32h21/esp32h4 Kconfig.mac help text and the EN/zh_CN
misc_system_api docs.
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit 811c64c17c)
Add help text to the esp32h2/esp32h21/esp32h4 Kconfig.mac explaining
that these chips only consume one universally administered MAC address:
the IEEE 802.154 EUI-64 is derived from the base MAC and MAC_EXT, and
Bluetooth reuses the base MAC as-is (no BT offset, since there is no
Wi-Fi).
Add a matching 1-MAC derivation table and note to misc_system_api.rst
(EN and zh_CN) under a new `.. only:: esp32h2 or esp32h21 or esp32h4`
block, and exclude these targets from the generic 4/2 table.
Add an esp32s31-only note stating that the "Four" option may only be
used with a customer-provided custom base MAC range, since ESP32-S31
only provides two universally administered MAC addresses in eFuse.
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit e3bc260178)
ESP32-H2/H21/H4 only provide a single universally administered MAC
address in eFuse (MAC_FACTORY), so switch their UNIVERSAL_MAC_ADDRESSES
Kconfig from "Two" to "One" to match the hardware allocation.
This is a functional no-op for MAC generation: the BT offset is only
applied when SOC_WIFI_SUPPORTED, and these chips have no Wi-Fi, so
Bluetooth already reuses the base MAC as-is; the IEEE 802.154 EUI-64 is
derived from the base MAC and MAC_EXT regardless. The only change is
the (otherwise unused) ESP_MAC_UNIVERSAL_MAC_ADDRESSES int value going
from 2 to 1.
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit 431983a091)
ESP32-S31 only provides two universally administered MAC addresses in
eFuse. The previous default of "Four" led to WiFi softap and Ethernet
consuming global MAC slots (base+1/+3) that do not exist on this chip
and could collide with the Bluetooth MAC.
Switch the default to "Two" so Softap and Ethernet fall back to locally
administered MACs derived from the WiFi station and Bluetooth MACs.
The "Four" option is retained for customers who override the base MAC
with a custom range in which four universally administered MAC
addresses are allocated per device; the help text now documents this
constraint.
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit f18f3814cc)
ESP32-C6/H2 bootloaders <= v5.2.1 configure and lock PMP entries 3-4 as their
D-ROM region; a locked PMP entry cannot be reconfigured until CPU reset.
Commit 366e4ee944 ("Remove redundant PMP entry for ROM region") dropped the
D-ROM entry, and commit d4167fea60 (which also restructured C6/H2 PMP setup)
then renumbered the regions down, placing the application IRAM/DRAM split on
entries 3-4. On an already-deployed older bootloader those entries are locked,
so IRAM never gains execute permission and the chip resets before app_main()
(GitHub issue #18769).
Restore the separate (redundant) D-ROM PMP entry on indices 3-4 so the
application IRAM/DRAM split stays on entries 5-7, clear of the locked range.
This keeps newer applications bootable on older bootloaders.
Closes https://github.com/espressif/esp-idf/issues/18769
spinlock.h used #else to include riscv/rv_utils.h for all non-Xtensa
targets. On Linux host (neither __XTENSA__ nor __riscv defined), this
pulls in a non-existent header. Change to #elif __riscv, matching
esp_cpu.h's existing pattern.
morris
Fu Hanxi
Mahavir Jain
Roland Dobai
Armando (Dou Yiwen)
Ashish Sharma
Alexey Lapshin
Jiang Jiang Jian
sibeibei
cjin
wuzhenghui
yanzihan@espressif.com
Li Shuai
Xiao Xufeng
hebinglin
Jack
nilesh.kale
Song Ruo Jing
Sudeep Mohanty