<div dir="ltr">On Sat, Oct 11, 2008 at 11:56 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net">rob@landley.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Friday 10 October 2008 18:44:23 Erik de Castro Lopo wrote:<br>
> Hi all,<br>
><br>
> Back in June, Fabrice Bellard posted a patch against SVN 4734:<br>
><br>
> <a href="http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00513.html" target="_blank">http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00513.html</a><br>
><br>
> to add configuration files to qemu.<br>
><br>
> It seems that this work was never merged into SVN and that patchset<br>
> does not apply to current SVN head.<br>
><br>
> Does anyone have an updated version of that patch or something similar?<br>
><br>
> Is there any interest in pushing this kind of functionality into<br>
> qemu mainline?<br>
<br>
</div>I point out that device trees are becoming standard in the Linux kernel, and<br>
being spread from powerpc and sparc to arm, mips, and so on. I attented a<br>
BOF about them at OLS, and there's even a mailing list for them now:<br>
<br>
<a href="https://ozlabs.org/mailman/listinfo/devicetree-discuss" target="_blank">https://ozlabs.org/mailman/listinfo/devicetree-discuss</a><br>
<br>
This means the Linux kernel already has data files which describe boards on<br>
architectures that don't have big defacto standard hardware layouts already<br>
implemented in C, and lots of 'em are yanking the C implementation in favor<br>
of using the device tree parser.<br>
<br>
Teaching qemu to parse a device tree means you get a ton of free board layouts<br>
from the linux kernel. (It also simplifies "-kernel" since lots of platforms<br>
need the flattened device tree passed in from the firmware...)<br></blockquote></div><br>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.<br>
<br>
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).<br>
<br>
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.)<br>
<br>
-Hollis<br></div>