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

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

[James Hanley]

[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]

I'm moving my query to QEMU-Arm since it seems more applicable here.
   1) It seems that the -dtb option is not what I thought it was, but would
something like what I thought was the intent of the option be of value to
QEMU, that is to define the board support package for the system using DTC
to compile and pass into QEMU to define a generic board from the tree,
rather then defining the hardware within the code base of QEMU?  I
understand that there will always be some need for device support and
deginition from within the codebase, but this was more to allow the user to
define hardware board profiles without having to change source code.
   2) Right now, I'm trying to run our embedded application (EmbOS RTOS
with DLib with our application support all targeted for Cortex-M4 MPU) and
it seems like QEMU (at least from variable names) wants to believe that
under boot.c and loader.c that the passed in application (using --kernel
option) is linux.  Is this proper behavior - or is there someway to pass
the statically linked code-flash binary to execute? Our binary is note
Linux, and is running EmbOS an RTOS. Note that this CM4 module executes
from code flash.

Thanks much,
-Jim


On Sat, Nov 19, 2016 at 2:48 AM, Thomas Huth <thuth@redhat.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3767 bytes --]

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

[Peter Maydell]

On 5 December 2016 at 17:51, James Hanley <jhanley@dgtlrift.com> wrote:
> I'm moving my query to QEMU-Arm since it seems more applicable here.
>    1) It seems that the -dtb option is not what I thought it was, but would
> something like what I thought was the intent of the option be of value to
> QEMU, that is to define the board support package for the system using DTC
> to compile and pass into QEMU to define a generic board from the tree,
> rather then defining the hardware within the code base of QEMU?  I
> understand that there will always be some need for device support and
> deginition from within the codebase, but this was more to allow the user to
> define hardware board profiles without having to change source code.

The problem is that DTC is not designed for that job. It describes
those aspects of the hardware that the kernel cares about, which
overlaps with but isn't the same as the information that you would
need to build a complete model of the hardware. So the idea has been
suggested before but I think it would in practice be pretty unreliable
(and for 99% of dtb files it would just not work anyway, because QEMU doesn't
model the devices that the dtb describes).

>    2) Right now, I'm trying to run our embedded application (EmbOS RTOS with
> DLib with our application support all targeted for Cortex-M4 MPU) and it
> seems like QEMU (at least from variable names) wants to believe that under
> boot.c and loader.c that the passed in application (using --kernel option)
> is linux.

M-profile is different and doesn't generally use boot.c -- the board
model code ends up calling armv7m_init() which treats kernel_filename
as a random ELF file. (A profile --kernel will also treat an ELF
file as an ELF file, it just has special casing to handle Linux kernels and
assumes a raw binary is a kernel.)

If you're running one of the 2.8 rc candidates you can also use
-device loader to load an arbitrary file (see docs/generic-loader.txt).

thanks
-- PMM

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

[James Hanley]

[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]

Thanks - I'm using the -device option to load the binaries, but have run
into another issue with setting the program counter.

qemu-system-arm: -device loader,cpu-num=0,addr=0x00400000: cpu_num must be
specified when setting a program counter

I believe the error isn't precise since the token defined in the
generic_loader_props is
DEFINE_PROP_UINT32("cpu-num", GenericLoaderState, cpu_num, CPU_NONE),
I'm just not sure why it's not capturing the cpu-num parameter.

On Wed, Dec 7, 2016 at 4:25 AM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 5 December 2016 at 17:51, James Hanley <jhanley@dgtlrift.com> wrote:
> > I'm moving my query to QEMU-Arm since it seems more applicable here.
> >    1) It seems that the -dtb option is not what I thought it was, but
> would
> > something like what I thought was the intent of the option be of value to
> > QEMU, that is to define the board support package for the system using
> DTC
> > to compile and pass into QEMU to define a generic board from the tree,
> > rather then defining the hardware within the code base of QEMU?  I
> > understand that there will always be some need for device support and
> > deginition from within the codebase, but this was more to allow the user
> to
> > define hardware board profiles without having to change source code.
>
> The problem is that DTC is not designed for that job. It describes
> those aspects of the hardware that the kernel cares about, which
> overlaps with but isn't the same as the information that you would
> need to build a complete model of the hardware. So the idea has been
> suggested before but I think it would in practice be pretty unreliable
> (and for 99% of dtb files it would just not work anyway, because QEMU
> doesn't
> model the devices that the dtb describes).
>
> >    2) Right now, I'm trying to run our embedded application (EmbOS RTOS
> with
> > DLib with our application support all targeted for Cortex-M4 MPU) and it
> > seems like QEMU (at least from variable names) wants to believe that
> under
> > boot.c and loader.c that the passed in application (using --kernel
> option)
> > is linux.
>
> M-profile is different and doesn't generally use boot.c -- the board
> model code ends up calling armv7m_init() which treats kernel_filename
> as a random ELF file. (A profile --kernel will also treat an ELF
> file as an ELF file, it just has special casing to handle Linux kernels and
> assumes a raw binary is a kernel.)
>
> If you're running one of the 2.8 rc candidates you can also use
> -device loader to load an arbitrary file (see docs/generic-loader.txt).
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 3285 bytes --]

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

