ESP32-S2 support (QEMU-54)

[Ebiroll]

Hello and thanks for the QEMU 5.0.0 rebase release, although it was a bit hard to find. Do you have any plans to do a esp32-s2 release?

[igrr]

Hi @Ebiroll, we do have plans for the eventual ESP32-S2 support, but very likely not in the next 2-3 of weeks. I'll post a note here when we start working on that.

[Ebiroll]

OK, thanks. I made a quick esp32-s2, test and was able to get it to run through the 2nd, bootloader, without to much effort. https://github.com/Ebiroll/qemu_esp32/blob/master/s2BOOT.md

On the S2 hardware I guess will it be possible to use the Icache to map memory to external-RAM instead of flash. Would this allow loading of an elf file from openocd/gdb, similar to the gdb_loadable_elf test?

Have you done such a openocd stub code? It would be nice to be able to skip the flash step when you are using gdb, and use load instead. Or is there any other way to make it possible to load an elf file with gdb_load?

In QEMU there are more options to get this possibility, and I was wondering what you think would be the easiest way to start an elf file loaded with gdb or the -kernel qemu option? (Without setting a breakpoint in the rom, as in the gdb_loadable_elf example)

[igrr]

On the S2 hardware I guess will it be possible to use the Icache to map memory to external-RAM instead of flash. Would this allow loading of an elf file from openocd/gdb, similar to the gdb_loadable_elf test?

Yes, this should be possible. It will require a few things:

1. A configuration option in IDF (maybe implied from CONFIG_APP_BUILD_TYPE_ELF_RAM && CONFIG_SPIRAM_SUPPORT). It would change the linker script to move iram0_2_seg to into the PSRAM backed region.
2. Support in OpenOCD for configuring SPIRAM after target reset. Not too hard to do in the simple case, but it gets really hairy to support things such as pins customized by eFuse, octal PSRAM, etc. I expect this part to be most time consuming to get right. However, the good news is that theoretically this can be all scripted in OpenOCD TCL config files, as a post-reset hook! This might work slower than an on-chip stub, but could still be a viable option?
3. Add enough CPU-specific startup code into the app so that it can be gbd load-ed without having to run the ROM code first. This is also required for the QEMU case, in your last question. At minimum this would require setting VECBASE, initializing WINDOWBASE, WINDOWSTART, PS, setting up the initial stack. There may be some other important things that the ROM code does, but I can't name any off the top of my head.

I agree that adding such "gdb load" capability would be quite useful, we'll try to get this done.

[Ebiroll]

OK, Thanks. But if I want to make a test, where you flash an app that overrides start_cpu0 and sets up SPI-RAM and calls a "flash-ram swap function" that looks something like this,

void IRAM_ATTR flash_swap(void)
{
    unsigned int_state = portENTER_CRITICAL_NESTED();
    for (int i=0;i<NUM_PAGES_TO_SWAP;i++) { 
        uint32_t cache_val=i;  // *(uint32_t *)(0x61801200+i*4);
        cahce_val &= ~(MMU_ACCESS_FLASH);
        cahce_val |= (MMU_ACCESS_SPIRAM);
        *(uint32_t *)(0x61801200+i*4)=cache_val;
     }
     while(true) {
        ;
     portEXIT_CRITICAL_NESTED(int_state);
}

After that openocd is required to load the elf file. (gdb) load will use 'M' , write memory to load the elf file into SPI-RAM, or is this not possible until you set some IBUS, permission registers?

It also seems like the gdb elf load sets the PC to the entry function (call_start_cpu0). The app you load must make sure to define start_cpu0() and make sure not to call spi_flash_init(); , esp_flash_app_init() or heap_caps_malloc_extmem_enable().

Could this idea possibly work? I will make some experiments here, https://github.com/Ebiroll/esp32s2_kaluga/tree/master/examples/flash_swap I also noticed this function, esp_spiram_enable_instruction_access, what does it do, and why?

[svenstaro]

Can this issue be closed or is this still on the radar?