From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GcIDA-00055p-Ea for qemu-devel@nongnu.org; Tue, 24 Oct 2006 05:04:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GcID7-00054q-N6 for qemu-devel@nongnu.org; Tue, 24 Oct 2006 05:04:39 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcID6-00054e-Bu for qemu-devel@nongnu.org; Tue, 24 Oct 2006 05:04:36 -0400 Received: from [71.162.243.5] (helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GcID5-0005vP-Qo for qemu-devel@nongnu.org; Tue, 24 Oct 2006 05:04:36 -0400 From: Rob Landley Subject: Re: [Qemu-devel] Config file support Date: Tue, 24 Oct 2006 05:04:09 -0400 References: <200610231822.59310.rob@landley.net> <200610240033.51392.paul@codesourcery.com> In-Reply-To: <200610240033.51392.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610240504.09647.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: Paul Brook Cc: qemu-devel@nongnu.org On Monday 23 October 2006 7:33 pm, Paul Brook wrote: > My intention is that a machine config file would remove the "motherboard" bits > altogether. ie. the config file describes everything that pc_init_1 does. The > first half of pc.c would remain because that's device emulation. Sounds highly cool. I'm quite in favor of _that_ kind of config file. > For things like network/serial/disks we need to figure out how to make the > machine description adapt to the config the user requested. Proably want to > replace the fixed tables eg. bs_table with some mechanism for > identifying/requesting disks by name. If some of the hardware could be hotpluggable, that would be cool. (I've hotpluged real IDE disks, ill-advised as that is.) I dunno what has ordering requirements (or more specifically, dependencies on previous hardware) though. > Take the Integrator/CP board as an example. I'd expect the machine config to > look something like: > > ram {base=0; size=RAM_SIZE, physaddr=0} > ram {base=0x80000000; size=RAM_SIZE, physaddr=0} > integrator_core{ram_size=RAM_SIZE}; > arm_cpu_pic {cpu_index=0, pic_name="CPU0"} > integrator_pic {pic_name="PRIMARY", base=0x14000000,parent="CPU0", > parent_irq=0, parent_fiq=1} > integrator_pic {pic_name="SECONDARY", base=0xca000000, pic="PRIMARY",irq=0, > fiq=1} > integrator_pit{base=0x13000000, pic="PRIMARY", irq=5} > pl011{base=0x16000000, name="serial0", pic="PRIMARY", irq=1} > etc. > > The syntax I just made up, and there are the issues I mentioned above, but > hopefully you get the idea. The syntax looks fine to me, and I can see where bits of that come from hw/integratorcp.c intergratorcp_init(), but when in that file I also see things like struct integratorcm_state and icp_pic_read() in there, and I don't know how they relate. The "here's a new device: it's a DMA controller" and "here's a new motherboard that has all these chips and devices on it wired together this way" is all mixed together in the same files. I have trouble figure out which bits belong to which categories. Possibly I should be poking at application emulation first, rather than system emulation. Easier to follow what's happening when you run "hello world"... Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery