Discuss here different C compiler set ups, and compiling executables for the ESP8266

User avatar
By jonsmirl
#67 Qemu supports the Xtensa processors. That is another way to debug. Once someone has hardware they can read the ROM contents out and load it and the flash contents into Qemu. Then as things get figured out various ROM calls can get replaced with stubs that print on the console or emulate the hardware.

The reason all of this support is in place is because you can run Linux on larger versions of Xtensa.
User avatar
By hackrid
#134 I could not find that lx3 is supported by quemu.
Very nice idea BTW.
User avatar
By jonsmirl
#140
hackrid wrote:I could not find that lx3 is supported by quemu.
Very nice idea BTW.


Here's the QEMU page. I'm don't know a lot about Extensa but I was under the impression that the processors are upwardly compatible. So one of these Qemu configurations is a superset of the LX3. http://wiki.linux-xtensa.org/index.php/Xtensa_on_QEMU
User avatar
By jonsmirl
#141 See the bit at the bottom, looks like the overlay files from Espressif are also used to configure Qemu.

Extending QEMU

To extend QEMU with new xtensa core an appropriate XtensaConfig structure must be registered. This structure may be mostly automatically filled in from the overlay data, see mainline commits 53add759be1a39063cfc52ca2a6d0fcdd1091697 (target-xtensa: add dc232b core) and 935f7a2b428f71a40e985f09955bccaaf09518fa (target-xtensa: add fsf core) for example:
target-xtensa/core-<core name>/core-isa.h is a copy of config/core.h from xtensa-config-overlay.tar.gz;
target-xtensa/core-<core name>/gdb-config.c is made from gdb/xtensa-config.c from xtensa-config-overlay.tar.gz, only rmap entries for PC, A*, AR*, SR*, UR* are retained;
XtensaConfig::gdb_regmap::num_regs is the total number of rmap entries in the gdb-config.c;
XtensaConfig::gdb_regmap::num_core_regs is the number of contiguous non-privileged ((flags & 1) == 0) rmap entries in the gdb-config.c.