Re: [Qemu-discuss] Custom board with DTS/DTB

[James Hanley]

Seems like I spoke too soon. Removed the DTB option and started down the road of building up our board as a test and connect gdb to the target with the --gdb option.

address@hidden:~/project/test$ gdb qemu-build/arm-softmmu/qemu-system-arm /tmp/cores/core.qemu-system-arm.3253.jim-VirtualBox.1481140001 

GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1

Copyright (C) 2016 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 "x86_64-linux-gnu".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from qemu-build/arm-softmmu/qemu-system-arm...done.

[New LWP 3256]

[New LWP 3254]

[New LWP 3253]

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Core was generated by `qemu-system-arm -M Boardx24 -m 256 -cpu cortex-m4 -no-reboot -nographic -S -singl'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  gic_test_pending (cm=<optimized out>, irq=<optimized out>, s=<optimized out>)

    at /home/jim/project/test/qemu/hw/intc/gic_internal.h:90

90    if (s->revision == REV_NVIC || s->revision == REV_11MPCORE) {

[Current thread is 1 (Thread 0x7f9c1758f700 (LWP 3256))]

(gdb) bt

#0  gic_test_pending (cm=<optimized out>, irq=<optimized out>, s=<optimized out>)

    at /home/jim/project/test/qemu/hw/intc/gic_internal.h:90

#1  gic_set_pending_private (s=0x0, cpu=0, irq=6)

    at /home/jim/project/test/qemu/hw/intc/arm_gic.c:136

#2  0x000056402fabe233 in cpu_handle_exception (ret=<synthetic pointer>, cpu=0x56403223c720)

    at /home/jim/project/test/qemu/cpu-exec.c:442

#3  cpu_exec (address@hidden) at /home/jim/project/test/qemu/cpu-exec.c:631

#4  0x000056402fae7b36 in tcg_cpu_exec (cpu=0x56403223c720)

    at /home/jim/project/test/qemu/cpus.c:1117

#5  qemu_tcg_cpu_thread_fn (arg=<optimized out>) at /home/jim/project/test/qemu/cpus.c:1197

#6  0x00007f9c2185b6ba in start_thread (arg=0x7f9c1758f700) at pthread_create.c:333

#7  0x00007f9c2159182d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

(gdb) 

On Sat, Nov 19, 2016 at 2:48 AM, Thomas Huth <address@hidden> wrote:

On 17.11.2016 23:14, James Hanley wrote:
> I saw the presentation on “Custom Hardware Modeling for FPGAs and
> Embedded Linux Platforms with QEMU” via
> http://free-electrons.com/pub/video/2010/elc/elc2010-williams-iglesias-fpga-qemu.ogv
> and was trying to apply the concepts described against our custom board
> design, and defining the board using dts.  I haven't been able to really
> get far and was looking for some guidance if this is the right direction.
> The mcu is a cortex-m4 (Atmel)
> The target firmware is running an RTOS (not Linux)
>
> QEMU emulator version 2.7.50 (v2.7.0-1890-g83c83f9-dirty)
> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
>
> It's my understanding that the dtb option passes a file that includes
> details of the machine that qemu can use to map out peripherals for it
> without having to compile the machine into qemu - is this a
> misunderstanding?

As far as I know, the -dtb parameter only passes the device tree blob to
the kernel image. I think QEMU does not look at the contents of that file.
So you've got to instantiate the corresponding devices manually with the
"-device" parameter of QEMU. Simply run QEMU with "-device ?" for a list
of supported devices.
However, I'm not familiar with ARM machines of QEMU, not sure whether
you can successfully populate a "none" machine that way. So you rather
might need to modify the source code by copying one of the existing
boards and adapting it to your needs.

> When I attempt to connect to qemu from gdb the qemu instance segfaults.

That should not happen. Can you get a backtrace to see where this happened?

 Thomas