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

[James Hanley]

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 <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