Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ESP-IDF Bootloader bootloop #27068

Closed
Skallwar opened this issue Jul 22, 2020 · 8 comments
Closed

ESP-IDF Bootloader bootloop #27068

Skallwar opened this issue Jul 22, 2020 · 8 comments
Labels
bug The issue is a bug, or the PR is fixing a bug platform: ESP32 Espressif ESP32 priority: low Low impact/importance bug Stale

Comments

@Skallwar
Copy link

Describe the bug
When enabling CONFIG_BOOTLOADER_ESP_IDF, the bootlader load the app but hang after I (178) boot: Disabling RNG early entropy source... then restart.

To Reproduce
Steps to reproduce the behavior:
1.export ZEPHYR_TOOLCHAIN_VARIANT=espressif; export ESPRESSIF_TOOLCHAIN_PATH=/path/to/xtensa-esp32-elf/; export ESP_IDF_PATH=/path/to/esp-idf
2. west build -b esp32 zephyr/samples/hello_world/ -DCONFIG_BOOTLOADER_ESP_IDF=y
3. west flash
4. Open a serial console
5. Watch the bootloop

Expected behavior
We should the default hello_world sample output

Impact
While mcuboot does not support esp32, this is a showstopper for wifi and bluetooth as esp-idf bootloader is the only second stage bootloader we have, which is necessary for future flash cache support

Logs and console output

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6824
load:0x40078000,len:14724
load:0x40080400,len:4292
entry 0x400806e4
I (73) boot: Chip Revision: 1
I (73) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (40) boot: ESP-IDF v4.0.1-dirty 2nd stage bootloader
I (40) boot: compile time 18:48:12
I (40) boot: Enabling RNG early entropy source...
I (45) boot: SPI Speed      : 40MHz
I (49) boot: SPI Mode       : DIO
I (53) boot: SPI Flash Size : 4MB
I (57) boot: Partition Table:
I (60) boot: ## Label            Usage          Type ST Offset   Length
I (68) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (75) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (83) boot:  2 factory          factory app      00 00 00010000 00100000
I (90) boot: End of partition table
I (94) boot_comm: chip revision: 1, min. application chip revision: 0
I (101) esp_image: segment 0: paddr=0x00010020 vaddr=0x3ffb0000 size=0x00070 (   112) load
I (111) esp_image: segment 1: paddr=0x00010098 vaddr=0x3ffb0070 size=0x00014 (    20) load
I (119) esp_image: segment 2: paddr=0x000100b4 vaddr=0x3ffb0084 size=0x0008c (   140) load
I (128) esp_image: segment 3: paddr=0x00010148 vaddr=0x3ffb0110 size=0x002c4 (   708) load
I (138) esp_image: segment 4: paddr=0x00010414 vaddr=0x40080000 size=0x00400 (  1024) load
I (147) esp_image: segment 5: paddr=0x0001081c vaddr=0x40080400 size=0x00048 (    72) load
I (155) esp_image: segment 6: paddr=0x0001086c vaddr=0x40080448 size=0x00100 (   256) load
I (164) esp_image: segment 7: paddr=0x00010974 vaddr=0x40080548 size=0x03254 ( 12884) load
I (181) boot: Loaded app from partition at offset 0x10000
I (181) boot: Disabling RNG early entropy source...ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6824
load:0x40078000,len:14724
load:0x40080400,len:4292
entry 0x400806e4
I (73) boot: Chip Revision: 1
I (73) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (40) boot: ESP-IDF v4.0.1-dirty 2nd stage bootloader
I (40) boot: compile time 18:48:12
I (40) boot: Enabling RNG early entropy source...
I (45) boot: SPI Speed      : 40MHz
I (49) boot: SPI Mode       : DIO
I (53) boot: SPI Flash Size : 4MB
I (57) boot: Partition Table:
I (61) boot: ## Label            Usage          Type ST Offset   Length
I (68) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (75) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (83) boot:  2 factory          factory app      00 00 00010000 00100000
I (90) boot: End of partition table
I (94) boot_comm: chip revision: 1, min. application chip revision: 0
I (101) esp_image: segment 0: paddr=0x00010020 vaddr=0x3ffb0000 size=0x00070 (   112) load
I (111) esp_image: segment 1: paddr=0x00010098 vaddr=0x3ffb0070 size=0x00014 (    20) load
I (119) esp_image: segment 2: paddr=0x000100b4 vaddr=0x3ffb0084 size=0x0008c (   140) load
I (128) esp_image: segment 3: paddr=0x00010148 vaddr=0x3ffb0110 size=0x002c4 (   708) load
I (138) esp_image: segment 4: paddr=0x00010414 vaddr=0x40080000 size=0x00400 (  1024) load
I (147) esp_image: segment 5: paddr=0x0001081c vaddr=0x40080400 size=0x00048 (    72) load
I (155) esp_image: segment 6: paddr=0x0001086c vaddr=0x40080448 size=0x00100 (   256) load
I (164) esp_image: segment 7: paddr=0x00010974 vaddr=0x40080548 size=0x03254 ( 12884) load
I (181) boot: Loaded app from partition at offset 0x10000
I (181) boot: Disabling RNG early entropy source...

