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