* [Qemu-devel] questions about qemu fdt & 440EP softmmu
@ 2009-07-13 13:18 Baojun Wang
2009-07-13 15:49 ` [Qemu-devel] " Hollis Blanchard
0 siblings, 1 reply; 2+ messages in thread
From: Baojun Wang @ 2009-07-13 13:18 UTC (permalink / raw)
To: qemu-devel; +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 <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/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 "<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
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Qemu-devel] Re: questions about qemu fdt & 440EP softmmu
2009-07-13 13:18 [Qemu-devel] questions about qemu fdt & 440EP softmmu Baojun Wang
@ 2009-07-13 15:49 ` Hollis Blanchard
0 siblings, 0 replies; 2+ messages in thread
From: Hollis Blanchard @ 2009-07-13 15:49 UTC (permalink / raw)
To: Baojun Wang; +Cc: Blue Swirl, qemu-devel
On Mon, Jul 13, 2009 at 6:18 AM, Baojun Wang<wangbj@gmail.com> 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/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 <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/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 "<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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-07-13 15:50 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-13 13:18 [Qemu-devel] questions about qemu fdt & 440EP softmmu Baojun Wang
2009-07-13 15:49 ` [Qemu-devel] " Hollis Blanchard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).