On Fri, 2009-04-03 at 22:54 +0800, 刘宇 wrote: > > > The takeaway here is that the flat device tree is so far mostly a > > PowerPC Linux specific concept. Although the idea is beginning to > catch > > on with architectures and kernels, I expect that NetBSD doesn't know > > anything about it, and x86 Linux doesn't either. > > hmm. learnt a lot. Thanks. > seems qemu is going to adopt flat device tree. :) Coincidentally, virtual platforms like qemu also benefit from a device tree in a few ways. First, you can flexibly describe a system without needing 20 command line options. Second, firmware running in guest context also needs to know system topology, so qemu needs to provide that information somehow... Since ultimately the (PowerPC Linux) kernel needs the flat device tree, you might as well start with that. The other option would be to invent something new and then translate it into a flat device tree for the kernel. > > So since PowerPC NetBSD has build-time tables describing the > hardware it > > will try to use. I see the following options: > > 1) Teach NetBSD about flat device trees. Probably a lot of work. > > 2) Emulate more 85xx hardware in qemu. Maybe an easy to medium > amount of > > work, depending on the complexity and number of the IO devices. > > 3) Build a special NetBSD kernel with modified tables appropriate > for > > qemu. Probably the easiest/quickest way, but if your long-term goal > is > > to run unmodified NetBSD kernels built for real hardware, this is > only a > > prototyping step. > > > > If you have more than one person playing with this, #2 could be done > in > > conjunction with #3, until you've emulated all the necessary > devices. > > > > Also, if you do #2, you could actually use qemu (without KVM) as a > > development environment on normal x86 Linux or Windows workstations > (I > > think "virtual prototyping" or "virtual platforms" is the buzzword > these > > days). This might be a benefit for your internal software > development > > processes. > > btw, why did you give up virtio-net and change to e1000 on guest 440? Practically speaking, the 440 code was committed to qemu before the virtio drivers. Also, an arbitrary kernel (e.g. NetBSD) is more likely to have an e1000 driver than a virtio-net driver. Anyways, it's just the default. You can choose whatever you want with command line options. > > If there is interest (or maybe even existing work) in the NetBSD > > community for flat device tree support, you may be able to team up > with > > other developers to tackle problem #1. To find out, I would post to > > devicetree-discuss@xxxxxxxxxx asking if they've heard of NetBSD > work, > > and also NetBSD/PowerPC mailing lists to see if they've heard of > device > > tree work. > > > > It will be better to cc here... Good point. Rahul, when you mail those lists, you should CC this list too. Probably should just send one mail to all three. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
