QEMU hangs for ESP32-S2 application

[smuehlst]

I built the Espressif QEMU from the most recent commit commit according to the instructions in the Wiki:

https://github.com/espressif/qemu/wiki#configure

After that I built a flash_image.bin file for an ESP32-S2 app according to the corresponding instructions from this page, and tried to start QEMU with it under Windows 10 WSL2 Debian Linux:

$ build/qemu-system-xtensa -machine esp32 -drive file=flash_image.bin,if=mtd,format=raw
==19816==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Adding SPI flash device

After that nothing happens anymore, QEMU apparently hangs.

Should QEMU work for an ESP32-S2 application? Or do I have to rebuild the application specifically for ESP32?

[igrr]

Hi @smuehlst, this repository only contains patches to emulate the ESP32 chip. Unfortunately there is no ESP32-S2 support here. This was also requested in #9 but we never got to implementing it.
If you'd like to run an ESP application in QEMU you can only do so by building the application for the ESP32.

[smuehlst]

@igrr Thanks for clarifying this, I will try my luck with an ESP32 build.

[smuehlst]

@igrr I rebuilt the application for the ESP32 target, and the behavior is the same. QEMU hangs after printing the message "Adding SPI flash device". Do you have any hints for analyzing this problem?

[igrr]

It's odd that it doesn't at least print the ROM code sign-on message — that shouldn't depend on the application being loaded.

I have noticed you aren't passing -nographic argument. This usually results in serial output being sent to a GUI window, if QEMU was configured with GUI support. I don't know what happens on WSL in this case. Could you try adding -nographic and see if that makes any difference?

[igrr]

If that doesn't make any difference, can you try the following:

• build/qemu-system-xtensa -nographic -machine esp32 -global driver=esp32.gpio,property=strap_mode,value=0x0f — should normally print

  Not initializing SPI Flash
  ets Jul 29 2019 12:21:46
  
  rst:0x1 (POWERON_RESET),boot:0xf (UART_BOOT(UART0))
  

• If the above doesn't work, then run the same with an extra -trace enable=*,file=qemu_log.txt argument — this should (normally) produce a lot of output in qemu_log.txt. Please attach that file here.

[smuehlst]

Could you try adding -nographic and see if that makes any difference?

@igrr Thanks for the hints. Indeed adding the option -nographic prevents the hang:

