On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote:
It depends. For ARM we insist that the user provides the device tree that corresponds to the kernel they're going to run, and then we just tweak it a bit.
Um... device trees describe hardware, and should not be at all kernel-specific. Did you mean to say "the device tree that corresponds to the machine they're going to emulate"?
And I suppose you do have a kernel that corresponds to the machine it's going to run on, so what you say isn't *entirely* bogus. But it's just written in a way which makes it scary :)
On 14 May 2013 15:29, David Woodhouse dwmw2@infradead.org wrote:
On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote:
It depends. For ARM we insist that the user provides the device tree that corresponds to the kernel they're going to run, and then we just tweak it a bit.
Um... device trees describe hardware, and should not be at all kernel-specific. Did you mean to say "the device tree that corresponds to the machine they're going to emulate"?
No, I meant "corresponding to the kernel". (Qualifier to the following rant: I'm talking specifically about ARM; I understand PPC is different.)
In my experience if you try to use a device tree blob other than the one which you produce from the dts that is shipped with the exact revision of the kernel that you're booting, then it is likely to result in missing devices at best and quite likely random inexplicable crashes. ARM device trees are simply churning way too much at the moment (the usual failure behaviour is "device which was driven by board data gets a DT binding, so using an old DT means the kernel doesn't think the device exists at all", but I've seen crashes too). Maybe in a decade we'll be able to claim that device trees are a description of the hardware, but right now the fact is that this is a kernel specific data structure and it's not guaranteed to work with anything other than the kernel it goes with. If somebody reports a "this isn't booting" kind of bug, "are you using the right device tree blob for the kernel?" is among the first questions I ask (and I have zero interest in debugging cases where there's a mismatch.)
I make a very small exception for mach-virt, because it's entirely device tree driven and there's a very small set of things that appear in it. So we have a reasonable chance of holding kernel peoples' feet to the fire if they try to break existing device trees generated by QEMU or kvmtool. For anything else I am absolutely against having QEMU generate any ARM device tree blobs or do anything beyond the minimal modifications to them we absolutely must.
thanks -- PMM
-
David Woodhouse -
Peter Maydell