From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0HBm-0005RE-Cx for qemu-devel@nongnu.org; Fri, 09 Apr 2010 12:36:14 -0400 Received: from [140.186.70.92] (port=45223 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0HBi-0005PN-Js for qemu-devel@nongnu.org; Fri, 09 Apr 2010 12:36:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0HBg-00033p-2u for qemu-devel@nongnu.org; Fri, 09 Apr 2010 12:36:10 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:59208) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0HBd-00032d-Hz for qemu-devel@nongnu.org; Fri, 09 Apr 2010 12:36:07 -0400 Received: by pwi6 with SMTP id 6so2841586pwi.4 for ; Fri, 09 Apr 2010 09:36:04 -0700 (PDT) MIME-Version: 1.0 Sender: glikely@secretlab.ca In-Reply-To: <201004091657.10684.paul@codesourcery.com> References: <20100407040129.20274.44284.stgit@angua> <201004091307.22473.paul@codesourcery.com> <201004091657.10684.paul@codesourcery.com> From: Grant Likely Date: Fri, 9 Apr 2010 10:35:42 -0600 Message-ID: Subject: Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: devicetree-discuss@lists.ozlabs.org, qemu-devel@nongnu.org, jeremy.kerr@canonical.com On Fri, Apr 9, 2010 at 9:57 AM, Paul Brook wrote: >> 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 ge= t >> >> it out there to solicit comments. =A0My 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. =A0What would be a good (preferably ARM) platform to look at? >> =A0I'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. PCI shouldn't be too hairy. As long as the PCI bridge node is created with the right properties for ranges and irq mapping, then the child devices can be detected by the OS. Unlike the configuration case, I don't have to fully populate this part of the tree. :-D > The realview-eb-mpcore in > particular has entertaining IRQ routing. Fun. I'll probably look at this first. > =A0The Stellaris boards have various > devices hanging off I2C/SSI busses and/or GPO pins (though the stellaris > boards aren't capable of running linux). I'll skip that for now then. > The musicpal audio device may also be > interesting as it's connected vi both i2s and gpio based i2c. =A0All thes= e > should be fairly well qdev-ified. This looks like a good candidate too then. Getting i2c, spi and gpio sorted out is higher priority for me right now than pci. > Arguably the most interesting is the PPC boards as we already know what d= evice > tree we need to generate. =A0However these haven't been converted to qdev= yet, > and it's unclear how well the 4xx boards work to start with. :-) Thanks for the suggestions. I'll keep you posted on how things go. g. --=20 Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.