From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQLQi-00088L-SX for qemu-devel@nongnu.org; Mon, 13 Jul 2009 09:18:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQLQe-00087i-EP for qemu-devel@nongnu.org; Mon, 13 Jul 2009 09:18:52 -0400 Received: from [199.232.76.173] (port=41901 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQLQe-00087e-3J for qemu-devel@nongnu.org; Mon, 13 Jul 2009 09:18:48 -0400 Received: from mail-px0-f201.google.com ([209.85.216.201]:57976) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MQLQd-0005ef-Gz for qemu-devel@nongnu.org; Mon, 13 Jul 2009 09:18:47 -0400 Received: by pxi39 with SMTP id 39so1593377pxi.4 for ; Mon, 13 Jul 2009 06:18:45 -0700 (PDT) MIME-Version: 1.0 Date: Mon, 13 Jul 2009 21:18:45 +0800 Message-ID: <3cdfa5bc0907130618g5250be31se8e0be24c3b8964b@mail.gmail.com> From: Baojun Wang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] questions about qemu fdt & 440EP softmmu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Hollis Blanchard , Blue Swirl hi, list I'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? static void *bamboo_load_device_tree(target_phys_addr_t addr, uint32_t ramsize, target_phys_addr_t initrd_base, target_phys_addr_t initrd_size, const char *kernel_cmdline) { void *fdt = NULL; #ifdef HAVE_FDT uint32_t mem_reg_property[] = { 0, 0, ramsize }; char *filename; int fdt_size; int ret; filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, BINARY_DEVICE_TREE_FILE); if (!filename) { goto out; } fdt = load_device_tree(filename, &fdt_size); qemu_free(filename); if (fdt == NULL) { goto out; } /* Manipulate device tree in memory. */ ret = qemu_devtree_setprop(fdt, "/memory", "reg", mem_reg_property, sizeof(mem_reg_property)); if (ret < 0) fprintf(stderr, "couldn't set /memory/reg\n"); ret = qemu_devtree_setprop_cell(fdt, "/chosen", "linux,initrd-start", initrd_base); if (ret < 0) fprintf(stderr, "couldn't set /chosen/linux,initrd-start\n"); ret = qemu_devtree_setprop_cell(fdt, "/chosen", "linux,initrd-end", (initrd_base + initrd_size)); if (ret < 0) fprintf(stderr, "couldn't set /chosen/linux,initrd-end\n"); ret = qemu_devtree_setprop_string(fdt, "/chosen", "bootargs", kernel_cmdline); if (ret != 0) fprintf(stderr, "couldn't set /chosen/bootargs\n"); if (kvm_enabled()) kvmppc_fdt_update(fdt); cpu_physical_memory_write (addr, (void *)fdt, fdt_size); out: #endif return fdt; } 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. 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? 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 r3 : physical pointer to the device-tree block (defined in chapter II) in RAM r4 : physical pointer to the kernel itself. This is used by the assembly code to properly disable the MMU in case you are entering the kernel with MMU enabled and a non-1:1 mapping. r5 : 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): static bd_t bd; void platform_init(unsigned long r3, unsigned long r4, unsigned long r5, unsigned long r6, unsigned long r7) { CUBOOT_INIT(); bamboo_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 63: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? 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): $ ./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: DMA 0x00000000 -> 0x00001fff Normal 0x00001fff -> 0x00001fff Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00001fff MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8127 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: * 0xffffe000..0xfffff000 : fixmap * 0xfde00000..0xfe000000 : consistent mem * 0xfddfe000..0xfde00000 : early ioremap * 0xd1000000..0xfddfe000 : vmalloc & ioremap SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 392.19 BogoMIPS (lpj=784384) Mount-cache hash table entries: 512 net_namespace: 296 bytes NET: Registered protocol family 16 PCI host bridge /plb/pci@ec000000 (primary) ranges: MEM 0x00000000a0000000..0x00000000dfffffff -> 0x00000000a0000000 MEM 0x00000000e0000000..0x00000000e00fffff -> 0x0000000000000000 IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000 Removing 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 = 16) is a 16550A console handover: boot [udbg0] -> real [ttyS0] ef600300.serial: ttyS0 at MMIO 0xef600300 (irq = 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=" boot option; here are the available partitions: 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.. Any help/info is greatly appreciated, thanks a lot. Best Regards, - Wang