Environment (please complete the following information):

  • OS: Linux
  • Toolchain: espressif
  • Commit b046ca5
@Skallwar Skallwar added the bug The issue is a bug, or the PR is fixing a bug label Jul 22, 2020
@MaureenHelm MaureenHelm added the priority: low Low impact/importance bug label Jul 28, 2020
@ExtremeGTX
Copy link
Collaborator

I think this needs to be fixed after we have a working SPI driver and initial flash support.
then we can try to load Zephyr from flash and implement flash cache support.

For now, I think the path to BT/WiFi is:

  • Initial SoC Support
  • UART/PINMUX
  • Clock Control
  • SPI (Initial progress), tried to continue, but now I don't have much time to continue working on it.
  • Flash Cache
  • Initial WiFi/BT Support

@ivanwel
Copy link

ivanwel commented Aug 3, 2020

Hi Everyone Ran into the same issue over the weekend, it seems to be executing application code briefly though. Do we have an idea why it might enter this loop?

@Skallwar
Copy link
Author

I think this needs to be fixed after we have a working SPI driver and initial flash support.

I'm working on flash cache support. At the moment the easiest way to test is by using ESP-IDF Bootloader.

@Skallwar
Copy link
Author

Hi Everyone Ran into the same issue over the weekend, it seems to be executing application code briefly though. Do we have an idea why it might enter this loop?

How have you diagnosed this?

Do we have an idea why it might enter this loop?

I don't

@github-actions
Copy link

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

@github-actions github-actions bot added the Stale label Oct 16, 2020
@ExtremeGTX
Copy link
Collaborator

Zephyr Linker script is not configured to work with ESP 2nd Stage Bootloader, The Bootloader found Zephyr but failed to find IRAM and DRAM parts, so it is not loading Zephyr.
It should work after making the necessary modifications in the linker script, but am not sure if there is something else needed.

@github-actions github-actions bot removed the Stale label Oct 22, 2020
@ExtremeGTX ExtremeGTX added the platform: ESP32 Espressif ESP32 label Oct 25, 2020
@ExtremeGTX
Copy link
Collaborator

This should be fixed when #3723 implemented.

@github-actions
Copy link

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

@github-actions github-actions bot added the Stale label Dec 26, 2020
@github-actions github-actions bot closed this as completed Jan 9, 2021
@ExtremeGTX ExtremeGTX removed their assignment Jan 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug The issue is a bug, or the PR is fixing a bug platform: ESP32 Espressif ESP32 priority: low Low impact/importance bug Stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@MaureenHelm @ExtremeGTX @ivanwel @Skallwar