[PATCH 1/1] mips: clear IV bit in CP0 cause if the CPU doesn't support divec

[PATCH 1/1] mips: clear IV bit in CP0 cause if the CPU doesn't support divec

[Thomas Petazzoni]

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@free-electrons.com>
Cc: Thiemo Seufer <ths@networkno.de>
Cc: linux-mips@linux-mips.org
---
 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:
-- 
1.5.4.3

Re: [PATCH 1/1] mips: clear IV bit in CP0 cause if the CPU doesn't support divec

[Thomas Bogendoerfer]

On Tue, Sep 09, 2008 at 10:15:25AM +0200, Thomas Petazzoni wrote:
> +	else {
> +		clear_c0_cause(CAUSEF_IV);
> +	}

so we now touch a bit, which is at least marked reserved for R10k CPUs
and hope nobody did something else with it ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH 1/1] mips: clear IV bit in CP0 cause if the CPU doesn't support divec

[Kevin D. Kissell]

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@free-electrons.com>
> Cc: Thiemo Seufer <ths@networkno.de>
> Cc: linux-mips@linux-mips.org
> ---
>  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:
>   

Re: [PATCH 1/1] mips: clear IV bit in CP0 cause if the CPU doesn't support divec

[Ralf Baechle]

On Wed, Sep 10, 2008 at 01:11:45PM +0200, Kevin D. Kissell wrote:

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

What happened is this:

        if (cpu_has_divec) {
                if (cpu_has_mipsmt) {
                        unsigned int vpflags = dvpe();
                        set_c0_cause(CAUSEF_IV);
			evpe(vpflags);
		} else
                        set_c0_cause(CAUSEF_IV);
	}

but include/asm-mips/mach-qemu/cpu-feature-overrides.h was defining
cpu_has_divec as 0.  It should have been either undefined (for runtime
probing) or 1.  Iow, it was a platform specific bug.

With the large number of wild pre-MIPS32/64 architecture variants around I
feel a little uneasy to just zero the field unless I know that bit 23
really is the IV bit on a particular processor.  Just as an example, the
RM7000 has the IV bit on bit 24, not bit 23 like MIPS32 and the
functionality also differs a little.

  Ralf

Re: [PATCH 1/1] mips: clear IV bit in CP0 cause if the CPU doesn't support divec

[Shinya Kuribayashi]

Kevin D. Kissell wrote:
> 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.

It seems the culprit is U-Boot/MIPS `qemu-mips' target. It apparently
sets IV bit in its local initialization.

u-boot/board/qemu-mips/lowlevel_init.S
---------------------------------------
http://git.denx.de/?p=u-boot.git;a=blob;f=board/qemu-mips/lowlevel_init.S;hb=HEAD

/* Memory sub-system initialization code */

#include <config.h>
#include <asm/regdef.h>
#include <asm/mipsregs.h>

	.text
	.set noreorder
	.set mips32

	.globl	lowlevel_init
lowlevel_init:

	/*
	 * Step 2) Establish Status Register
	 * (set BEV, clear ERL, clear EXL, clear IE)
	 */
	li	t1, 0x00400000
	mtc0	t1, CP0_STATUS

	/*
	 * Step 3) Establish CP0 Config0
	 * (set K0=3)
	 */
	li	t1, 0x00000003
	mtc0	t1, CP0_CONFIG

	/*
	 * Step 7) Establish Cause
	 * (set IV bit)
	 */
	li	t1, 0x00800000
	mtc0	t1, CP0_CAUSE

	/* Establish Wired (and Random) */
	mtc0	zero, CP0_WIRED
	nop

	jr	ra
	nop

--->8--->8--->8--->8---


On the other hand, a normal U-Boot/MIPS startup routine doesn't set any
CP0.CAUSE bits; it just clears all bits right after system reset.

u-boot/cpu/mips/start.S
------------------------
http://git.denx.de/?p=u-boot.git;a=blob;f=cpu/mips/start.S;hb=HEAD

	(snipped)

	/* Clear watch registers.
	 */
	mtc0	zero, CP0_WATCHLO
	mtc0	zero, CP0_WATCHHI

	/* WP(Watch Pending), SW0/1 should be cleared. */
	mtc0	zero, CP0_CAUSE

	setup_c0_status_reset

	/* Init Timer */
	mtc0	zero, CP0_COUNT
	mtc0	zero, CP0_COMPARE

	(snipped)

So this issue only happens on U-Boot/MIPS `qemu-mips' target, I think.


  Shinya