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
