- Add ESP32-C5, ESP32-C61, ESP32-H4 initial support versions to COMPATIBILITY.md
- Fix ESP32-C2 v1.2 required version from v5.1 to v5.2 in COMPATIBILITY_CN.md
- Improve README_CN.md translation to be more accurate and concise
fix(i2c): fix LOG_LOCAL_LEVEL redefinition error when CONFIG_I2C_ENABLE_DEBUG_LOG is enabled
Closes IDFGH-16800
See merge request espressif/esp-idf!43859
In cmakev2, a component can be evaluated within the context of another
component, so it's important to properly initialize each variable used
by the component.
Fixes: 0c4cf75c35 ("feat(esp32s31): Introduce esp32s31 hello world")
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The idf_build_generate_depgraph function creates a component dependency
graph in dot (graphviz) format for a specified executable. It uses
existing helper functions from cmakev1, ensuring that the generated dot
files are produced in the same manner as in cmakev1. While adjustments
might be needed in the future if necessary, the current implementation
is intended to offer the same functionality as cmakev1. Similar to
cmakev1, the dot files are only generated only when the
__BUILD_COMPONENT_DEPGRAPH_ENABLED build property is set.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
As part of inter-procedural optimizations (IPA), the compiler may
perform tasks such as constant propagation for functions. This involves
generating a specialized version of a given function with a new symbol
name that includes a suffix. For example, during constant propagation,
the compiler might create a specialized version named
`spiflash_start_core.constprop.0` for the `spiflash_start_core`
function. Additionally, the compiler may generate multiple clones of a
single function. Currently, when ldgen performs symbol placement, it
does not account for these compiler-generated functions, leading to
their incorrect or unexpected placement in memory (markers).
Consider a linker fragment with:
```
[mapping:spi_flash]
archive: libspi_flash.a
entries:
esp_flash_api: spiflash_start_core (noflash)
```
The `spiflash_start_core` function should be placed in IRAM. However,
the compiler might generate an optimized version of this function with a
`.constprop.0` suffix, resulting in a
`.text.spiflash_start_core.constprop.0` input section. Currently, ldgen
does not handle this situation, leading to misplaced symbols.
Since `.` is not allowed in C identifiers, it should be safe to consider
all input sections for a symbol with any `.` suffix as representing that
symbol. This means considering the symbol suffixes should not cause any
ambiguity.
This change automatically places all input sections, including those
with possible suffixes for a given symbol, into the specified memory. In
other words, specifying a function name like `spiflash_start_core` in a
linker fragment automatically includes input section names matching
`spiflash_start_core(\..*)?$`.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
wuzhenghui
Xiao Xufeng
harshal.patil
C.S.M
Wan Lei
Mahavir Jain
Wang Meng Yang
Island
Ondrej Kosta
Alexey Gerenkov
Jiang Jiang Jian
luoxu
Tan Yan Quan
Bogdan Kolendovskyy
Konstantin Kondrashov
Aditya Patwardhan
Zhang Wen Xu
Armando (Dou Yiwen)
hrushikesh.bhosale
He Binglin
cjin
Jin Cheng
Frantisek Hrbata
linruihao
Kapil Gupta
Jakub Kocka