From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GcAFj-0004Oh-G8 for qemu-devel@nongnu.org; Mon, 23 Oct 2006 20:34:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GcAFh-0004Nf-EB for qemu-devel@nongnu.org; Mon, 23 Oct 2006 20:34:47 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcAFh-0004NY-0t for qemu-devel@nongnu.org; Mon, 23 Oct 2006 20:34:45 -0400 Received: from [65.74.133.4] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GcAFg-0005zv-GK for qemu-devel@nongnu.org; Mon, 23 Oct 2006 20:34:44 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Config file support Date: Tue, 24 Oct 2006 01:34:39 +0100 References: <200610231822.59310.rob@landley.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610240134.40102.paul@codesourcery.com> 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, balrogg@gmail.com > > The things are what I was asking about. Assuming that QEMU has support > > for the appropriate processor type, support for the right bus > > controller(s), and support for various devices that can attach to that > > bus, what other information is needed to completely specify a machine? > > (You mention IRQ lines and DMA channels...) > > I'm pessimistic about machine config file support. I know little about > the PC-like machines in qemu but I've been playing with embedded > (system-on-chip) hw emulation and every new piece of hardware required > changes (even if very small) in the bus or cpu code as well, the > reason being that manufacturers are allowed to do any kind of tricks > in their hardware knowing that it doesn't need to be configurable, > being sold together as a single board. For example chips with totally > contrasting functions (take keypad input and LCD) are allowed to > communicate between themselves for good synchronisation, without > poking the main processor. A different example is a single device > occupying multiple "slots" on a given bus, or multiple busses. I'm more optimistic. Even SoC designs tend to be built up from modular components. While adding support for a totally new system may require changes, I think there's a good chance of being able to describe different variants of the similar devices (eg. all the different PrimeCell based integrator/versatile/Realview boards, or different members of the OMAP family). Paul