Xtensa on QEMU

Setting up and running Xtensa simulation on QEMU

QEMU is a free processor/machine emulator and virtualizer.

Starting with version 1.0 QEMU offers Xtensa architecture emulation. DC232B (LE) and fsf (BE) cores are supported on sim and LX60/LX200 platforms.

Getting and building QEMU

QEMU is developed using git. The main tree is located at git://git.qemu.org/qemu.git. Release tarballs and guest systems images are available at http://wiki.qemu.org/Download.

This will make a copy of master QEMU repository, configure, build and install QEMU binaries for little-endian and big-endian targets:

 $ git clone git://git.qemu.org/qemu.git
 $ mkdir qemu-xtensa ; cd qemu-xtensa
 $ ../qemu/configure --prefix=`pwd`/root --target-list=xtensa-softmmu,xtensaeb-softmmu
 $ make install

QEMU options

Option	Meaning	Example
-M <machine-name>	Emulate specific platform type. Use '?' to list all supported platform types.	-M lx60
-cpu <core-name>	Emulate specific core type. Use '?' to list all supported core types.	-cpu dc232b
-m megs	Set emulated RAM size to megs MB	-m 128
-semihosting	Enable SIMCALL instruction for the protection ring 0.	-semihosting
-kernel <elf-image>	Load elf-image and start emulation from its entry point. Note that image is loaded to virtual addresses it is linked for. For LX60/LX200 this option also chooses 'boot from SRAM' mode, mapping SRAM to the System ROM region at physical address 0xFE000000.	-kernel xtensa-2.6.29-smp/arch/xtensa/boot/Image.elf
-append <kernel arguments>	(Not for sim) Wrap kernel arguments into the bootparameters block and pass pointer to it to the elf-image in a2.	-append 'console=ttyS0 ip=dhcp root=/dev/nfs rw'
-pflash <flash-image>	(Not for sim) Mount flash-image as a system FLASH. Note that image size must match platform FLASH size (4MB for LX60, 16MB for LX200).	-pflash u-boot.dc232b_xtav200.flash
-net nic,<nic-parameters>	(Not for sim) Set network interface parameters.	-net nic,vlan=0
-net user,<SLIRP parameters>	(Not for sim) Use the user mode network stack. SLIRP parameters may be used to tune built-in DHCP and TFTP servers.	-net user,vlan=0,tftp=.,hostname=dc232b-lx200

sim platform

The sim platform is modelled after Tensilica ISS. It may run ELF images built for ISS, see e.g. Build and Run a Linux Kernel on the Instruction Set Simulator (ISS). There's only SIMCALL external interface available for the sim machine. To avoid console interference with QEMU monitor, monitor should be disabled with -monitor null or moved to network interface.

 $ qemu-system-xtensa -cpu dc232b -M sim -m 128M -semihosting -nographic -monitor null \
   -kernel sim-2.6.29-smp/arch/xtensa/boot/Image.elf

LX60/LX200 platform

LX60/LX200 platform emulates system RAM, board-specific FPGA, UART, OpenCores 10/100 Mbit Ethernet MAC, National Semiconductors DP83848C 10/100 PHY and parallel FLASH. The platform may boot from either SRAM (when -kernel option is specified, SRAM is mapped to the System ROM region and ELF image is loaded) or from FLASH.

NFS root export record for user network (there's no way to specify root-path option for the QEMU builtin DHCP server. Unless kernel parameter 'rootpath' is given, you'll have to put the rootfs to /tftpboot/<hostname>):

 /tftpboot/      127.0.0.1(rw,no_root_squash,insecure)

Booting linux image from SRAM (FLASH not mapped):

 $ qemu-system-xtensa -cpu dc232b -M lx200 -m 96M -nographic \
   -net nic,vlan=0 -net user,vlan=0,tftp=.,hostname=dc232b-lx200 \
   -kernel lx60-2.6.29-smp/arch/xtensa/boot/Image.elf

