From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs Date: Fri, 9 Apr 2010 16:57:10 +0100 Message-ID: <201004091657.10684.paul@codesourcery.com> References: <20100407040129.20274.44284.stgit@angua> <201004091307.22473.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org List-Id: devicetree@vger.kernel.org > On Fri, Apr 9, 2010 at 6:07 AM, Paul Brook wrote: > >> Hi everyone, > >> > >> This is an experimental set of patches for populating the flattened > >> device tree (fdt) data from the actual set of qdevs in the platform. > >> I'm not expecting this to get merged anytime soon, but I wanted to get > >> it out there to solicit comments. My target for this is testing > >> device tree support on ARM. > > > > I think you need to convert some more interesting machines before it's > > possible to tell whether this is a sane setup. When investigating FDTs > > for creation of machine I found it's easy to invent something that can > > handle the simple integrator/cp board, but it all starts to fall apart > > when you encounter more complicated boards. In particular things like > > PCI, USB, I2C, etc. and strange bus configurations when you have both > > on-chip and external devices. > > Certainly. What would be a good (preferably ARM) platform to look at? > I'm fairly new to working with QEMU, so I'm not very familiar with > the platforms that are available. The versatile and readview boards both have PCI. The realview-eb-mpcore in particular has entertaining IRQ routing. The Stellaris boards have various devices hanging off I2C/SSI busses and/or GPO pins (though the stellaris boards aren't capable of running linux). The musicpal audio device may also be interesting as it's connected vi both i2s and gpio based i2c. All these should be fairly well qdev-ified. Arguably the most interesting is the PPC boards as we already know what device tree we need to generate. However these haven't been converted to qdev yet, and it's unclear how well the 4xx boards work to start with. Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0GaB-0002c0-Bi for qemu-devel@nongnu.org; Fri, 09 Apr 2010 11:57:23 -0400 Received: from [140.186.70.92] (port=49881 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0Ga9-0002bR-Ja for qemu-devel@nongnu.org; Fri, 09 Apr 2010 11:57:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0Ga7-00056t-MQ for qemu-devel@nongnu.org; Fri, 09 Apr 2010 11:57:21 -0400 Received: from mx20.gnu.org ([199.232.41.8]:38675) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0Ga7-00056n-KI for qemu-devel@nongnu.org; Fri, 09 Apr 2010 11:57:19 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1O0Ga7-0008U8-19 for qemu-devel@nongnu.org; Fri, 09 Apr 2010 11:57:19 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs Date: Fri, 9 Apr 2010 16:57:10 +0100 References: <20100407040129.20274.44284.stgit@angua> <201004091307.22473.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004091657.10684.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Grant Likely , devicetree-discuss@lists.ozlabs.org, jeremy.kerr@canonical.com > On Fri, Apr 9, 2010 at 6:07 AM, Paul Brook wrote: > >> Hi everyone, > >> > >> This is an experimental set of patches for populating the flattened > >> device tree (fdt) data from the actual set of qdevs in the platform. > >> I'm not expecting this to get merged anytime soon, but I wanted to get > >> it out there to solicit comments. My target for this is testing > >> device tree support on ARM. > > > > I think you need to convert some more interesting machines before it's > > possible to tell whether this is a sane setup. When investigating FDTs > > for creation of machine I found it's easy to invent something that can > > handle the simple integrator/cp board, but it all starts to fall apart > > when you encounter more complicated boards. In particular things like > > PCI, USB, I2C, etc. and strange bus configurations when you have both > > on-chip and external devices. > > Certainly. What would be a good (preferably ARM) platform to look at? > I'm fairly new to working with QEMU, so I'm not very familiar with > the platforms that are available. The versatile and readview boards both have PCI. The realview-eb-mpcore in particular has entertaining IRQ routing. The Stellaris boards have various devices hanging off I2C/SSI busses and/or GPO pins (though the stellaris boards aren't capable of running linux). The musicpal audio device may also be interesting as it's connected vi both i2s and gpio based i2c. All these should be fairly well qdev-ified. Arguably the most interesting is the PPC boards as we already know what device tree we need to generate. However these haven't been converted to qdev yet, and it's unclear how well the 4xx boards work to start with. Paul