On Tue, 28 Jan 2003, Ralf Baechle wrote: > Hmm... If you can't reproduce this anymore I guess we should pull this > patch again? Despite Mike basically acknowledging that such behaviour > exists I don't feel to well about applying patches for non-reproducable > processor behaviour and would rather prefer to wait until we believe to > know the full details. Agreed, and I believe a run-time check would be better (and trivial as well). The (!MIPS32 && !MIPS64) approximation is too rough. > > I think you can remove the unconditional jumps, cfr. Mike's comments. > > That's one of the points where I felt a bit unsafe about the extend of > the issue so I left the jumps in. Anyway, why should it make a difference > if an instruction is conditional or not? I think jumps cannot be non-taken... > > Isn't the Vr4120A core MIPS32? > > Vr4120 is MIPS III. Actually I have a datasheet for the Vr4121 (which is a Vr4120 plus some glue logic for specific peripherals) and it explicitly states whenever cp0.EPC points to a preceding branch/jump of a faulting instruction, the cp0.Cause.BD bit is set. Maybe there is an errata sheet available. Additionally the processor is "nice" enough to implement the MIPS III ISA (with the MIPS16 extension) except ll/sc, lld/scd, sigh... So the emulation would need to be ported to the 64-bit kernel if we were to support this processor in the 64-bit mode. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
