From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpQ8t-00085c-Ff for qemu-devel@nongnu.org; Mon, 13 Oct 2008 12:19:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpQ8s-00084r-Fq for qemu-devel@nongnu.org; Mon, 13 Oct 2008 12:19:34 -0400 Received: from [199.232.76.173] (port=60990 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpQ8s-00084l-BG for qemu-devel@nongnu.org; Mon, 13 Oct 2008 12:19:34 -0400 Received: from yw-out-1718.google.com ([74.125.46.152]:29378) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpQ8s-0007XF-0C for qemu-devel@nongnu.org; Mon, 13 Oct 2008 12:19:34 -0400 Received: by yw-out-1718.google.com with SMTP id 6so376127ywa.82 for ; Mon, 13 Oct 2008 09:19:32 -0700 (PDT) Message-ID: Date: Mon, 13 Oct 2008 11:19:32 -0500 From: "Hollis Blanchard" Sender: slightlyunconventional@gmail.com Subject: Re: [Qemu-devel] Fabrice Bellard 's QEMU configuration files In-Reply-To: <200810112356.39698.rob@landley.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21085_16514310.1223914772595" References: <20081011104423.38beecf8.mle+tools@mega-nerd.com> <200810112356.39698.rob@landley.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: devicetree-discuss@ozlabs.org ------=_Part_21085_16514310.1223914772595 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, Oct 11, 2008 at 11:56 PM, Rob Landley 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 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 ------=_Part_21085_16514310.1223914772595 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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
------=_Part_21085_16514310.1223914772595--