From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGai1-0002cE-3o for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:36:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGai0-0002bN-IL for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:36:24 -0400 Received: from [199.232.76.173] (port=34803 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGai0-0002b3-3m for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:36:24 -0400 Received: from yw-out-1718.google.com ([74.125.46.154]:42152) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGahz-0002eA-Ub for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:36:24 -0400 Received: by yw-out-1718.google.com with SMTP id 5so2676089ywr.82 for ; Tue, 16 Jun 2009 08:36:22 -0700 (PDT) MIME-Version: 1.0 Sender: slightlyunconventional@gmail.com In-Reply-To: <3cdfa5bc0906160812y2dc670dfqb61015a0373c72f4@mail.gmail.com> References: <3cdfa5bc0906142140nf2a78rf2a07c3185a9614d@mail.gmail.com> <3cdfa5bc0906160812y2dc670dfqb61015a0373c72f4@mail.gmail.com> Date: Tue, 16 Jun 2009 10:36:17 -0500 Message-ID: Subject: Re: [Qemu-devel] PowerPC 440 support From: Hollis Blanchard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Baojun Wang Cc: Blue Swirl , "Richard W.M. Jones" , qemu-devel@nongnu.org On Tue, Jun 16, 2009 at 10:12 AM, Baojun Wang 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=3D-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=3Ddtc.git;a=3Dsummary) and install libfdt by hand from there. -Hollis > =A0Regard & Thanks, > Wang > > On Mon, Jun 15, 2009 at 11:46 PM, Hollis Blanchard= wrote: >> KVM PPC execution doesn't use firmware today. Instead we create the devi= ce >> tree in qemu itself, stuff it into guest memory, and point a guest regis= ter >> at it on entry. This was just a shortcut/hack, because we didn't have en= ough >> 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 devic= e >> emulation, and also we'll probably need to work out a way for qemu to pa= ss >> parameters (e.g. memory size) to u-boot. IMHO, the best approach there w= ould >> 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 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.. >>> >>> =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 wro= te: >>> >> 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. T= he >>> >> 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 =A0 LR 0000000000000000 CTR 0000000000000000 XE= R >>> >> 00000000 >>> >> MSR 0000000000000000 HID0 0000000000000300 =A0HF 0000000000000000 id= x 1 >>> >> Segmentation fault >>> >> >>> >> On 6/14/09, Hollis Blanchard wrote: >>> >>> Yes, I wrote the code you quoted. >>> >>> >>> >>> =A0In case there is any confusion, let me restate: You can boot a B= amboo >>> >>> =A0(PowerPC 440) guest under KVM on a PowerPC 440 host. KVM bypasse= s >>> >>> =A0qemu's CPU emulation (TCG), but uses qemu's device emulation. >>> >>> =A0Therefore, if someone were to implement 440 core emulation in qe= mu, >>> >>> =A0you could boot a 440 kernel with qemu without KVM. >>> >>> >>> >>> =A0Most devices found on 440 SoCs are the same as or very similar t= o the >>> >>> =A0devices found on 405 SoCs. Qemu's 440 device emulation isn't per= fect, >>> >>> =A0but because Linux is highly modular, with a modified device tree= you >>> >>> =A0can boot it. See pc-bios/bamboo.dts. >>> >>> >>> >>> =A0-Hollis >>> >>> >>> >>> =A0On Sat, Jun 13, 2009 at 10:47 PM, Baojun Wang >>> >>> wrote: >>> >>> =A0> >>> >>> =A0> in hw/ppc440.c: >>> >>> =A0> >>> >>> =A0> =A0 =A0env =3D cpu_ppc_init("440EP"); >>> >>> =A0> =A0 =A0if (!env && kvm_enabled()) { >>> >>> =A0> =A0 =A0 =A0 =A0/* XXX Since qemu doesn't yet emulate 440, we j= ust say it's >>> >>> a 405. >>> >>> =A0> =A0 =A0 =A0 =A0 * Since KVM doesn't use qemu's CPU emulation i= t seems to be >>> >>> working >>> >>> =A0> =A0 =A0 =A0 =A0 * OK. */ >>> >>> =A0> =A0 =A0 =A0 =A0env =3D cpu_ppc_init("405"); >>> >>> =A0> =A0 =A0} >>> >>> =A0> =A0 =A0if (!env) { >>> >>> =A0> =A0 =A0 =A0 =A0fprintf(stderr, "Unable to initialize CPU!\n"); >>> >>> =A0> =A0 =A0 =A0 =A0exit(1); >>> >>> =A0> =A0 =A0} >>> >>> =A0> >>> >>> =A0> also in hw/ppc.c: >>> >>> =A0> >>> >>> =A0> I can find ppc40x_irq_init/e500_irq_init(used mpc8544ds), but = there >>> >>> is >>> >>> =A0> no ppcbooke_irq_init? It seems hw/ppc405_uc.c is emulation for >>> >>> DCRs, >>> >>> =A0> PLB, DMA, GPIO, I2C.., but there is no hw/ppc44x_uc.c. >>> >>> =A0> >>> >>> =A0> the qemu source I used is 0.10.5. >>> >>> =A0> >>> >>> =A0> Also in ppc/translate_init.c, there lots of CONFIG_USER_ONLY, = but I >>> >>> =A0> many of them are DEBUG or CACHE related SPR emulation, and sin= ce >>> >>> qemu >>> >>> =A0> doesn't emulate cache, I think it's OK. >>> >>> =A0> >>> >>> =A0> =A0Thanks, >>> >>> =A0> Wang >>> >>> =A0> >>> >>> =A0> On Sun, Jun 14, 2009 at 1:47 AM, Hollis >>> >>> Blanchard wrote: >>> >>> =A0> > On Fri, Jun 12, 2009 at 10:48 AM, Blue Swirl >>> >>> wrote: >>> >>> =A0> >> >>> >>> =A0> >> On 6/11/09, Baojun Wang wrote: >>> >>> =A0> >> > could qemu emulate some board like bamboo (without kvm) o= r >>> >>> MPC8544ds >>> >>> =A0> >> > now? Thanks >>> >>> =A0> >> >>> >>> =A0> >> Yes, if someone adds emulation for these devices: UIC, PLB,= DMA, >>> >>> POB, >>> >>> =A0> >> EBC, IIC, ZMII. Maybe some are not needed in all cases. >>> >>> =A0> > >>> >>> =A0> > No, qemu still doesn't emulate Book E cores, such as the Pow= erPC >>> >>> 440 in a >>> >>> =A0> > Bamboo board. >>> >>> =A0> > >>> >>> =A0> > UIC is of course emulated, otherwise KVM guests on 440 would= n't >>> >>> get very >>> >>> =A0> > far. :) Enough 440 SoC devices are emulated to support Linux= boot >>> >>> with a >>> >>> =A0> > properly stripped device tree. >>> >>> =A0> > >>> >>> =A0> > -Hollis >>> >>> =A0> > >>> >>> >>> >> >>> > >> >> >