Re: Fabrice Bellard 's QEMU configuration files

Re: Fabrice Bellard 's QEMU configuration files

[Hollis Blanchard]

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

On Sat, Oct 11, 2008 at 11:56 PM, Rob Landley <rob@landley.net> wrote:

> On Friday 10 October 2008 18:44:23 Erik de Castro Lopo wrote:
> > Hi all,
> >
> > Back in June, Fabrice Bellard posted a patch against SVN 4734:
> >
> >
> http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00513.html
> >
> > to add configuration files to qemu.
> >
> > It seems that this work was never merged into SVN and that patchset
> > does not apply to current SVN head.
> >
> > Does anyone have an updated version of that patch or something similar?
> >
> > Is there any interest in pushing this kind of functionality into
> > qemu mainline?
>
> I point out that device trees are becoming standard in the Linux kernel,
> and
> being spread from powerpc and sparc to arm, mips, and so on.  I attented a
> BOF about them at OLS, and there's even a mailing list for them now:
>
> https://ozlabs.org/mailman/listinfo/devicetree-discuss
>
> This means the Linux kernel already has data files which describe boards on
> architectures that don't have big defacto standard hardware layouts already
> implemented in C, and lots of 'em are yanking the C implementation in favor
> of using the device tree parser.
>
> Teaching qemu to parse a device tree means you get a ton of free board
> layouts
> from the linux kernel.  (It also simplifies "-kernel" since lots of
> platforms
> need the flattened device tree passed in from the firmware...)
>

FWIW, I've already had to teach qemu how to load and manipulate device trees
for my work with KVM on PPC440. Basically, rather than trying to run uboot
inside qemu, I have qemu replicate the post-uboot environment. That means
qemu is responsible for providing the device tree to the booted kernel.

There really wasn't a whole lot to it, really: just have the qemu board code
load a binary <board.dtb> file from the "pc-bios" (*ahem* ;) directory, and
use some libfdt calls to provide runtime information (e.g. memory layout).

Of course, the more complete solution would be to have qemu actually load
devices based on the contents of the device tree, so that you wouldn't need
to specify commandline options. (Erik, I have no idea why you think that's
orthogonal -- it's exactly what you're asking about.)

-Hollis

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