[Qemu-devel] MIPS kernel hanging when loaded through U-Boot in qemu

[Thomas Petazzoni <thomas.petazzoni@enix.org>]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

Hi,

I'm trying to get a MIPS kernel to boot in qemu-system-mips when loaded
through U-Boot, but the kernel boot hangs at random locations. Let me
explain the whole thing. I'm running Qemu SVN-5089.

First, I have a 2.6.24.7 kernel configured for the "qemu" machine of
the MIPS architecture. The config file is available at
 http://toulibre.org/~thomas/qemu/config-2.6.24.7

When I boot this kernel using the -kernel option, it works perfectly,
as can be seen in
 http://toulibre.org/~thomas/qemu/qemu-log-kernel

(well it hangs because it cannot find a root filesystem, but this is
expected)

The ELF binary of this kenel is available at
 http://toulibre.org/~thomas/qemu/vmlinux

Now, to the problem. I compile U-Boot 1.3.4 for the qemu-mips machine,
and boot into it using
~/local/qemu/mips-softmmu/qemu-system-mips -M mips -pflash u-boot.bin
-net nic -net tap -serial stdio

U-Boot boots correctly, I can download the kernel using TFTP, flash it,
and boot it. I use the exact same kernel, except that I use the
binary-only arch/mips/boot/vmlinux.bin instead of the ELF file. Of
course the vmlinux.bin has been prepared using mkimage before being
downloaded by U-Boot. When I boot this kernel in U-Boot using the
'bootm' command, it starts, but then hangs:
 http://toulibre.org/~thomas/qemu/qemu-log-kernel-from-uboot

It always hangs around the same place, but not exactly. Sometimes after
"PID hash table entries", sometimes after "Console: colour dummy
devices", sometimes one or two messages later, or before.

Using the qemu monitor, I can see where the kernel hanged:
 http://toulibre.org/~thomas/qemu/qemu-monitor-showing-hang-location.png

It hanged at 0x80000180, which if I remember correctly my old MIPS
knowledge, is an exception vector location. And the address that
trigerred this exception is 0x80018904, which according to an objdump
of the kernel, is located in handle_sys().

Then, when I use gdbserver, put a breakpoint in handle_sys() to get a
backtrace, the backtrace is different at each boot. Two examples of
backtraces:
 http://toulibre.org/~thomas/qemu/qemu-backtrace-1
 http://toulibre.org/~thomas/qemu/qemu-backtrace-2

Seing handle_sys() being called at that point of the kernel
initialization looks strange to me, as userspace isn't running yet.

For those who want to test, the u-boot.bin image which is the flash
image containing both U-Boot and the kernel can be downloaded from:
 http://toulibre.org/~thomas/qemu/u-boot.bin

Just let U-Boot boot, the default command does the right thing.

Do you have any idea on what's going on ?

Thanks,

Thomas
-- 
Thomas Petazzoni, thomas.petazzoni@enix.org, http://thomas.enix.org
Jabber, thomas.petazzoni@jabber.dk
Toulibre, http://www.toulibre.org - APRIL, http://www.april.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]