From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQNmz-0003Xn-MA for qemu-devel@nongnu.org; Mon, 13 Jul 2009 11:50:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQNmy-0003Wc-0d for qemu-devel@nongnu.org; Mon, 13 Jul 2009 11:50:00 -0400 Received: from [199.232.76.173] (port=46217 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQNmx-0003WH-QI for qemu-devel@nongnu.org; Mon, 13 Jul 2009 11:49:59 -0400 Received: from qw-out-1920.google.com ([74.125.92.150]:37288) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MQNmt-0004i5-Fq for qemu-devel@nongnu.org; Mon, 13 Jul 2009 11:49:55 -0400 Received: by qw-out-1920.google.com with SMTP id 5so711925qwc.4 for ; Mon, 13 Jul 2009 08:49:54 -0700 (PDT) MIME-Version: 1.0 Sender: slightlyunconventional@gmail.com In-Reply-To: <3cdfa5bc0907130618g5250be31se8e0be24c3b8964b@mail.gmail.com> References: <3cdfa5bc0907130618g5250be31se8e0be24c3b8964b@mail.gmail.com> Date: Mon, 13 Jul 2009 08:49:54 -0700 Message-ID: From: Hollis Blanchard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: questions about qemu fdt & 440EP softmmu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Baojun Wang Cc: Blue Swirl , qemu-devel@nongnu.org On Mon, Jul 13, 2009 at 6:18 AM, Baojun Wang wrote: > hi, list > > =A0I'm getting a little bit confused about the fdt support in qemu, I > see that qemu have tried to build a dtb for a specific board (bamboo, > for example), later when qemu is trying to load a kernel, it will try > to find & load bamboo.dtb; my question is the newer kernel also have > fdt support, a new kernel will build a image like cuImage.bamboo, > which is embedded with a dtb, so when we use qemu (with fdt) to load > cuImage.bamboo, actually we have two dtb, what happen if the two dtb > doesn't match? Don't use cuImage if your bootloader (qemu in our case) is passing in a device tree; use a uImage instead. The "c" in "cuImage" means "compatible": it's meant to allow using older fdt-ignorant bootloaders. ... > the above code is copied from qemu, it try to patch the dtb > ``/chosen'' section to pass the kernel command lines, but does > function lilke ``qemu_devtree_setprop_string'' expand the dtb size > dynamically? otherwise we will still unable to pass kernel cmd line in > such a way. Yes, it does. To confirm it, you can trace the code into libfdt (which is open source). > currently I'm using the following command: > > qemu-system-ppcemb -M bamboo -cpu 440EP -kernel > ~/linux/linux-2.6.30.1/arch/powerpc/boot/cuImage.bamboo -m 32 > -nographic -serial stdio > > to load a linux kernel, is it the right way to load a kernel with fdt > enabled qemu? Except you should use uImage instead of cuImage.bamboo, that seems fine. > Another question, acording to booting-without-of.txt, when the > bootloader (well, not bootloader for qemu at this moment) launching > the kernel, the register should be > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0r3 : physical pointer to the device-tree b= lock > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(defined in chapter II) in RAM > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0r4 : physical pointer to the kernel itself= . This is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0used by the assembly code to properly disa= ble the MMU > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in case you are entering the kernel with M= MU enabled > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and a non-1:1 mapping. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0r5 : NULL (as to differentiate with method= a) > > so we should pass the address of dtb to r3? It seems the kernel code > still expect r3 is a pointer to bd_t.. we can see this code in the > latest kernel (2.6.30.1): You can see that qemu already sets the initial guest register state properl= y. > static bd_t bd; > > void platform_init(unsigned long r3, unsigned long r4, unsigned long r5, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long r6, unsigned long r7) > { > =A0 =A0 =A0 =A0CUBOOT_INIT(); > =A0 =A0 =A0 =A0bamboo_init(&bd.bi_enetaddr, &bd.bi_enet1addr); > } > > in the following log, we can see MAC of eth0 is set to > 00:00:0a:00:00:00, and eth1 is set to =A063:63:2c:62:61:6d, the later > actual is ``cc,bam'', which is actually in the dtb! (part of amcc, > bamboo I guess), so what should be passed in r3? Perhaps it's the cuImage attempting to read an old bd_t structure from the FDT pointer we passed it. > P.S: I'm trying to enable 440EP softmmu emulation (bamboo) recently, I > have made some changes to the qemu code so that qemu could run 440EP > bamboo with softmmu a little bit, here is the log (three some erros in > the code, and emulation is not competed yet): > > =A0$ ./ppcemb-softmmu/qemu-system-ppcemb -M bamboo -cpu 440EP -kernel > ~/linux/linux-2.6.30.1/arch/powerpc/boot/cuImage.bamboo -m 32 > -nographic -serial stdio > Truncating memory to 32 MiB to fit SDRAM controller limits. > ppc405_serial_init: offset 0000000000000300 > sysclk: 33333333, vco: 799999992, cpu: 399999996, per: 133333332, plb: > 266666664, opb: 133333332, pci: 66666666, uart: 7017543, i2c: 0 > fdt_size: 6358, my guess size: 6358 > CPU clock-frequency <- 0xbebc1fe (200MHz) > CPU timebase-frequency <- 0xbebc1fe (200MHz) > /plb: clock-frequency <- 7f28154 (133MHz) > /plb/opb: clock-frequency <- 3f940aa (67MHz) > /plb/opb/ebc: clock-frequency <- 1fca055 (33MHz) > /plb/opb/serial@ef600300: clock-frequency <- 358a23 (4MHz) > /plb/opb/serial@ef600400: clock-frequency <- 7f281 (1MHz) > /plb/opb/serial@ef600500: clock-frequency <- 7f281 (1MHz) > /plb/opb/serial@ef600600: clock-frequency <- 7f281 (1MHz) > Memory <- <0x0 0x0 0x1fff000> (31MB) > ethernet0: local-mac-address <- 00:00:0a:c0:00:00 > ethernet1: local-mac-address <- 63:63:2c:62:61:6d > > zImage starting: loaded at 0x00400000 (sp: 0x00ffffb8) > Allocating 0x2fe294 bytes for kernel ... > gunzipping (0x00000000 <- 0x0040e000:0x0070d3ac)...done 0x2e81e8 bytes > > Linux/PowerPC load: > Finalizing device tree... flat tree at 0x71a300 > Using PowerPC 44x Platform machine description > Linux version 2.6.30.1 (baojunwa@localhost) (gcc version 4.3.2 (Gentoo > 4.3.2-r3 p1.6, pie-10.1.5) ) #24 Sun Jul 12 17:09:14 CST 2009 > console [udbg0] enabled > setup_arch: bootmem > arch: exit > Zone PFN ranges: > =A0DMA =A0 =A0 =A00x00000000 -> 0x00001fff > =A0Normal =A0 0x00001fff -> 0x00001fff > Movable zone start PFN for each node > early_node_map[1] active PFN ranges > =A0 =A00: 0x00000000 -> 0x00001fff > MMU: Allocated 1088 bytes of context maps for 255 contexts > Built 1 zonelists in Zone order, mobility grouping on. =A0Total pages: 81= 27 > Kernel command line: > Experimental hierarchical RCU implementation. > Experimental hierarchical RCU init done. > NR_IRQS:512 > UIC0 (32 IRQ sources) at DCR 0xc0 > UIC1 (32 IRQ sources) at DCR 0xd0 > PID hash table entries: 128 (order: 7, 512 bytes) > clocksource: timebase mult[1400000] shift[22] registered > Console: colour dummy device 80x25 > Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) > Memory: 29364k/32764k available (2808k kernel code, 3400k reserved, > 140k data, 84k bss, 124k init) > Kernel virtual memory layout: > =A0* 0xffffe000..0xfffff000 =A0: fixmap > =A0* 0xfde00000..0xfe000000 =A0: consistent mem > =A0* 0xfddfe000..0xfde00000 =A0: early ioremap > =A0* 0xd1000000..0xfddfe000 =A0: vmalloc & ioremap > SLUB: Genslabs=3D11, HWalign=3D32, Order=3D0-3, MinObjects=3D0, CPUs=3D1,= Nodes=3D1 > Calibrating delay loop... 392.19 BogoMIPS (lpj=3D784384) > Mount-cache hash table entries: 512 > net_namespace: 296 bytes > NET: Registered protocol family 16 > > PCI host bridge /plb/pci@ec000000 (primary) ranges: > =A0MEM 0x00000000a0000000..0x00000000dfffffff -> 0x00000000a0000000 > =A0MEM 0x00000000e0000000..0x00000000e00fffff -> 0x0000000000000000 > =A0IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000 > =A0Removing ISA hole at 0x00000000e0000000 > 4xx PCI DMA offset set to 0x00000000 > /plb/pci@ec000000: Resource out of range > /plb/pci@ec000000: Legacy ISA memory support enabled > PCI: Probing PCI hardware > PCI: Hiding 4xx host bridge resources 0000:00:00.0 > bio: create slab at 0 > NET: Registered protocol family 2 > IP route cache hash table entries: 1024 (order: 0, 4096 bytes) > TCP established hash table entries: 1024 (order: 1, 8192 bytes) > TCP bind hash table entries: 1024 (order: 0, 4096 bytes) > TCP: Hash tables configured (established 1024 bind 1024) > TCP reno registered > NET: Registered protocol family 1 > msgmni has been set to 57 > io scheduler noop registered > io scheduler anticipatory registered (default) > io scheduler deadline registered > io scheduler cfq registered > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > serial8250.0: ttyS0 at MMIO 0xef600300 (irq =3D 16) is a 16550A > console handover: boot [udbg0] -> real [ttyS0] > ef600300.serial: ttyS0 at MMIO 0xef600300 (irq =3D 16) is a 16550A > brd: module loaded > Intel(R) PRO/1000 Network Driver - version 7.3.21-k3-NAPI > Copyright (c) 1999-2006 Intel Corporation. > e1000: 0000:00:01.0: e1000_probe: (PCI:33MHz:32-bit) 52:54:00:12:34:56 > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > PPC 4xx OCP EMAC driver, version 3.54 > MAL v1 /plb/mcmal, 4 TX channels, 2 RX channels > ZMII /plb/opb/emac-zmii@ef600d00 initialized > /plb/opb/emac-zmii@ef600d00: bridge in RMII mode > invalid SDR0 DCR: 0xf > /plb/opb/ethernet@ef600e00: can't find PHY! > invalid SDR0 DCR: 0xf > /plb/opb/ethernet@ef600f00: can't find PHY! > mice: PS/2 mouse device common for all mice > TCP cubic registered > NET: Registered protocol family 17 > RPC: Registered udp transport module. > RPC: Registered tcp transport module. > Root-NFS: No NFS server available, giving up. > VFS: Unable to mount root fs via NFS, trying floppy. > VFS: Cannot open root device "" or unknown-block(2,0) > Please append a correct "root=3D" boot option; here are the available par= titions: > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block= (2,0) > Call Trace: > [c1821ee0] [c0005f94] show_stack+0x48/0x15c (unreliable) > [c1821f10] [c02219e0] panic+0x8c/0x16c > [c1821f60] [c029fcfc] mount_block_root+0x198/0x240 > [c1821fb0] [c029ffb4] prepare_namespace+0xf8/0x1cc > [c1821fd0] [c029f1f0] kernel_init+0xd0/0xfc > [c1821ff0] [c000dc10] kernel_thread+0x50/0x6c > Rebooting in 180 seconds.. Looks good! Note that this particular error seems to be a root filesystem issue, not directly related to the MMU (the MMU is used very little during kernel boot). Once you fix the fdt issue, I imagine you'll start really exercising the MMU code when you hit userspace. -Hollis