ESP32 board support?

[dgtlrift]

I see there's ESP8266 support, any chance of the new ESP32 support being added?

[jcmvbkbc]

You might have noticed that ESP8266 support is very rudimentary.

Espressif haven't provided any feedback to my request for the hardware specifications of ESP32, I haven't been following ESP32 development/reverse engineering closely and I don't have the hardware ATM.
For the ESP32 support to appear something of the following need to happen: either somebody contributes the implementation (ideal, but doesn't sound likely), or somebody publishes hardware specifications (at least the subset with the memory layout and core peripherals description/register maps)/ROM dumps. In addition somebody willing to test that QEMU model behavior is somewhat close to the real hardware behavior is needed.

[Ebiroll]

I got my ESP32 board from adafruit. I have managed to dump the ROM and use it to start an elf file compiled with esp-idf in my patched version of QEMU. You can see the results here, https://github.com/Ebiroll/qemu_esp32 . However, I was wondering, what is the difference of this repository and the xtensa support in QEMU? (https://github.com/qemu/qemu) Thank you.

[jcmvbkbc]

Hi @Ebiroll
the master branch of this tree follows (with some noticeable lag) the master branch of the QEMU mainline.
Other branches are experimental (e.g. windowed*, xtensa-perf or xtensa-esp8266), work in progress (e.g. xtensa-ccount, xtensa-tcg, xtensa-user), not currently upstreamable for some reason, but having somewhat useful functionality (e.g. xtensa-nommu, xtensa-smp*) or some kind of helpers (e.g. xtensa-cores, xtensa-fp-test, xtensa-staging*, xtensa-trace, xtensa-xtfpga).

[Ebiroll]

Thanks a lot. I guess the xtensa-esp8266 branch would be most helpful for esp32 emulation work.
I had to make some rom patches to make it run, but proper hardware emulation would be much better.

Running gdb with qemu on assembly level works quite well, however when stepping through the c-code I get this assertion in gdb: /home/ivan/e/crosstool-NG/.build/src/gdb-7.10/gdb/regcache.c:697: internal-error: regcache_raw_read_unsigned: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
This happens sometimes at return from a function. Maybe it has something to do with a new task being created.

Any chance you have an idea of whats the cause of this problem? Has it something to do with the windowed call mechanism or interrupts screwing up the registers? Its really annoying and discourages any further work on this. If not stepping in but rather just setting a breakpoint or running (next) it runs well.

Here is your toolchain that espresstif are using.
https://github.com/espressif/crosstool-NG
https://github.com/espressif/esp-idf/blob/master/docs/linux-setup.rst

Thanks for your great work anyways.
/Olof

[jcmvbkbc]

I guess the xtensa-esp8266 branch would be most helpful for esp32 emulation work.

Sure, feel free to reuse it if it helps.

Running gdb with qemu on assembly level works quite well, however when stepping through the c-code I get this assertion in gdb: /home/ivan/e/crosstool-NG/.build/src/gdb-7.10/gdb/regcache.c:697: internal-error: regcache_raw_read_unsigned: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
This happens sometimes at return from a function. Maybe it has something to do with a new task being created.
Any chance you have an idea of whats the cause of this problem?

I believe it's gdb issue. Have seen it multiple times in different contexts with different xtensa cores in recent gdb versions, I'll likely have a chance to look deeper into it this week.

[Ebiroll]

Have seen it multiple times in different contexts with different xtensa cores in recent gdb versions,
I looked closer at the assert.
Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
I added some printouts to gdb and it seems that regnum is 116 and nr_raw_registers is 105. My guess is that 116 is the EPC1 register and that one is not included in the 'raw' registers.

If you look for register 116 you find it here
From gdb xtensa-config.c
XTREG(116,464,32, 4, 4,0x02b1,0x0007,-2, 2,0x1000,epc1, 0,0,0,0,0,0)

The only location that it is accessed by gdb is here,
In xtensa-tdep.c
static void
xtensa_window_interrupt_frame_cache (struct frame_info this_frame,
xtensa_frame_cache_t *cache,
CORE_ADDR pc)
{
...
/ Read PC of interrupted function from EPC1 register. */
epc1_regnum = xtensa_find_register_by_name (gdbarch,"epc1");
if (epc1_regnum < 0)
error(_("Unable to read Xtensa register EPC1"));

cache->ra = xtensa_read_register (epc1_regnum);
cache->pc = get_frame_func (this_frame);
}

I also did a analysis of the gdb-protocol that was sent, you can see it here,
https://github.com/Ebiroll/qemu_esp32/blob/master/gdbanalysis.md

When patching the xtensa_window_interrupt_frame_cache() functions it seems like qemu gets into to the interrupt function , _WindowUnderflow8, however I am not sure what to put in cache->ra.

It could be an error in the file core-esp32/gdb-config.c but when I add more than 105 registers then gdb complaints about Remote 'g' packet reply is too long....

[jcmvbkbc]

@Ebiroll looks like there are two issues here: first is that gdb overlay in the espressif crosstool-NG is not patched to mark all registers as unprivileged ( & ~1 in the 7th column of XTREG list in gdb/xtensa-config.c), second is that you've specified incorrect num_regs in https://github.com/Ebiroll/qemu_esp32/blob/master/qemu-patch/target-xtensa/core-esp32.c . It should work correctly with gdb corrected as said above if you just drop this line.

I've pushed a branch xtensa-esp32 with my version of the esp32 core to this repository, please take a look.
The combination of these two fixes works fine in my limited testing. I'll look at it some more.

[Ebiroll]

gdb overlay in the espressif crosstool-NG is not patched to mark all registers as unprivileged

Thanks, the gdb patch worked! That really improved the debugging experience when debugging with qemu. I also tested your xtensa-esp32 branch but had to comment out //gen_exception_cause(dc, ILLEGAL_INSTRUCTION_CAUSE); in the function gen_check_sr(), translate.c,
(register 97) SR 97 is not implemented
Other missing instructions,
WUR 234 not implemented, TBD(pc = 400971db)
WUR 235 not implemented, TBD(pc = 400971e0)
WUR 236 not implemented, TBD(pc = 400971e5)
But they do not generate exceptions. I guess these instructions are related to synchronisation between the cores.

static bool gen_check_sr(DisasContext *dc, uint32_t sr, unsigned access)
{
if (!xtensa_option_bits_enabled(dc->config, sregnames[sr].opt_bits)) {
if (sregnames[sr].name) {
qemu_log_mask(LOG_GUEST_ERROR, "SR %s is not configured\n", sregnames[sr].name);
} else {
qemu_log_mask(LOG_UNIMP, "SR %d %s is not implemented\n", sr);
}
//gen_exception_cause(dc, ILLEGAL_INSTRUCTION_CAUSE);

Keep the good work up and have a nice weekend!

[jcmvbkbc]

(register 97) SR 97 is not implemented

Oh, right, MEMCTL. I'll implement it.

WUR 234 not implemented, TBD(pc = 400971db)
WUR 235 not implemented, TBD(pc = 400971e0)
WUR 236 not implemented, TBD(pc = 400971e5)

These are the registers of the double precision floating point accelerator. I'll look at implementing it too.

BTW, this core (esp32) uses new hardware floating point, slightly different from what's in the QEMU right now, and with additional instructions for division and square root. It's still in WIP state at the xtensa-new-ops branch.

[Ebiroll]

Thanks for MEMCTL. It works fine.
Espressif have published a reference manual, updated with MMU chapter on the 9/11, 2016
http://espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf
Do you have the hardware now? I can make a pull request with ROM0 & ROM1 if you want.
Otherwise making a romdump is easy with esptool.py, esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 -b 921600 -p /dev/ttyUSB0 dump_mem 0x40000000 0x000C2000 rom0.bin

Also I have a question about the mapfile generated in the build directory by esp-idf. Is there anyway to use this information directly in gdb? The purpose of this is to get the name of the rom function in gdb when running in qemu. From the mapfile we know that uartAttach is here 0x40008fd0.
Rather than this,
(gdb) where
0x40008fd0 in ?? ()
0x40080990 in call_start_cpu0
I would like to see this,
0x40008fd0 in uartAttach
0x40080990 in call_start_cpu0
I tried adding -defsym=uartAttach=0x40008fd0 when linking but not with any success.
Try using, make VERBOSE=1 , with esp-idf to see how its compiled and linked. It would help a lot when trying to understand the code in the romdump.

[jcmvbkbc]

Espressif have published a reference manual, updated with MMU chapter on the 9/11, 2016

Thanks, I'll take a look.

Do you have the hardware now?

No, not yet. Looks like I won't have time to play with it for the following several weeks anyway.

I can make a pull request with ROM0 & ROM1 if you want.

Ok, I can take a look.

Also I have a question about the mapfile generated in the build directory by esp-idf. Is there anyway to use this information directly in gdb? The purpose of this is to get the name of the rom function in gdb when running in qemu.

Not that I know of. OTOH I did this for ESP8266 for the same purpose. The resulting elf may be loaded into gdb with 'add-symbol-file' command.

[Ebiroll]

Thanks, almost works for me, not sure how to modify this though

rom-functions.s: esp32.rom.ld
sed -n 's/PROVIDE[[:space:]]([[:space:]]([^[:space:]=]+)[^0]+(0x4.......).*/\1 = \2 - 0x40000000 + _stext\n.global \1\n.type \1, @function/p' < $^ &gt; $@
Whe I run I get this,
(gdb) add-symbol-file rom.elf
The address where rom.elf has been loaded is missing

Output from make
xtensa-esp32-elf-ld -M -T bootrom.ld -r bootrom.o -o bootrom.elf
xtensa-esp32-elf-ld: bootrom.elf section .text' will not fit in regionbootrom0'

Discarded input sections

.data 0x0000000000000000 0x0 bootrom.o
.bss 0x0000000000000000 0x0 bootrom.o

Memory Configuration

Name Origin Length Attributes
bootrom0 0x0000000040000000 0x0000000000010000
default 0x0000000000000000 0xffffffffffffffff

Linker script and memory map

.text 0x0000000040000000 0xc2000
*(.text)
.text 0x0000000040000000 0xc2000 bootrom.o
0x0000000040000000 _WindowOverflow4
0x0000000040000010 _xtos_alloca_handler
0x0000000040000040 _WindowUnderflow4
0x0000000040000080 _WindowOverflow8

[Ebiroll]

Sorry, I was in a hurry.
(gdb) add-symbol-file rom.elf 0x40000000 did the trick.

[Ebiroll]

@jcmvbkbc any time to update xtensa-esp32 yet?

I tried to look at the new-ops branch and tried to add the missing instructions here. https://github.com/Ebiroll/qemu-xtensa-esp32
There is not support for DFP accelerator in xtensa-gcc at the moment so I guess there is no need to add all floating point coprocessor instructions. I guess it is also not really necessary to add the RUR and WUR instructions either as its not used in the code. After the rom lets the control to the app.elf file xthal_restore_extra_nw is not called and these instructions are not called at all.

I have also added an open core lwip ethernet driver, but never got interrupts to work. I need to look closer at this. I did something like this.
xtensa_get_extint(env, 9)
s = SYS_BUS_DEVICE(dev);
sysbus_connect_irq(s, 0, irq);

But when I called qemu_irq_raise(s->irq); no interrupt was generated. Any ideas?
Probably some numbering mismatch or maybe I should try to call qemu_irq_pulse() in case the interrupt is edge triggered.

This is how interrupt handler is added by the real esp32 ether-net driver.
static void emac_enable_intr()
{
//init emac intr
REG_SET_FIELD(DPORT_PRO_EMAC_INT_MAP_REG, DPORT_PRO_EMAC_INT_MAP, ETS_EMAC_INUM);
xt_set_interrupt_handler(ETS_EMAC_INUM, emac_process_intr, NULL);
xt_ints_on(1 << ETS_EMAC_INUM);

REG_WRITE(EMAC_DMAINTERRUPT_EN_REG, EMAC_INTR_ENABLE_BIT);

}

[jcmvbkbc]

irq = xtensa_get_extint(env, 9)

AFAICS 9 is the internal IRQ number, not the external. Should be irq = env->irq_inputs[9];