[Qemu-devel] questions about qemu fdt & 440EP softmmu

[Baojun Wang]

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/address@hidden: clock-frequency <- 358a23 (4MHz)
/plb/opb/address@hidden: clock-frequency <- 7f281 (1MHz)
/plb/opb/address@hidden: clock-frequency <- 7f281 (1MHz)
/plb/opb/address@hidden: 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 (address@hidden) (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/address@hidden (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/address@hidden: Resource out of range
/plb/address@hidden: Legacy ISA memory support enabled
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
bio: create slab <bio-0> 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/address@hidden initialized
/plb/opb/address@hidden: bridge in RMII mode
invalid SDR0 DCR: 0xf
/plb/opb/address@hidden: can't find PHY!
invalid SDR0 DCR: 0xf
/plb/opb/address@hidden: 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 "<NULL>" 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