QEMU Virtualization - Custom ESP32-based board

obaidch
Posts: 2
Joined: Mon Jun 19, 2023 9:25 am

QEMU Virtualization - Custom ESP32-based board

Postby obaidch » Mon Jun 19, 2023 9:36 am

Hello everyone!

I am working on a project in order to virtualize a custom ESP32-based board and I would appreciate some help from the community!

the custom ESP32-based board is connected to external devices through SPI (ADC device, CAN-FD-controller..).

I chose to work with QEMU in order to make the emulation possible, the purpose of this is to be able to do tests and flash the firmware and see it running within a virtualized environment without the need for a specific hardware.

the project contains all the drivers and dependencies for the devices and when we flash the custom board with the built firmware everything works great!

At the moment I am working with:

- vs-code, using the ESP-IDF v4.4.3, within a devcontainer setup.
- QEMU release: esp-develop-8.0.0-20230522 (Built from source code)
- QEMU package used: qemu-system-xtensa

The environment variables are set correctly for QEMU, ESP-idf and all the ESP-IDF components and tools, also source files, directories, and paths are included within the setup.

Steps I did in order to make it work:

-Built the project (project is built with cmake).
-Merged bootloader.bin, partition-table.bin, and application.bin files into one single .bin file in order to be able to flash it with QEMU (flash size is 16MB).
-ran this script in order to start the emulation: qemu-system-xtensa -nographic -machine esp32 -drive file=merged.bin,if=mtd,format=raw

At first QEMU is starting the emulation correctly, but the loop starts when QEMU tries to configure the CAN-FD controller for some reason, I tried to debug the project by attaching xtensa-esp32-elf-gdb to QEMU on our executable (the .elf file generated after a completed build), added the -s -S flags in the QEMU script, and by adding breakpoints and going through them, I saw that QEMU is stuck in the part when it is configuring the external devices, so basically the objects that should be created by the object manager are not being created because it is stuck within the configuration part.

Here is the output of QEMU when I run the emulation:

Code: Select all

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:6660
load:0x40078000,len:14936
load:0x40080400,len:3792
entry 0x40080694
I (691) boot: ESP-IDF v4.4.3 2nd stage bootloader
I (693) boot: compile time 12:09:42
I (700) boot: chip revision: 0
I (701) boot.esp32: SPI Speed      : 40MHz
I (701) boot.esp32: SPI Mode       : DIO
I (701) boot.esp32: SPI Flash Size : 16MB
I (707) boot: Enabling RNG early entropy source...
I (713) boot: Partition Table:
I (713) boot: ## Label            Usage          Type ST Offset   Length
I (714) boot:  0 otadata          OTA data         01 00 0000d000 00002000
I (714) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (715) boot:  2 factory          factory app      00 00 00010000 00300000
I (715) boot:  3 ota_0            OTA app          00 10 00310000 00300000
I (715) boot:  4 ota_1            OTA app          00 11 00610000 00300000
I (716) boot:  5 nvs              WiFi data        01 02 00910000 000f0000
I (716) boot:  6 qfs_0            Unknown data     01 99 00a00000 00300000
I (716) boot:  7 qfs_1            Unknown data     01 99 00d00000 00300000
I (720) boot: End of partition table
I (727) boot: Defaulting to factory image
I (732) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=32b94h (207764) map
I (770) esp_image: segment 1: paddr=00042bbc vaddr=3ffb0000 size=03720h ( 14112) load
I (783) esp_image: segment 2: paddr=000462e4 vaddr=40080000 size=09d34h ( 40244) load
I (801) esp_image: segment 3: paddr=00050020 vaddr=400d0020 size=c2718h (796440) map
I (882) esp_image: segment 4: paddr=00112740 vaddr=40089d34 size=0b02ch ( 45100) load
I (900) esp_image: segment 5: paddr=0011d774 vaddr=50000000 size=00010h (    16) load
I (916) boot: Loaded app from partition at offset 0x10000
I (916) boot: Disabling RNG early entropy source...
I (924) cpu_start: Pro cpu up.
I (925) cpu_start: Starting app cpu, entry point is 0x400815b8
I (591) cpu_start: App cpu up.
I (2153) cpu_start: Pro cpu start user code
I (2154) cpu_start: cpu freq: 240000000
I (2154) cpu_start: Application information:
I (2154) cpu_start: Compile time:     Jun 12 2023 12:09:42
I (2155) cpu_start: ELF file SHA256:  4df53292b1fdfecb...
I (2155) cpu_start: ESP-IDF:          v4.4.3
I (2157) heap_init: Initializing. RAM available for dynamic allocation:
I (2158) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (2159) heap_init: At 3FFB8870 len 00027790 (157 KiB): DRAM
I (2159) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (2159) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (2160) heap_init: At 40094D60 len 0000B2A0 (44 KiB): IRAM
I (2193) spi_flash: detected chip: issi
I (2204) spi_flash: flash io: dio
I (2235) cpu_start: Starting scheduler on PRO CPU.
I (4) cpu_start: Starting scheduler on APP CPU.
I (2250) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (15284) sy_app_main: Starting vv62f5-dirty on ESP32 Rev 0, Package 0
I (15288) sy_app_main: Git branch: master
I (15300) sy_app_main: Free memory before creating objects: 203432
I (15308) os_nvs: Opening NVS app_main
I (15416) os_nvs: Opening NVS system

E (15418) sy_obj_mgr: Failed getting size of system/configuration from NVS!
E (15420) sy_obj_mgr: Bad hardware configuration name: , using: defaultconfig-one_stack 
// (this is normal because we do not have an existing configuration, so we load the default one)

I (15424) gpio: GPIO[5]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (15432) gpio: GPIO[34]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (15438) os_spi: Enabled SPI device at CS 4
I (15438) os_spi: Enabled SPI device at CS 17
I (15438) os_spi: Enabled SPI device at CS 2
I (15442) ---: configure CANfdComponent (index: 1) 
// (this is a log message that I printed where everything stops)
after doing some research, I found out that it is not normal for QEMU to halt or enter a loop without raising an error or a warning, and in my case I have no errors neither warnings!

Does anyone have an idea on how to proceed?

Thanks in advance!

ESP_Sprite
Posts: 9757
Joined: Thu Nov 26, 2015 4:08 am

Re: QEMU Virtualization - Custom ESP32-based board

Postby ESP_Sprite » Wed Jun 21, 2023 2:42 am

Are you sure (your version of) qemu supports can in the first place?

obaidch
Posts: 2
Joined: Mon Jun 19, 2023 9:25 am

Re: QEMU Virtualization - Custom ESP32-based board

Postby obaidch » Wed Jun 21, 2023 10:09 am

ESP_Sprite wrote:
Wed Jun 21, 2023 2:42 am
Are you sure (your version of) qemu supports can in the first place?
Yes it does actually, you can have more details concerning the qemu release that I am using in this link: https://github.com/espressif/qemu/relea ... 0-20230522

Who is online

Users browsing this forum: No registered users and 48 guests