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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).