Re: [Qemu-devel] Using load_elf

[Blue Swirl]

On Mon, Apr 2, 2012 at 22:57, Brian Vandenberg
<address@hidden> wrote:
>  I'm attempting to familiarize myself with the APIs used to add
> support for boards in qemu, and I have a few questions.
>
> * How does using load_elf differ from load_image_targphys?
>
>  As an example, many of the boards I've looked at have a hard-coded
> entrypoint.  In mpc8455, it looks as though it doesn't have a
> hard-coded entrypoint but rather it gets the entrypoint directly from
> the kernel module.  However, I'm guessing in an actual mpc 8455 board,
> it would expect the image to be in ROM, which would be mapped at a
> particular address, and it would expect the entrypoint to be some
> fixed offset from the beginning of that ROM segment.
>
>  So, in terms of how qemu will use the image (and any other related
> info), how do load_elf and load_image_targphys differ?

ROM images are in form of binary blobs with no location information,
they must be loaded to a known address. For boot ROMs, the address
range would cover CPU hard reset entry vector.

ELF images specify the load and entry address (as well as symbol
tables, debugging info etc.), this is useful for kernel images but
also for ROMs where we have the source, like OpenBIOS on Sparc and
PPC.

Depending on machine setup, it's also possible to load only a kernel
and no ROM in QEMU. Of course on real machines, kernel images don't
just magically appear in RAM, some kind of ROM or flash is always
involved.

> * mpc8455 uses a device tree for describing a device-tree hierarchy to
> qemu.  Where should I look to find useful documentation describing
> these .dtb files (where they come from, what is used to create them,
> etc)?

The tool used is device tree compiler (http://jdl.com/software/ I think).

> * On a related note: I'm working on getting VxWorks to boot in qemu
> for a few different boards.  VxWorks doesn't use libfdt (or anything
> similar) to describe the hardware; the BSP does that job.  My
> assumption so far is that FDT is being used by qemu, but it's used to
> ease development in qemu; libfdt isn't being used to provide any
> information directly to the guest OS.  Is this a correct assumption?

The device tree is decorated by QEMU (for example memory size and host
clock speed), but it's not used internally by QEMU otherwise. This
tree is passed to the guest OS. If the guest doesn't use the tree, it
could be useful to make the FDT use optional.

>
> -Brian
>