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

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Sat, Jan 28, 2012 at 11:48:37AM -0700, Grant Likely wrote:
> On Fri, Jan 27, 2012 at 10:34:01PM +0000, Paul Brook wrote:
> > > If compiled with CONFIG_FDT, allow user to specify a device tree file using
> > > the -dtb argument.  If the machine supports it then the dtb will be loaded
> > > into memory and passed to the kernel on boot.
> > 
> > Adding annother machine feels wrong. Why does the board specific code need to 
> > know about this at all? You already going it via a global variable, so can't 
> > this be entirely contained within arm_boot.c?
> 
> Mostly because the infrastructure isn't yet in place to pass the .dtb file
> through to the arm_boot code (or maybe it is; what is the best way to pass
> command line data through to the arm_boot.c code (or similar for other
> architectures)?
> 
> > If the board file is involved, why is it asking the user?
> 
> 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 believe this is how Edgar is using the microblaze model, but I don't
> think those patches have been upstreamed yet.  I hope that microblaze,
> ARM and powerpc can all use the same model here.

Yes, that's right.

> > 
> > > +    versatile_init(ram_size,
> > > +                   boot_device,
> > > +                   kernel_filename, kernel_cmdline,
> > > +                   initrd_filename, cpu_model, 0xffffffff);
> > 
> > This only works because we're currently too dumb to emulate the differences 
> > between the two board variants.
> 
> Yeah, this is a hack so I could play with forcing the machine id.
> I'll remove it.
> 
> > What we probably want to be doing is shipping/constructing device trees for 
> > the boards we implement, with an option to turn this on/off.  Requiring a user 
> > to invent their own seems deeply sub-optimal given we know exactly what 
> > hardware we're emulating.  A user that needs to provide their own FDT seems 
> > like a fairly rare corner case.
> 
> I disagree.  QEMU may want to ship stock .dts files, but it will
> absolutely be a common use case for embedded developers to pass in
> their own .dtb file.
>
> > 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.

That's the way I see it too. Our use-case is to build the virtual machine
from the dtb. We then run the exact same software that runs on real hw.
I don't know the details on how practical dtb's are for describing more
complex bus hierarchies, maybe Peter has more info on that.

Cheers,
Edgar