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