From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrbaC-0005AL-TJ for qemu-devel@nongnu.org; Sun, 29 Jan 2012 15:42:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrbaB-00039s-LK for qemu-devel@nongnu.org; Sun, 29 Jan 2012 15:42:40 -0500 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:50641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrbaB-00039l-F6 for qemu-devel@nongnu.org; Sun, 29 Jan 2012 15:42:39 -0500 Received: by lahi5 with SMTP id i5so1326432lah.4 for ; Sun, 29 Jan 2012 12:42:37 -0800 (PST) Date: Sun, 29 Jan 2012 21:42:32 +0100 From: "Edgar E. Iglesias" Message-ID: <20120129204232.GA30311@zapo> References: <1327701190-24822-1-git-send-email-grant.likely@secretlab.ca> <201201272234.02700.paul@codesourcery.com> <20120128184837.GG2501@ponder.secretlab.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120128184837.GG2501@ponder.secretlab.ca> Subject: Re: [Qemu-devel] [PATCH] arm: add device tree support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Grant Likely Cc: Peter Maydell , qemu-devel@nongnu.org, Rob Herring , Peter Crosthwaite , Paul Brook , Jeremy Kerr On Sat, Jan 28, 2012 at 11:48:37AM -0700, Grant Likely wrote: > On Fri, Jan 27, 2012 at 10:34:01PM +0000, Paul Brook wrote: > > > If compiled with CONFIG_FDT, allow user to specify a device tree file using > > > the -dtb argument. If the machine supports it then the dtb will be loaded > > > into memory and passed to the kernel on boot. > > > > Adding annother machine feels wrong. Why does the board specific code need to > > know about this at all? You already going it via a global variable, so can't > > this be entirely contained within arm_boot.c? > > Mostly because the infrastructure isn't yet in place to pass the .dtb file > through to the arm_boot code (or maybe it is; what is the best way to pass > command line data through to the arm_boot.c code (or similar for other > architectures)? > > > If the board file is involved, why is it asking the user? > > There is a lot of configuration in the .dts file that the QEMU user may want > to manipulate; particularly when using QEMU for testing embedded platforms. > The direction I want to go is to select the machine model based on the top > level DT compatible property (making -M optional), and then also allow a lot > of the machine layout to be driven by DT data. ie. populate emulated devices > from DT data. > > I believe this is how Edgar is using the microblaze model, but I don't > think those patches have been upstreamed yet. I hope that microblaze, > ARM and powerpc can all use the same model here. Yes, that's right. > > > > > + versatile_init(ram_size, > > > + boot_device, > > > + kernel_filename, kernel_cmdline, > > > + initrd_filename, cpu_model, 0xffffffff); > > > > This only works because we're currently too dumb to emulate the differences > > between the two board variants. > > Yeah, this is a hack so I could play with forcing the machine id. > I'll remove it. > > > What we probably want to be doing is shipping/constructing device trees for > > the boards we implement, with an option to turn this on/off. Requiring a user > > to invent their own seems deeply sub-optimal given we know exactly what > > hardware we're emulating. A user that needs to provide their own FDT seems > > like a fairly rare corner case. > > I disagree. QEMU may want to ship stock .dts files, but it will > absolutely be a common use case for embedded developers to pass in > their own .dtb file. > > > This gets slightly more interesting when you have custom machine variants > > (i.e. once we fix the object model, and have proper dynamic machine > > construction). Even then I'd expect the FDT to be derived from/specificed by > > the machine description, not a separate option. > > I started with going down that route, but switched to this model after > playing with it and noticing that it doesn't seem to fit as well for > embedded development as providing a .dtb file and having QEMU > construct a machine that matches the data. That's the way I see it too. Our use-case is to build the virtual machine from the dtb. We then run the exact same software that runs on real hw. I don't know the details on how practical dtb's are for describing more complex bus hierarchies, maybe Peter has more info on that. Cheers, Edgar