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