Booting u-boot image from SRAM (empty FLASH image is created and mapped):

 $ head -c 16M /dev/zero > lx200.flash
 $ qemu-system-xtensa -cpu dc232b -M lx200 -m 96M -nographic \
   -net nic,vlan=0 -net user,vlan=0,tftp=.,hostname=dc232b-lx200 -pflash lx200.flash \
   -kernel u-boot-xtensa.git/u-boot.dc232b_xtav200

In this scenario binary u-boot image may be downloaded from TFTP and copied to the FLASH as described here.

Alternatively FLASH image containing u-boot may be preformatted and QEMU may be booted from it:

 $ cat u-boot-xtensa.git/u-boot.bin.dc232b_xtav200 /dev/zero | head -c 16M > lx200.flash
 $ qemu-system-xtensa -cpu dc232b -M lx200 -m 96M -nographic \
   -net nic,vlan=0 -net user,vlan=0,tftp=.,hostname=dc232b-lx200 -pflash lx200.flash

Debugging with QEMU

There's builtin GDB server in the QEMU. -s command line switch activates it on the address 0.0.0.0:1234, -S switch stops QEMU at the first guest instruction waiting for 'continue' command from gdb.

 $ qemu-system-xtensa -M lx200 -nographic -pflash lx200.flash \
   -net nic,vlan=0 -net user,vlan=0,tftp=.,hostname=dc232b-lx200 \
   -kernel u-boot-xtensa.git/u-boot.dc232b_xtav200 -s -S

By default xtensa gdb may only access unprivileged core registers. To allow access to all available registers ./gdb/xtensa-config.c needs to be modified, marking privileged registers as non-privileged.

GDB breakpoints, watchpoints, single-stepping and other debugging features work as usual.

 $ xtensa-dc232b-elf-gdb
 GNU gdb (GDB) 7.3.50.20110709-cvs
 Copyright (C) 2011 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
 and "show warranty" for details.
 This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=xtensa-dc232b-elf".
 For bug reporting instructions, please see:
 <http://www.gnu.org/software/gdb/bugs/>.
 (gdb) target remote 127.0.0.1:1234
 Remote debugging using 127.0.0.1:1234
 0xfe000000 in ?? ()
 (gdb) symbol-file u-boot-xtensa.git/u-boot.dc232b_xtav200
 Reading symbols from u-boot-xtensa.git/u-boot.dc232b_xtav200...done.
 (gdb) x/10i $pc
 => 0xfe000000 <_ResetVector>:   j       0xfe00000c <_ResetVector+12>
    0xfe000003 <_ResetVector+3>: break   0, 0
    0xfe000006 <_ResetVector+6>: excw
    0xfe000009 <_ResetVector+9>: .byte 0xff
    0xfe00000a <_ResetVector+10>:        .byte 0xff
    0xfe00000b <_ResetVector+11>:        .byte 0xff
    0xfe00000c <_ResetVector+12>:        l32r    a2, 0xfe000004 <_ResetVector+4>
    0xfe00000f <_ResetVector+15>:        jx      a2
    0xfe000012 <_ResetVector+18>:        ill
    0xfe000015 <_ResetVector+21>:        subx2   a0, a0, a0
 (gdb) si
 69      1:      l32r    a2, 2b
 (gdb)

QEMU monitor commands may be invoked via gdb monitor command:

 (gdb) monitor info mtree
 memory
 00000000-fffffffe (prio 0): system
   00000000-07ffffff (prio 0): lx60.dram
   f0000000-fdffffff (prio 0): lx60.io
     fd020000-fd02ffff (prio 0): lx60.fpga
     fd030000-fd030053 (prio 0): open_eth.regs
     fd030400-fd0307ff (prio 0): open_eth.desc
     fd050020-fd05003f (prio 0): serial
     fd800000-fd803fff (prio 0): open_eth.ram
   f8000000-f83fffff (prio 0): lx60.io.flash
   fe000000-fe01ffff (prio 0): lx60.sram

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.