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
Trim bootloader size by moving some logs to DEBUG. Allows
compiling bootloader on P4 with CONFIG_ESPTOOLPY_FLASHMODE_QIO
without changing partition table offset
The generated assembly emitted <name>_length immediately after the raw
payload bytes, so the 32-bit word landed misaligned whenever the data
size was not a multiple of 4. Consumers declare it as a 32-bit object
(e.g. `extern const size_t <name>_length` in the ULP firmware loaders),
so the compiler emits an alignment-assuming word load, which is a
misaligned flash read prone to spurious load faults on chips with
SOC_CPU_MISALIGNED_ACCESS_ON_PMP_MISMATCH_ISSUE (ESP32-C6/H2/H21).
The previous commit touches tools/ci/check_type_comments.py, which brings the
file into ruff's scope for the first time in a while and surfaces two
pre-existing findings:
A004 Import `exit` is shadowing a Python builtin
F401 `typing.List` imported but unused
Import sys and call sys.exit() rather than shadowing the builtin, which is
also how master writes this file. List is used, but only inside `# type:`
comments that ruff cannot see, so mark the import instead of dropping it:
check_type_comments.py is not on tools/ci/mypy_ignore_list.txt, so mypy checks
it under disallow_untyped_defs and the name has to resolve.
No behaviour change. Verified with the pinned ruff 0.9.7 (check and
format --check) and with mypy 1.19.1, and both exit paths of the script still
behave as before.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
check_type_comments.py runs ignore-listed files through a relaxed mypy pass
with --python-version 3.8, which overrides the python_version = 3.9 that
.mypy.ini already sets. mypy dropped 3.8 as a modelling target in 1.17.0 and
now rejects the flag while parsing arguments, before it reads any source:
mypy: error: argument --python-version: Python 3.8 is not supported
(must be 3.9 or higher)
mypy check failed for:
tools/ldgen/ldgen.py
The hook declares mypy without a version, so which mypy is used is decided
when the ci/images pre-commit-idf-v5.5 image is built. That image is based on
Python 3.9, where Requires-Python caps mypy at 1.19.1, and the image
currently in use carries exactly that. Any MR touching a file listed in
tools/ci/mypy_ignore_list.txt therefore fails check_pre_commit
deterministically, whatever the file contains.
Pass 3.9 instead, matching .mypy.ini and the OLDEST_PYTHON_SUPPORTED = (3, 9)
that tools/python_version_checker.py enforces on this branch. This restores
the pairing master and release/v6.0 already have, where the flag mirrors
.mypy.ini at 3.10.
release/v5.4 and release/v5.3 need no equivalent change: their pre-commit
images are based on Python 3.8, where mypy caps at 1.14.1 and the flag is
still accepted.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
release/v5.5's tools/ldgen/ldgen.py predates the ruff-format layout that
pre-commit enforces, so running the hook over this file reports it as
needing reformatting because of code that no change here touches.
Apply ruff-format. That also resolves the E501 on the long
"with open(output_path, ...)" line, since the formatter wraps the call.
No behaviour change.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
On some Windows systems, antivirus, endpoint-security or DLP/encryption
software intercepts short-lived toolchain processes and strips their
stdout when the build captures it through a pipe, while the same command
prints its output normally when run by hand. The tool exits successfully
but returns nothing, and each build step that reads toolchain output then
failed with a different, cryptic error far from the real cause:
- CMake configuration aborted with "Unknown arguments specified" in
components/xtensa/project_include.cmake, or "check_expected_tool_version
invoked with incorrect arguments" in components/esp_common.
- ldgen turned the empty objdump output into an opaque pyparsing
"Expected 'In archive'" traceback.
- idf_tools.py silently reported the compiler/debugger version as
"unknown", sending users into a fruitless reinstall loop.
Detect the empty result at each consumer and fail (or warn) with an
actionable message that names the likely cause and the remedy:
- tools/cmake/compiler_query.cmake: new __compiler_query() helper runs a
compiler query and fails with a clear error on empty or failed output.
It is a standalone module included by the build system utilities, so
that it is available to the esp_common and xtensa project_include.cmake
files that call it. The xtensa if() arguments are now quoted so an
empty result no longer collapses into a parse error.
- tools/ldgen/ldgen.py: _run_objdump() rejects empty objdump output, and
non-empty-but-unparsable section info is caught and re-raised as a clear
LdGenFailure instead of a raw pyparsing traceback.
- tools/idf_tools.py: empty version output now warns with the cause and
returns UNKNOWN_VERSION instead of silently reporting "unknown".
Closes https://github.com/espressif/esp-idf/issues/18727
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Backport of efa75a9b60 to release/v5.5.
Adapted from the master version because of structural differences on
release/v5.5:
- The new jobs are added to .gitlab/ci/host-test.yml (where build-system
pytest jobs live on v5.5) instead of .gitlab/ci/build.yml.
- The minimum supported cmake version is 3.16.3 on v5.5
(cmake_minimum_required(VERSION 3.16) in tools/cmake/project.cmake),
so the new jobs test cmake@3.16.3 instead of 3.22.1.
- The macOS template extraction from the original commit is omitted:
v5.5 already uses .brew-macos-settings for the macOS variables, so
the refactor would be redundant.
Co-authored-by: Cursor <cursoragent@cursor.com>
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.
Replace argparse with rich-click and use esp_pylib.logger for
standardized console output and fatal error handling.
(cherry picked from commit 3a7896f2c5)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
ECDSA based Secure Boot V2 is not functional for certain input vectors on
ESP32-C5/C61/H2/P4 and on the preview targets ESP32-H4/H21. RSA based Secure
Boot V2 is the recommended scheme where the SoC supports it. This issue will be
fixed in a future hardware ECO revision; more details will be shared through the
hardware errata document.
A new hidden Kconfig option SECURE_BOOT_V2_ECDSA_INSECURE marks the affected
mass-production SoCs (ESP32-C5/C61/H2/P4). On these SoCs, when hardware Secure
Boot V2 is enabled, the ECDSA (V2) signing scheme is no longer offered by
default; it must be turned on explicitly via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
under "Allow potentially insecure options" (CONFIG_SECURE_BOOT_INSECURE). App
signing without hardware Secure Boot is not affected. Note that ESP32-C61 has no
RSA based Secure Boot V2, so it has no Secure Boot scheme enabled by default.
The preview targets ESP32-H4 and ESP32-H21 mark ECDSA Secure Boot V2 as not
supported in their SoC capabilities instead of using the option above. As
ESP32-H4 has no other Secure Boot V2 scheme, Secure Boot is disabled entirely on
it; ESP32-H21 retains RSA based Secure Boot V2.
The security documentation keeps the ECDSA Secure Boot V2 content visible and
adds a warning describing the limitation (including that ECDSA Secure Boot V2 on
ESP32-C61 is not recommended for production). CI apps that exercise ECDSA Secure
Boot V2 on the affected SoCs set CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
accordingly.
Move the OpenCode companion guide into the ble_uart_service example.
Add English and Chinese Markdown guides with image assets.
Keep ESP-BLE-UART naming consistent across the example and bridge tooling.
(cherry picked from commit 926111e721)
Co-authored-by: Zhou Xiao <zhouxiao@espressif.com>
