Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Rob Landley <rob@landley.net>]

               On 11/09/2012 10:28:59 AM, Grant Likely wrote:
> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren  
> <swarren@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