[Thomas Huth]

On 07.12.2016 21:31, James Hanley wrote:
> 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.
> jim@jim-VirtualBox:~/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

Looks like QEMU is crashing because s is NULL ... but the backtrace
below does not really help here anymore. So maybe add some printfs to
see where the s = NULL is coming from?

> #2  0x000056402fabe233 in cpu_handle_exception (ret=<synthetic pointer>,
> cpu=0x56403223c720)
>     at /home/jim/project/test/qemu/cpu-exec.c:442
> #3  cpu_exec (cpu=cpu@entry=0x56403223c720) 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) 

 Thomas

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

[Edgar E. Iglesias]

On Wed, Dec 07, 2016 at 09:25:15AM +0000, Peter Maydell wrote:
> On 5 December 2016 at 17:51, James Hanley <jhanley@dgtlrift.com> wrote:
> > I'm moving my query to QEMU-Arm since it seems more applicable here.
> >    1) It seems that the -dtb option is not what I thought it was, but would
> > something like what I thought was the intent of the option be of value to
> > QEMU, that is to define the board support package for the system using DTC
> > to compile and pass into QEMU to define a generic board from the tree,
> > rather then defining the hardware within the code base of QEMU?  I
> > understand that there will always be some need for device support and
> > deginition from within the codebase, but this was more to allow the user to
> > define hardware board profiles without having to change source code.
> 
> The problem is that DTC is not designed for that job. It describes
> those aspects of the hardware that the kernel cares about, which
> overlaps with but isn't the same as the information that you would
> need to build a complete model of the hardware. So the idea has been
> suggested before but I think it would in practice be pretty unreliable
> (and for 99% of dtb files it would just not work anyway, because QEMU doesn't
> model the devices that the dtb describes).

Hi,

I mostly agree with what Peter says. Saying that, we (in the Xilinx tree) have
a system where we create a QEMU machine from a device-tree.
We've abandoned the idea of using a plain Linux DTS (with the Linux bindings)
for the reasons Peter mentions. Instead we use a set of extended bindings
+ we expose the QEMU device properties as they are.

So far we can describe everything we've needed, included complex memory
hierarchies with multiple address-spaces and memory translation/protection units
(IOMMUs, MPUs etc). Complex and multiple IRQ trees, power management structures
and signals to communicate between devices etc.

This is very useful to us but I'm not sure adding the current version of
our implementation makes sense to upstream.

A better option is perhaps to allow machine creation fully over QMP and
implement a DTS (could be XML or something else) parser outside of QEMU
that creates the machine over QMP. We could then support any kind of
format and a DTS/DTB instantiator could be written in python for example.

Best regards,
Edgar

> 
> >    2) Right now, I'm trying to run our embedded application (EmbOS RTOS with
> > DLib with our application support all targeted for Cortex-M4 MPU) and it
> > seems like QEMU (at least from variable names) wants to believe that under
> > boot.c and loader.c that the passed in application (using --kernel option)
> > is linux.
> 
> M-profile is different and doesn't generally use boot.c -- the board
> model code ends up calling armv7m_init() which treats kernel_filename
> as a random ELF file. (A profile --kernel will also treat an ELF
> file as an ELF file, it just has special casing to handle Linux kernels and
> assumes a raw binary is a kernel.)
> 
> If you're running one of the 2.8 rc candidates you can also use
> -device loader to load an arbitrary file (see docs/generic-loader.txt).
> 
> thanks
> -- PMM
>