On 11/12/2012 05:50 AM, Pantelis Antoniou wrote: > Hi Rob. > > On Nov 11, 2012, at 10:47 PM, Rob Landley wrote: > >> On 11/09/2012 10:28:59 AM, Grant Likely wrote: >>> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> 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 > > It should be possible when the stuff we're talking about is ready. > > I don't know what you'll find is broken during the exercise, but I guess > your article is going to be entertaining at least :) To be honest, I think Rob's proposal should be possible irrespective of this conversation; if he wants to simply define the HW structure once before running qemu, then none of this overlay discussion is relevant. Perhaps the missing piece is the Documentation/devicetree/bindings/ directory? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
