Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753531Ab2KKUrU (ORCPT ); Sun, 11 Nov 2012 15:47:20 -0500 Received: from mail-oa0-f46.google.com ([209.85.219.46]:60744 "EHLO mail-oa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751427Ab2KKUrT convert rfc822-to-8bit (ORCPT ); Sun, 11 Nov 2012 15:47:19 -0500 Date: Sun, 11 Nov 2012 14:47:13 -0600 From: Rob Landley Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) To: Grant Likely Cc: Stephen Warren , Pantelis Antoniou , Rob Herring , Deepak Saxena , Benjamin Herrenschmidt , Scott Wood , Tony Lindgren , Kevin Hilman , Matt Porter , Koen Kooi , linux-kernel , Felipe Balbi , Russ Dill , linux-omap@vger.kernel.org, devicetree-discuss@lists.ozlabs.org In-Reply-To: (from grant.likely@secretlab.ca on Fri Nov 9 10:28:59 2012) X-Mailer: Balsa 2.4.11 Message-Id: <1352666833.20434.5@driftwood> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2055 Lines: 41 On 11/09/2012 10:28:59 AM, Grant Likely wrote: > On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren > wrote: > > On 11/05/2012 01:40 PM, Grant Likely wrote: > I'm not actually opposed to it, but it needs to be done in an elegant > way. The DT data model already imposes more of a conceptual learning > curve than I wish it did and I don't want to make that worse with a > versioning model that is difficult to get ones head around. Speaking of which... I want to poke at board emulation in qemu, from scratch. Specifically, I want to start with an unpopulated board (just the processor), add a block of physical memory and a serial device, and boot an initramfs in there with stdin/stdout. Then I want to incrementally add an RTC, network card, and three block devices. I'd like to define this board by giving qemu and the kernel the same device tree they can parse, and I'd like to _build_ this device tree so I understand what's in it. I'd like to repeat this exercize for arm, mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards. And I'd like to write up an article on doing it as a learning exercise. Last time I checked, doing this wasn't possible. (qemu couldn't define a board by parsing a device tree, the kernel used the device tree as a guideline but it only really read data the drivers you linked in were expecting, the only documentation about what any of the nodes were was was read the other device trees as examples or read the source code of the drivers looking for data in the tree...) Is it a more realistic project now? If so, where would I start? (Once upon a time I read the booting-without-of document, back when it lived in the ppc directory. It didn't really say what should go in any of the nodes.) Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/