[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] MIPS kernel hanging when loaded through U-Boot in qemu
From: |
Thomas Petazzoni |
Subject: |
Re: [Qemu-devel] MIPS kernel hanging when loaded through U-Boot in qemu |
Date: |
Wed, 3 Sep 2008 14:03:37 +0200 |
Le Wed, 3 Sep 2008 12:54:47 +0200,
Thiemo Seufer <address@hidden> a écrit :
> 'Interrupt' at this point should be the normal timer interrupt,
> "syscall" are the execve() calls which start kernel threads. On
> classic mips, both types of exceptions use the general exception
> vector at 0x80000180.
What's strange about these "syscall" interrupts is that we don't see
them in the kernel-only boot
(http://toulibre.org/~thomas/qemu/qemu-interrupt-log-kernel-only).
Are you sure that the syscall interrupt is used to run do_fork() inside
the kernel ? I'm not so sure.
> The difference here is that the timer interrupt goes to 0x80000200,
> this is controlled by the IV bit in the Cause register. This feature
> isn't available on all CPUs. In the kernel the relevant check to test
> for it is cpu_has_divec. I figure U-Boot and the Kernel disagree
> on the setting.
Hehe, it seems that you're correct.
In U-Boot board/qemu-mips/lowlevel_init.S, we have:
/*
* Step 7) Establish Cause
* (set IV bit)
*/
li t1, 0x00800000
mtc0 t1, CP0_CAUSE
In the kernel include/asm-mips/mach-qemu/cpu-feature-overrides.h, we
have:
#define cpu_has_divec 0
> Qemu always allows to set this Cause bit, independent of the CPU type.
> So I figure we have two bugs:
> - The kernel should try to clear the IV bit if it doesn't intend to
> use it
> - Qemu should ignore attempts to set the IV bit when emulating CPUs
> without divec.
Probably :-)
Thomas
--
Thomas Petazzoni, address@hidden, http://thomas.enix.org
Jabber, address@hidden
Toulibre, http://www.toulibre.org - APRIL, http://www.april.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7
signature.asc
Description: PGP signature