From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXekS-0000z1-5c for qemu-devel@nongnu.org; Thu, 12 Feb 2009 11:49:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXekQ-0000y3-Eu for qemu-devel@nongnu.org; Thu, 12 Feb 2009 11:49:11 -0500 Received: from [199.232.76.173] (port=60777 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXekQ-0000xz-C9 for qemu-devel@nongnu.org; Thu, 12 Feb 2009 11:49:10 -0500 Received: from bsdimp.com ([199.45.160.85]:56169 helo=harmony.bsdimp.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXekP-0005En-O8 for qemu-devel@nongnu.org; Thu, 12 Feb 2009 11:49:10 -0500 Date: Thu, 12 Feb 2009 09:46:13 -0700 (MST) Message-Id: <20090212.094613.514366467.imp@bsdimp.com> Subject: Re: [Qemu-devel] [RFC] Machine description as data From: "M. Warner Losh" In-Reply-To: <49941AE3.1000806@gmx.net> References: <20090212040138.GD31142@yookeroo.seuss> 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, c-d.hailfinger.devel.2006@gmx.net Cc: devicetree-discuss@ozlabs.org, hollisb@us.ibm.com <87iqng0x3t.fsf@pike.pond.sub.org> <49941AE3.1000806@gmx.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In message: <49941AE3.1000806@gmx.net> Carl-Daniel Hailfinger writes: : > I didn't mean to say they are a bad idea for FDTs, just that they're on : > an awkward level of abstraction for QEMU configuration. There, I'd : > rather express a PCI address as "02:01.0" than as <0x00000220>. : > Translating text to binary is the machine's job, not the user's. : : Coreboot v3 is using some device tree variant which is IMHO a bit more : user friendly. The tree below is incomplete (for example, it leaves out : the PCI bus number and assumes that it is zero by default), but you : surely get the idea. : : /{ : mainboard_vendor = "Gigabyte"; : mainboard_name = "M57SLI"; : cpus { }; : apic@0 { : }; : domain@0 { : pci@0,0 { /* MCP55 RAM? */ : }; : pci@1,0 { : /config/("southbridge/nvidia/mcp55/lpc.dts"); : ioport@2e { I'd like to make a couple of comments here. One, I dislike the DTS syntax. It is hard to learn to read, and I always have to have the manual in my hands to read it. However, every board that's being produced for powerpc has the DTB at least available. It has to be, or (recent?) Linux kernels flat out won't work. This suggests that it might be a good idea to look at this format. There's DTS and DTB. One is the source, the other is the binary created from the source. I'd recommend that qemu actually use the DTB rather than the DTS to implement things. This way one could have a nicer syntax like the above and generate the DTB, or one could use the DTS provided by a vendor if there was a more specific board they wanted qemu to emulate. Carl-Daniel, how does coreboot v3 generate the data that's passed to the kernel? Warner