Add ESP32-S31 as a supported target for the H.264 encoder/decoder
example and bump the esp_h264 component to v1.3.8, which provides
support (prebuilt software library) for ESP32-S31.
- Add sdkconfig.defaults.esp32s31 with SPIRAM/CPU settings
- Update pytest and build-test-rules to cover esp32s31
- Update README and Kconfig help text
Replace the oneshot latency assumption with a 1ms periodic timer that
runs only across a forced dirty-partition erase, and fail if irq_count
falls below 80% of the expected count from erase duration.
- Add sdp_seq to avoid p_ccb being free during sdp
- Changed some BTA_Pba functions to return non-void value
- Improve error catching and report
- Refactor bta_pba_client_response to avoid UAF problem
- Rearrange btc_pba_client init flag to avoid some disturbing bug
gen_crt_bundle.py only parses files ending in .pem or .der, but silently
ignored anything else. A PEM certificate named e.g. ca.crt was skipped
without a word, and since the build invokes the script with -q, even the
"Successfully added 0 certificates" hint was suppressed. The build then
succeeded and embedded a bundle without the certificate, and the problem
only surfaced at runtime as a TLS verification failure.
A file passed directly via --input, which is what
CONFIG_MBEDTLS_CUSTOM_CERTIFICATE_BUNDLE_PATH points at, is now expected
to be a certificate: an unsupported extension raises an InputError and
fails the build with a message naming the file and the two accepted
extensions. Files found while scanning a directory keep being skipped,
as a certificate directory may legitimately contain other files, but a
warning is now printed unconditionally so it is visible in the build log.
Also document the requirement in the Kconfig help text and in the
esp_crt_bundle documentation.
Closes https://github.com/espressif/esp-idf/issues/18933
Chips with RDID vendor 0x46 are not XMC and should not enter the XMC
startup flow via the RDID fast path.
Co-authored-by: Cursor <cursoragent@cursor.com>
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 offset table and the per-cert length fields of the certificate
bundle were read through uint16_t*/uint32_t* casts, which compile to
halfword/word loads at addresses with no alignment guarantee: bundles
supplied via esp_crt_bundle_set() can start anywhere, and cert entries
are byte-packed, so their 16-bit fields land at arbitrary offsets.
On chips with SOC_CPU_MISALIGNED_ACCESS_ON_PMP_MISMATCH_ISSUE (DIG-694:
ESP32-C6/H2/H21) a misaligned load from memory-mapped flash can take a
spurious "Load access fault" when it sits within two instructions of an
access to a differently-permissioned region, observed as a crash in
esp_crt_check_bundle()/CA callback during TLS handshakes with a bundle
that happened to be placed at an odd address.
