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

[Hollis Blanchard]

On Mon, Jul 13, 2009 at 6:18 AM, Baojun Wang<address@hidden> wrote:
> 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?

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
>
>
>                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):

You can see that qemu already sets the initial guest register state properly.

> 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?

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):
>
>  $ ./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..

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