qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] arm: add device tree support


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH] arm: add device tree support
Date: Sun, 29 Jan 2012 17:48:44 +1000

Hi Grant,

The patch series for dts driven machine creation we (myself and Edgar) use that you are referring to was rejected a few months ago on the grounds that it conflicted with QOM:

http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02953.html

I am maintaining it our of tree, although I have not fast forwarded that branch for a while, so I cant recreate that series quickly. But now that QOM is immenent, can we get another review on the original series, and comments on what needs to happen to make this play nice with QOM? There is nothing in this series that is target specific, Adaption for arm should be fairly trivial.

Peter

On Fri, Jan 27, 2012 at 10:34:01PM +0000, Paul Brook wrote:
> > If compiled with CONFIG_FDT, allow user to specify a device tree file using
> > the -dtb argument.  If the machine supports it then the dtb will be loaded
> > into memory and passed to the kernel on boot.
>
> Adding annother machine feels wrong. Why does the board specific code need to
> know about this at all? You already going it via a global variable, so can't
> this be entirely contained within arm_boot.c?

Mostly because the infrastructure isn't yet in place to pass the .dtb file
through to the arm_boot code (or maybe it is; what is the best way to pass
command line data through to the arm_boot.c code (or similar for other
architectures)?

> If the board file is involved, why is it asking the user?

There is a lot of configuration in the .dts file that the QEMU user may want
to manipulate; particularly when using QEMU for testing embedded platforms.
The direction I want to go is to select the machine model based on the top
level DT compatible property (making -M optional), and then also allow a lot
of the machine layout to be driven by DT data.  ie. populate emulated devices
from DT data.

I believe this is how Edgar is using the microblaze model, but I don't
think those patches have been upstreamed yet.  I hope that microblaze,
ARM and powerpc can all use the same model here.

>
> > +    versatile_init(ram_size,
> > +                   boot_device,
> > +                   kernel_filename, kernel_cmdline,
> > +                   initrd_filename, cpu_model, 0xffffffff);
>
> This only works because we're currently too dumb to emulate the differences
> between the two board variants.

Yeah, this is a hack so I could play with forcing the machine id.
I'll remove it.

> What we probably want to be doing is shipping/constructing device trees for
> the boards we implement, with an option to turn this on/off.  Requiring a user
> to invent their own seems deeply sub-optimal given we know exactly what
> hardware we're emulating.  A user that needs to provide their own FDT seems
> like a fairly rare corner case.

I disagree.  QEMU may want to ship stock .dts files, but it will
absolutely be a common use case for embedded developers to pass in
their own .dtb file.

> This gets slightly more interesting when you have custom machine variants
> (i.e. once we fix the object model, and have proper dynamic machine
> construction).  Even then I'd expect the FDT to be derived from/specificed by
> the machine description, not a separate option.

I started with going down that route, but switched to this model after
playing with it and noticing that it doesn't seem to fit as well for
embedded development as providing a .dtb file and having QEMU
construct a machine that matches the data.

g.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]