Re: [Qemu-devel] [PATCH] arm: add device tree support

[Paul Brook]

> 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 want to remove -M, and the associated board specific knowledge altogether.  
A system that can only create limited variants of hardcoded boards is IMO not 
a viable medium/long term solution.

> > 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.

Problem is that a FDT doesn't really tell you everything you need to know in 
order to construct the machine.  If you look back in the archives you should 
find that I tried something similar when I first added the qdev code.  While 
it appears to be a nice idea at first, it doesn't actually work do well in 
practice.  It's maybe OK for simple embedded systems with a single system bus, 
but when you start looking at more sophisticated machines it doesn't fit so 
well.  In particular when you look at things like PCI, devices connected via 
multiple busses (a sound codec with both I2C [command] and I2S [data] 
connections), and some of the stranger bus topographies (some ppc boards have 
lots of weirdness in the FDT) the requirements of qemu and linux start to 
diverge.

Clearly we need to have some sort of FDT support.  However I'm unconvinced 
that it's the correct format for the primary data structure.  For one thing 
it's a hierarchical tree structure, and in my experience describing links 
outside that structure gets hairy.  One of the things we're doing with QOM is 
move from a hierarchical tree/bus to a more general connected web of links 
between devices.

Paul