I think it's important to know whether it's U-Boot or Linux that's confused.
As Thomas Bogendoerfer pointed out, it's not good practice to flip bits
whose
use is unknown to the kernel. If in fact the CPU in question does
support IV,
was correctly identified as such by U-Boot, but isn't recognized by the MIPS
Linux kernel, then we ought to fix Linux to recognize the CPU. If it
doesn't
support IV, but U-Boot thought it did, then U-Boot is broken and ought to
be fixed. If you you're stuck with a broken U-Boot for some reason, then
there ought to be some platform-specific place to put a hack.
Regards,
Kevin K.
Thomas Petazzoni wrote:
When the kernel thinks that the CPU doesn't support the divec feature
(cpu_has_divec is false), reset the corresponding IV bit in the CP0
cause register, so that things will work correctly if the bootloader
had a different idea of the CPU support of the divec feature.
The problem has been found while trying to boot a 2.6.24 kernel for
the Qemu board using U-Boot inside Qemu. For the same CPU type, U-Boot
thinks that divec is supported, and the kernel doesn't. So U-Boot sets
the IV bit, but when the kernel boots and doesn't reset the IV bit,
things break when the first interrupts occur. The Qemu board has been
removed from the kernel in 2.6.25, but the problem might also occur
with other platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
Cc: Thiemo Seufer <ths@xxxxxxxxxxxx>
Cc: linux-mips@xxxxxxxxxxxxxx
---
arch/mips/kernel/traps.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 6bee290..8b1e507 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1467,6 +1467,9 @@ void __cpuinit per_cpu_trap_init(void)
} else
set_c0_cause(CAUSEF_IV);
}
+ else {
+ clear_c0_cause(CAUSEF_IV);
+ }
/*
* Before R2 both interrupt numbers were fixed to 7, so on R2 only:
