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 <swar...@wwwdotorg.org> >> 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 :) Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
