From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGaL4-0005bQ-Jg for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:12:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGaL0-0005Zz-R7 for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:12:42 -0400 Received: from [199.232.76.173] (port=38648 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGaL0-0005Zm-I1 for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:12:38 -0400 Received: from mail-px0-f181.google.com ([209.85.216.181]:54331) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGaL0-0000e5-DC for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:12:38 -0400 Received: by pxi11 with SMTP id 11so2815982pxi.4 for ; Tue, 16 Jun 2009 08:12:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <3cdfa5bc0906142140nf2a78rf2a07c3185a9614d@mail.gmail.com> Date: Tue, 16 Jun 2009 23:12:36 +0800 Message-ID: <3cdfa5bc0906160812y2dc670dfqb61015a0373c72f4@mail.gmail.com> Subject: Re: [Qemu-devel] PowerPC 440 support From: Baojun Wang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hollis Blanchard Cc: Blue Swirl , "Richard W.M. Jones" , qemu-devel@nongnu.org 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. 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=3D-lfdt' >> config-host.mak but that lead to compile error, seems device tree in qemu is not fully populated? Regard & Thanks, Wang On Mon, Jun 15, 2009 at 11:46 PM, Hollis Blanchard w= rote: > KVM PPC execution doesn't use firmware today. Instead we create the devic= e > tree in qemu itself, stuff it into guest memory, and point a guest regist= er > at it on entry. This was just a shortcut/hack, because we didn't have eno= ugh > 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 pas= s > parameters (e.g. memory size) to u-boot. IMHO, the best approach there wo= uld > be to have u-boot interpret a device tree from qemu, then modify it and p= ass > it on to the kernel. Obviously that will require u-boot work. > > -Hollis > > On Sun, Jun 14, 2009 at 11:40 PM, Baojun Wang 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.. >> >> =C2=A0Best Regards, >> Wang >> >> On Mon, Jun 15, 2009 at 3:46 AM, Hollis Blanchard >> 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 wrot= e: >> >> 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. Th= e >> >> 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 =C2=A0 LR 0000000000000000 CTR 0000000000000000 = XER >> >> 00000000 >> >> MSR 0000000000000000 HID0 0000000000000300 =C2=A0HF 0000000000000000 = idx 1 >> >> Segmentation fault >> >> >> >> On 6/14/09, Hollis Blanchard wrote: >> >>> Yes, I wrote the code you quoted. >> >>> >> >>> =C2=A0In case there is any confusion, let me restate: You can boot a= Bamboo >> >>> =C2=A0(PowerPC 440) guest under KVM on a PowerPC 440 host. KVM bypas= ses >> >>> =C2=A0qemu's CPU emulation (TCG), but uses qemu's device emulation. >> >>> =C2=A0Therefore, if someone were to implement 440 core emulation in = qemu, >> >>> =C2=A0you could boot a 440 kernel with qemu without KVM. >> >>> >> >>> =C2=A0Most devices found on 440 SoCs are the same as or very similar= to the >> >>> =C2=A0devices found on 405 SoCs. Qemu's 440 device emulation isn't p= erfect, >> >>> =C2=A0but because Linux is highly modular, with a modified device tr= ee you >> >>> =C2=A0can boot it. See pc-bios/bamboo.dts. >> >>> >> >>> =C2=A0-Hollis >> >>> >> >>> =C2=A0On Sat, Jun 13, 2009 at 10:47 PM, Baojun Wang >> >>> wrote: >> >>> =C2=A0> >> >>> =C2=A0> in hw/ppc440.c: >> >>> =C2=A0> >> >>> =C2=A0> =C2=A0 =C2=A0env =3D cpu_ppc_init("440EP"); >> >>> =C2=A0> =C2=A0 =C2=A0if (!env && kvm_enabled()) { >> >>> =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0/* XXX Since qemu doesn't yet emu= late 440, we just say it's >> >>> a 405. >> >>> =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Since KVM doesn't use qemu's C= PU emulation it seems to be >> >>> working >> >>> =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * OK. */ >> >>> =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0env =3D cpu_ppc_init("405"); >> >>> =C2=A0> =C2=A0 =C2=A0} >> >>> =C2=A0> =C2=A0 =C2=A0if (!env) { >> >>> =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0fprintf(stderr, "Unable to initia= lize CPU!\n"); >> >>> =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0exit(1); >> >>> =C2=A0> =C2=A0 =C2=A0} >> >>> =C2=A0> >> >>> =C2=A0> also in hw/ppc.c: >> >>> =C2=A0> >> >>> =C2=A0> I can find ppc40x_irq_init/e500_irq_init(used mpc8544ds), bu= t there >> >>> is >> >>> =C2=A0> no ppcbooke_irq_init? It seems hw/ppc405_uc.c is emulation f= or >> >>> DCRs, >> >>> =C2=A0> PLB, DMA, GPIO, I2C.., but there is no hw/ppc44x_uc.c. >> >>> =C2=A0> >> >>> =C2=A0> the qemu source I used is 0.10.5. >> >>> =C2=A0> >> >>> =C2=A0> Also in ppc/translate_init.c, there lots of CONFIG_USER_ONLY= , but I >> >>> =C2=A0> many of them are DEBUG or CACHE related SPR emulation, and s= ince >> >>> qemu >> >>> =C2=A0> doesn't emulate cache, I think it's OK. >> >>> =C2=A0> >> >>> =C2=A0> =C2=A0Thanks, >> >>> =C2=A0> Wang >> >>> =C2=A0> >> >>> =C2=A0> On Sun, Jun 14, 2009 at 1:47 AM, Hollis >> >>> Blanchard wrote: >> >>> =C2=A0> > On Fri, Jun 12, 2009 at 10:48 AM, Blue Swirl >> >>> wrote: >> >>> =C2=A0> >> >> >>> =C2=A0> >> On 6/11/09, Baojun Wang wrote: >> >>> =C2=A0> >> > could qemu emulate some board like bamboo (without kvm)= or >> >>> MPC8544ds >> >>> =C2=A0> >> > now? Thanks >> >>> =C2=A0> >> >> >>> =C2=A0> >> Yes, if someone adds emulation for these devices: UIC, PL= B, DMA, >> >>> POB, >> >>> =C2=A0> >> EBC, IIC, ZMII. Maybe some are not needed in all cases. >> >>> =C2=A0> > >> >>> =C2=A0> > No, qemu still doesn't emulate Book E cores, such as the P= owerPC >> >>> 440 in a >> >>> =C2=A0> > Bamboo board. >> >>> =C2=A0> > >> >>> =C2=A0> > UIC is of course emulated, otherwise KVM guests on 440 wou= ldn't >> >>> get very >> >>> =C2=A0> > far. :) Enough 440 SoC devices are emulated to support Lin= ux boot >> >>> with a >> >>> =C2=A0> > properly stripped device tree. >> >>> =C2=A0> > >> >>> =C2=A0> > -Hollis >> >>> =C2=A0> > >> >>> >> >> >> > > >