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.
/* Memory sub-system initialization code */
* 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
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.
/* Clear watch registers.
mtc0 zero, CP0_WATCHLO
mtc0 zero, CP0_WATCHHI
/* WP(Watch Pending), SW0/1 should be cleared. */
mtc0 zero, CP0_CAUSE
/* Init Timer */
mtc0 zero, CP0_COUNT
mtc0 zero, CP0_COMPARE
So this issue only happens on U-Boot/MIPS `qemu-mips' target, I think.