$ build/qemu-system-xtensa  -nographic -machine esp32 -drive file=flash_image_esp32.bin,if=mtd,format=raw
==151==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Adding SPI flash device
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x12 (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:0x3fff0030,len:7408
load:0x40078000,len:14912
load:0x40080400,len:3688
entry 0x4008067c
I (1678) boot: ESP-IDF v4.3.2 2nd stage bootloader
I (1726) boot: compile time 21:31:30
I (1779) boot: chip revision: 0
I (1821) boot.esp32: SPI Speed      : 40MHz
I (1834) boot.esp32: SPI Mode       : DIO
I (1845) boot.esp32: SPI Flash Size : 2MB
I (1907) boot: Enabling RNG early entropy source...
I (1985) boot: Partition Table:
I (1994) boot: ## Label            Usage          Type ST Offset   Length
I (2012) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (2034) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (2051) boot:  2 factory          factory app      00 00 00010000 00100000
I (2101) boot: End of partition table
I (2153) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=49fb8h (303032) map
I (5873) esp_image: segment 1: paddr=00059fe0 vaddr=3ffb0000 size=02990h ( 10640) load
I (6078) esp_image: segment 2: paddr=0005c978 vaddr=40080000 size=036a0h ( 13984) load
I (6342) esp_image: segment 3: paddr=00060020 vaddr=400d0020 size=adcb8h (711864) map
I (15251) esp_image: segment 4: paddr=0010dce0 vaddr=400836a0 size=07db8h ( 32184) load
I (15695) esp_image: segment 5: paddr=00115aa0 vaddr=50000000 size=00010h (    16) load
E (15779) esp_image: Image length 1071840 doesn't fit in partition length 1048576
E (15805) boot: Factory app partition is not bootable
E (15819) boot: No bootable app partitions in the partition table

Obviously something is still wrong with the partition table of the image, but the problem with the hang is solved.

Where could the problem with the partion table come from? I built the image file according to the Wiki instructions here:

https://github.com/espressif/qemu/wiki#build-test-app

(cd build; esptool.py --chip esp32 merge_bin --fill-flash-size 4MB -o flash_image.bin @flash_args)

These are the contents of the flash_args file:

--flash_mode dio --flash_freq 80m --flash_size 4MB
0x8000 partition_table/partition-table.bin
0x1000 bootloader/bootloader.bin
0x10000 esp-pdflib-app.bin

[igrr]

Do I understand it right that the same build works okay for you on the real ESP32 hardware, but somehow the result in QEMU is different?
If yes, could you compare the bootloader output on the real hardware with what you get in QEMU? (You can post the output from the hardware here.)

If you don't have esp32 hardware and you haven't checked that the build works there, it could be that the application you built is indeed too large for the available partition size. In that case you can define a custom partition table with larger factory partition.

[smuehlst]

Do I understand it right that the same build works okay for you on the real ESP32 hardware, but somehow the result in QEMU is different? If yes, could you compare the bootloader output on the real hardware with what you get in QEMU? (You can post the output from the hardware here.)

It's not the same build, as my real hardware is the TinyS2 ESP32-S2 board:

https://unexpectedmaker.com/tinys2

Therefore I created a separate build with the idf.py tool where I specified the target as esp32:

 idf.py -B build-esp32 -C esp-pdflib-app set-target esp32

If you don't have esp32 hardware and you haven't checked that the build works there, it could be that the application you built is indeed too large for the available partition size. In that case you can define a custom partition table with larger factory partition.

I have defined a custom partition table in a CSV file which looks like this:

PS E:\Users\stm\Documents\GIT\esp32-pdflib\esp-pdflib-app> cat  partitions_pdflib_app.csv
# Name,   Type, SubType, Offset,  Size, Flags
# Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap
nvs,      data, nvs,     ,        0x6000,
phy_init, data, phy,     ,        0x1000,
factory,  app,  factory, ,        2M,

I see now that the sdkconfig file of the project apparently was overwritten by the idf.py set-target command, so the custom partition table was not used. I will try to fix that and retry the build.

[smuehlst]

I see now that the sdkconfig file of the project apparently was overwritten by the idf.py set-target command, so the custom partition table was not used. I will try to fix that and retry the build.

I now understand my mistake which was that I thought I could just rebuild the application after the idf.py set-target command, without going again through menuconfig to set all relevant parameters. So after doing the menuconfig I was able to build an application that now actually runs in QEMU, although at the end it crashes with an assertion apparently in the heap implementation which needs further investigation:

assert failed: insert_free_block heap_tlsf.c:239 (current && "free list cannot have a null entry")

Anyway, thanks a lot, @igrr, your comments helped me a lot to get started with this topic!

[igrr]

@smuehlst No problem, it's an easy mistake to make! I recommend putting all the configuration changes into an sdkconfig.defaults file. This file will be applied as the starting point whenever sdkconfig doesn't exist, such as when you run idf.py set-target. You can then add sdkconfig.defaults to git and add sdkconfig to .gitignore.

Regarding the assertion, it's a weird one, I haven't seen it before. If you manage to reproduce it on real hardware, please report it in the esp-idf issue tracker. Otherwise it could be something specific to the emulator.

[smuehlst]

@smuehlst No problem, it's an easy mistake to make! I recommend putting all the configuration changes into an sdkconfig.defaults file. This file will be applied as the starting point whenever sdkconfig doesn't exist, such as when you run idf.py set-target. You can then add sdkconfig.defaults to git and add sdkconfig to .gitignore.

@igrr Thanks for pointing out the sdkconfig.defaults file. I just skimmed through the corresponding documentation, and it looks like the feature that allows to have separate sdkconfig.defaults file e.g. for ESP32 and ESP32-S2 targets may help me here. With that I can put the target-specific settings into separate version-controlled files and do builds for QEMU and for the real board from the same source tree.

Regarding the assertion, it's a weird one, I haven't seen it before. If you manage to reproduce it on real hardware, please report it in the esp-idf issue tracker. Otherwise it could be something specific to the emulator.

After thinking about this problem for a few minutes I remembered that I had seen something similar on the real ESP32-S2 board before, and then the fix was easy. One of the settings that I had forgotten when redoing the menuconfig for the ESP32 QEMU build was to adjust the main task stack size. After bumping that value upwards to the same value as in the ESP32-S2 build the error went away.