Open Elemecca opened 1 month ago
github-actions[bot]
commented
1 month ago Hi @Elemecca! We appreciate you submitting your first issue for our open-source project. 🌟
Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙
EricNRS
commented
3 weeks ago I just bumped into this for the ESP32-S3 target. The SOC_CACHE_SUPPORT_WRAP state is what includes these functions:
Commenting out these lines doesn't allow the system to boot. Likewise, adding the implementation file components/spi_flash/spi_flash_wrap.c to modules/hal/espressif/zephyr/esp32s3/CMakeLists.txt links correctly, but does not boot.
Further down the CMakeLists.txt file, spi_flash_wrap.c is commented out (https://github.com/zephyrproject-rtos/hal_espressif/blame/5191505f915c0b1c706222f4709925a453e0e858/zephyr/esp32s3/CMakeLists.txt#L157), so I suspect there was an issue with the support to be debugged later.
The boot process seems to go normally until here when the chip_id doesn't match and it tries to call ESP_LOGE():
| 60 esp_err_t bootloader_common_check_chip_validity(const esp_image_header_t* img_hdr, esp_image_type type) │
│ 61 { │
│ 62 esp_err_t err = ESP_OK; │
│ 63 esp_chip_id_t chip_id = CONFIG_IDF_FIRMWARE_CHIP_ID; │
│ 64 if (chip_id != img_hdr->chip_id) { │
│ > 65 ESP_LOGE(TAG, "mismatch chip ID, expected %d, found %d", chip_id, img_hdr->chip_id); │
│ 66 err = ESP_FAIL; │
│ 67 } else {
(gdb) bt
#0 esp_log_writev (level=ESP_LOG_ERROR, tag=0x3c01034c "", format=0x3c010358 "", args=...)
at /home/work/zephyrproject-3.6/modules/hal/espressif/components/log/log.c:191
#1 0x4037f278 in bootloader_common_check_chip_validity (img_hdr=<optimized out>, type=<optimized out>)
at /home/work/zephyrproject-3.6/modules/hal/espressif/components/bootloader_support/src/bootloader_common_loader.c:65
#2 0x4037eca2 in bootloader_check_bootloader_validity ()
at /home/work/zephyrproject-3.6/modules/hal/espressif/components/bootloader_support/src/bootloader_init.c:49
#3 0x4037ef74 in bootloader_init ()
at /home/work/zephyrproject-3.6/modules/hal/espressif/components/bootloader_support/src/esp32s3/bootloader_esp32s3.c:207
#4 0x4037826a in __start () at /home/work/zephyrproject-3.6/zephyr/soc/espressif/common/loader.c:241@sylvioalves - do you remember what the issue was and the best way to fix it?
Describe the bug
On
esp32s3theCONFIG_ESPTOOLPY_FLASHMODE_QIOKconfig setting is available, but choosing it causes the build to fail.To Reproduce
Steps to reproduce the behavior:
hello_worldsampleCONFIG_ESPTOOLPY_FLASHMODE_QIO=yinprj.confwest build -b esp32s3_devkitm/esp32s3/procpuExpected behavior
The bootstrap code should switch the flash to QIO mode during startup (either in MCUBoot prior to loading the application or during application startup if MCUBoot is disabled).
Impact
The flash mode is effectively forced to DIO, meaning:
For my application in production this would be a showstopper, but right now in prototyping I can work around it.
Logs and console output
Relevant section of the build log:
Environment
mainas of this morning)