From: Hollis Blanchard <hollis@penguinppc.org>
To: Baojun Wang <wangbj@gmail.com>
Cc: Blue Swirl <blauwirbel@gmail.com>,
"Richard W.M. Jones" <rjones@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] PowerPC 440 support
Date: Tue, 16 Jun 2009 10:36:17 -0500 [thread overview]
Message-ID: <fb412d760906160836l73dea987hc2416d62f733f905@mail.gmail.com> (raw)
In-Reply-To: <3cdfa5bc0906160812y2dc670dfqb61015a0373c72f4@mail.gmail.com>
On Tue, Jun 16, 2009 at 10:12 AM, Baojun Wang<wangbj@gmail.com> wrote:
> I think the idea is very good, otherwise it will take too much time to
> finish, and it gives us a way to lauch kernel directly without a
> firmware.
Note however that this approach means qemu must initialize the target
as if u-boot had. Practically speaking, that means device tree,
initial register values, and also TLB entries. At least on some
platforms, u-boot leaves a UART mapping for early kernel use.
> I have some question about the new qemu device tree, in ppc440_bamboo.c:
>
> function bamboo_load_device_tree() is only usable when HAVE_FDT
> defined as 1, but currently (even with git version) version (0.10.5)
> we can not enable this feature? I have forced HAVE_FDT to be defined
> by:
>
> echo '#define HAVE_FDT 1' >> config-host.h
>
> &
>
> echo 'FDT_LIBS=-lfdt' >> config-host.mak
>
> but that lead to compile error, seems device tree in qemu is not fully
> populated?
Do you have libfdt installed? If so, configure should have found it,
and you wouldn't need to mess with config-host.* manually.
Currently there are no distribution packages for libfdt. You must
download dtc source (http://git.jdl.com/gitweb/?p=dtc.git;a=summary)
and install libfdt by hand from there.
-Hollis
> Regard & Thanks,
> Wang
>
> On Mon, Jun 15, 2009 at 11:46 PM, Hollis Blanchard<hollis@penguinppc.org> wrote:
>> KVM PPC execution doesn't use firmware today. Instead we create the device
>> tree in qemu itself, stuff it into guest memory, and point a guest register
>> at it on entry. This was just a shortcut/hack, because we didn't have enough
>> time to enable both Linux and uboot.
>>
>> I agree that the best way to do things long-term is to run u-boot inside the
>> guest environment. That will likely require improvements to qemu's device
>> emulation, and also we'll probably need to work out a way for qemu to pass
>> parameters (e.g. memory size) to u-boot. IMHO, the best approach there would
>> be to have u-boot interpret a device tree from qemu, then modify it and pass
>> it on to the kernel. Obviously that will require u-boot work.
>>
>> -Hollis
>>
>> On Sun, Jun 14, 2009 at 11:40 PM, Baojun Wang <wangbj@gmail.com> wrote:
>>>
>>> It seems most boards will converted to the device tree infrastructure?
>>>
>>> but I think we will need a firmware first before loading the linux
>>> kernel, I don't know if qemu-system-ppcemb could run kernel directly
>>> without a firmware..
>>>
>>> Best Regards,
>>> Wang
>>>
>>> On Mon, Jun 15, 2009 at 3:46 AM, Hollis Blanchard<hollis@penguinppc.org>
>>> wrote:
>>> > My 440 board is inaccessible for a couple weeks, so I can't test your
>>> > patch. That said, the code looks fine.
>>> >
>>> > However, I wonder what your goal is? You want to be able to create a
>>> > Bamboo board with e.g. a 750 processor? I don't think that would help
>>> > the original poster, and I'm not sure how useful it is, but I don't
>>> > object...
>>> >
>>> > Either way I guess it will become a non-issue once PowerPC boards are
>>> > converted to the device tree infrastructure.
>>> >
>>> > -Hollis
>>> >
>>> > On Sun, Jun 14, 2009 at 1:33 PM, Blue Swirl<blauwirbel@gmail.com> wrote:
>>> >> Sorry, I was very confused (I didn't look at ppc440.c).
>>> >>
>>> >> For some reason, CPU model can't be specified on the command line. The
>>> >> patch allows this, does it look OK?
>>> >>
>>> >> Is there a kernel and initrd somewhere, so I could test this?
>>> >>
>>> >> Currently I get (no kernel or ROM, so nothing to execute):
>>> >> Truncating memory to 128 MiB to fit SDRAM controller limits.
>>> >> ppc405_serial_init: offset 0000000000000300
>>> >> QEMU 0.10.50 monitor - type 'help' for more information
>>> >> (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at
>>> >> 0x00000000fffffffc
>>> >>
>>> >> NIP 00000000fffffffc LR 0000000000000000 CTR 0000000000000000 XER
>>> >> 00000000
>>> >> MSR 0000000000000000 HID0 0000000000000300 HF 0000000000000000 idx 1
>>> >> Segmentation fault
>>> >>
>>> >> On 6/14/09, Hollis Blanchard <hollis@penguinppc.org> wrote:
>>> >>> Yes, I wrote the code you quoted.
>>> >>>
>>> >>> In case there is any confusion, let me restate: You can boot a Bamboo
>>> >>> (PowerPC 440) guest under KVM on a PowerPC 440 host. KVM bypasses
>>> >>> qemu's CPU emulation (TCG), but uses qemu's device emulation.
>>> >>> Therefore, if someone were to implement 440 core emulation in qemu,
>>> >>> you could boot a 440 kernel with qemu without KVM.
>>> >>>
>>> >>> Most devices found on 440 SoCs are the same as or very similar to the
>>> >>> devices found on 405 SoCs. Qemu's 440 device emulation isn't perfect,
>>> >>> but because Linux is highly modular, with a modified device tree you
>>> >>> can boot it. See pc-bios/bamboo.dts.
>>> >>>
>>> >>> -Hollis
>>> >>>
>>> >>> On Sat, Jun 13, 2009 at 10:47 PM, Baojun Wang <wangbj@gmail.com>
>>> >>> wrote:
>>> >>> >
>>> >>> > in hw/ppc440.c:
>>> >>> >
>>> >>> > env = cpu_ppc_init("440EP");
>>> >>> > if (!env && kvm_enabled()) {
>>> >>> > /* XXX Since qemu doesn't yet emulate 440, we just say it's
>>> >>> a 405.
>>> >>> > * Since KVM doesn't use qemu's CPU emulation it seems to be
>>> >>> working
>>> >>> > * OK. */
>>> >>> > env = cpu_ppc_init("405");
>>> >>> > }
>>> >>> > if (!env) {
>>> >>> > fprintf(stderr, "Unable to initialize CPU!\n");
>>> >>> > exit(1);
>>> >>> > }
>>> >>> >
>>> >>> > also in hw/ppc.c:
>>> >>> >
>>> >>> > I can find ppc40x_irq_init/e500_irq_init(used mpc8544ds), but there
>>> >>> is
>>> >>> > no ppcbooke_irq_init? It seems hw/ppc405_uc.c is emulation for
>>> >>> DCRs,
>>> >>> > PLB, DMA, GPIO, I2C.., but there is no hw/ppc44x_uc.c.
>>> >>> >
>>> >>> > the qemu source I used is 0.10.5.
>>> >>> >
>>> >>> > Also in ppc/translate_init.c, there lots of CONFIG_USER_ONLY, but I
>>> >>> > many of them are DEBUG or CACHE related SPR emulation, and since
>>> >>> qemu
>>> >>> > doesn't emulate cache, I think it's OK.
>>> >>> >
>>> >>> > Thanks,
>>> >>> > Wang
>>> >>> >
>>> >>> > On Sun, Jun 14, 2009 at 1:47 AM, Hollis
>>> >>> Blanchard<hollis@penguinppc.org> wrote:
>>> >>> > > On Fri, Jun 12, 2009 at 10:48 AM, Blue Swirl
>>> >>> <blauwirbel@gmail.com> wrote:
>>> >>> > >>
>>> >>> > >> On 6/11/09, Baojun Wang <wangbj@gmail.com> wrote:
>>> >>> > >> > could qemu emulate some board like bamboo (without kvm) or
>>> >>> MPC8544ds
>>> >>> > >> > now? Thanks
>>> >>> > >>
>>> >>> > >> Yes, if someone adds emulation for these devices: UIC, PLB, DMA,
>>> >>> POB,
>>> >>> > >> EBC, IIC, ZMII. Maybe some are not needed in all cases.
>>> >>> > >
>>> >>> > > No, qemu still doesn't emulate Book E cores, such as the PowerPC
>>> >>> 440 in a
>>> >>> > > Bamboo board.
>>> >>> > >
>>> >>> > > UIC is of course emulated, otherwise KVM guests on 440 wouldn't
>>> >>> get very
>>> >>> > > far. :) Enough 440 SoC devices are emulated to support Linux boot
>>> >>> with a
>>> >>> > > properly stripped device tree.
>>> >>> > >
>>> >>> > > -Hollis
>>> >>> > >
>>> >>>
>>> >>
>>> >
>>
>>
>
next prev parent reply other threads:[~2009-06-16 15:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-14 17:28 [Qemu-devel] PowerPC 440 support Hollis Blanchard
2009-06-14 18:33 ` Blue Swirl
2009-06-14 19:46 ` Hollis Blanchard
2009-06-14 20:40 ` Blue Swirl
2009-06-15 4:40 ` Baojun Wang
2009-06-15 15:46 ` Hollis Blanchard
2009-06-15 16:52 ` Blue Swirl
2009-06-15 17:37 ` Hollis Blanchard
2009-06-16 15:12 ` Baojun Wang
2009-06-16 15:36 ` Hollis Blanchard [this message]
2009-06-15 4:37 ` Baojun Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb412d760906160836l73dea987hc2416d62f733f905@mail.gmail.com \
--to=hollis@penguinppc.org \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=wangbj@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.