Wire esp_blockdev, comp_a, and comp_b into the test app dependency graph
so ioctl def files are registered and the POST_BUILD overlap checker runs.
Co-authored-by: Cursor <cursoragent@cursor.com>
Promote the build system v2 functions and macros used by the
examples/build_system/cmakev2 examples to the generated API reference,
document the component-scope and version variables, the public build
properties, and the public component properties, and add cmakev2
build_property and component_property directives with dedicated Build
Properties and Component Properties sections to the esp-docs extension.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Detect and drive the display-only ble_uart_vibe_indicator sample alongside
the interactive MiaoBan companion device, and let multiple OpenCode instances
each bind their own indicator channel.
- plugin: after connect, probe the device over the daemon's generic /request
path and classify it as vibe_indicator / generic / unknown — a vibe_indicator
answers the indicator_count capability query, a 502 marks a generic device,
and a transport failure stays unknown for retry on a later refresh. The daemon
stays a generic transport and is unchanged; detection is a demo concern.
- plugin: route by device_type. The vibe_indicator mirrors OpenCode activity
as four lamp states on its bound channel — executing (green blink),
success (green solid), waiting-for-user (yellow solid, on permission
prompts, decision left to the TUI), and error (red solid, on session.error
and the following idle). Other devices keep the existing session.status /
permission round-trip.
- plugin: add indicator_bind_channel / indicator_unbind_channel /
indicator_show_binding tools. Each channel has at most one live owner:
binding a channel owned by another running instance fails (force to take
over), and stale claims are reclaimed via process-liveness checks. The
per-directory binding is persisted and re-claimed across restarts
(OPENCODE_BLE_BINDING_FILE).
- docs: document device detection, lamp effects, and channel binding.
- Add type assertion for event.type to bypass strict TS compilation errors
- Accept both 'permission.asked' and 'permission.updated' event types
- Add normalizePermissionEvent() to handle internal vs SDK event property
format differences (pattern vs patterns, type vs permission fields)
- Add RawPermissionEvent type for loose event property parsing
- Add troubleshooting section and subdirectory auto-loading note to README
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
When an app sets __COMPONENT_REQUIRES_COMMON before project(), the
explicit value used to bypass the default branch that includes
${idf_target_arch}, dropping the arch component from the build.
IDF_TARGET_ARCH isn't known pre-project(), so apps shouldn't have to
hand-roll a target -> arch map. Append it after the explicit list during
common-component initialization; empty on linux means no append.
Read sdkconfig.cmake's CONFIG_* values and re-publish them on the
build-properties target so component CMakeLists.txt code that queries
Kconfig via idf_build_get_property(var CONFIG_FOO) returns the expected
value.
Add a COMMAND check on esptool_py_flash_target before invoking it in
__init_project_flash_targets. Apps that restrict the build set without
esptool_py would otherwise hit "Unknown CMake command".
Move managed-dependency injection and recursive inclusion to BEFORE the
component's add_subdirectory() call, so its CMakeLists.txt can resolve
managed-dep targets at register time. Inside idf_component_register,
union the manager-injected REQUIRES/PRIV_REQUIRES with what the
component author wrote instead of overwriting them.
Under __V1_COMPAT_SHIM, populate EXECUTABLE, EXECUTABLE_NAME, and
BUILD_COMPONENTS build properties in __project_default(), and propagate
project_elf to the caller scope. Relax the BUILD_COMPONENTS query gate
in build.cmake so component code that uses
idf_build_get_property(... BUILD_COMPONENTS) keeps working.
Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Replicate Build system v1 behavior where the 'main' component implicitly
depends on the discovered components (or the app-restricted
__SHIM_COMPONENTS list) when no explicit REQUIRES/PRIV_REQUIRES is set.
Gated on __V1_COMPAT_SHIM so native Build system v2 projects retain
their explicit dependency contract.
Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
When IDF_BUILD_V2 evaluates to a CMake-truthy value, project.cmake
delegates to Build system v2 (cmakev2). The shim wraps project(),
forwards the app-declared COMPONENTS list via __SHIM_COMPONENTS, and
publishes __V1_COMPAT_SHIM so Build system v2 internals can gate Build
system v1 compatibility behavior. Existing app CMakeLists.txt files
build unchanged.
Co-authored-by: Frantisek Hrbata <frantisek.hrbata@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.
feat(freertos): added option for automatically placing task stacks in PSRAM
Closes IDF-15538, IDF-15539, and IDF-15540
See merge request espressif/esp-idf!48953
Rework the syscall interposition architecture so FreeRTOS works
standalone (without VFS) and VFS optionally overrides with strong
symbols. All kernel FDs are registered with VFS via
esp_vfs_register_fd_with_local_fd, so the application only sees
VFS-allocated FD numbers, preventing numerical collisions between
kernel FDs and VFS-internal FD slots.
FreeRTOS side:
- Create linux_port_coop_internal.h with LINUX_COOP_IO_LOOP,
LINUX_COOP_RESOLVE, linux_coop_yield and FD state table functions
- Export cooperative I/O primitives (freertos_linux_coop_read/write/
open/close/fcntl/select/pread/pwrite/readv/writev/recv/send/
recvfrom/sendto/recvmsg/sendmsg/connect/accept/pselect/poll/
socket/socketpair/pipe/pipe2/dup/dup2/syscalls_init)
- Define weak POSIX symbols calling through to the cooperative
primitives; keep nanosleep/sleep/usleep as strong (not FD-related)
- Refactor freertos_linux_coop_syscalls.h into a pure public API header
VFS side:
- Register the Linux host FS with esp_vfs_register_fs_with_id() as a
proper VFS driver; register stdin/stdout/stderr at init (priority 99)
- Rewrite vfs_linux.c with strong POSIX symbols dispatching through
esp_vfs_*
- Add strong overrides for FD-creating syscalls (open, pipe, pipe2,
socket, socketpair, dup, dup2, accept) that register returned FDs
with VFS
- Add strong overrides for FD-translating syscalls (readv, writev,
recv, send, recvfrom, sendto, recvmsg, sendmsg, connect, pselect,
poll) that translate VFS FD to kernel FD
- Delete vfs_coop_syscalls.c (absorbed into FreeRTOS weak + VFS strong)
- Update CMakeLists.txt: remove vfs_coop_syscalls.c, add linker hook
Martin VychodilandCursor
Frantisek Hrbata
Island
jiminxiang
Zhou Xiao
morris
Alexey Lapshin
Jan Beran
Sudeep Mohanty
Tomáš Rohlínek
zhanghaipeng
Xiao Xufeng
Roland Dobai
Konstantin Kondrashov
Konstantin Kondrashov
Jiang Jiang Jian
Aditya Patwardhan
Jiang Guang MingandCursor
sibeibei
Vojtech Piroch
Ondrej Kosta
Guillaume Souchere
sonika.rathi
Marius Vikhammer