On Fri, Apr 3, 2009 at 3:32 AM, Hollis Blanchard <holl...@us.ibm.com> wrote: > (I'll address the MMU issue in a separate mail.) > > On Thu, 2009-04-02 at 11:56 -0700, Rahul Kulkarni wrote: >> Another potential issue could be the initial environment (described >> earlier as option 2) not being what BSD expects. Do you use u-boot? >> You >> can see the initial environment set up in kvm_arch_vcpu_setup() in KVM >> and mpc8544ds_init() in Qemu. >> >> Rahul>> Yes..I will look into those functions..We do use uboot..Are >> you hinting to go with option 1? > > If you use u-boot then you might not have much work to do (option 2 will > probably work for you with few changes). > >> Does NetBSD use flattened device trees at all? KVM (Qemu) supplies a >> stripped-down device tree to the guest so that the guest won't try to >> access IO devices not currently emulated by qemu. If BSD has a >> hardcoded >> device configuration system (e.g. "we built for 8544, therefore we >> always have the following SoC devices") that will be an issue. >> >> Rahul>> The device config is hardcoded our NetBSD code base(more so >> because of the embedded nature it's a preferred way) but since I see >> NetBSD supported on Qemu..I would think there is a support available >> for a flattened device tree to be passed in from qemu..I'll look at >> x86 implementations. > > Really quick history: Traditionally, desktop/server PowerPC had Open > Firmware (IEEE1275). Open Firmware provides runtime services (sometimes > including IP stack, disk drivers, filesystems, etc), and those services > allow the kernel to retrieve a device tree describing the physical > topology of the system. The runtime services (callbacks) are relatively > high overhead for embedded systems, so traditionally embedded PowerPC > systems used something simpler (ppcboot/u-boot, redboot, CFE, homebrew, > etc). These systems usually hardcoded the expected set of IO devices at > build time. > > However, in recent years Linux developers have found that the > flexibility granted by the device tree is invaluable, even without the > runtime services. So they developed a "flat device tree" data structure > ("flat" because it's a contiguous in-memory format representing a tree), > and had firmware (especially u-boot) pass that tree to the kernel as a > binary blob. > > 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. :) > > 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? > > 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-disc...@ozlabs.org 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... -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html