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
