Thiemo Seufer wrote:
Kevin D. Kissell wrote:
??? 2007-09-04?????? 12:03 +0200???Kevin D. Kissell?????????
The 4KEc is a MIPS32 Release 2 processor, for which the implementation
of the Cause.TI bit (bit 30) is required. You may have a defective board
or a bad FPGA bitfile. Please work with your support contacts at MIPS
to verify that this is not the case. It may also be that there's something more
subtle going on in the interrupt processing, such that the Cause.TI bit is being
cleared before it can be sampled by the code you've changed. But while the
patch below presumably solves the symptoms of your problem, I really
don't think that a kernel hack based on detecting CoreFPA3 is an appropriate
solution. I work every day with Malta/CoreFPGA3 bitfiles and have not
seen Cause.TI fail to function in any of the Release 2 core bitfiles I've used.
My board's core is Release 1 core. So Cause.TI bit always is zero. Maybe
I need update this patch to reflect this, i.e add #ifdef to distinguish
Release 1 and Release 2. Thanks.
In that case, your core is a 4Kc and not a 4KEc.
Not quite true, early revisions of the 4KEc were only release 1. This
seems to be a bug in arch/mips/cpu-probe.c:
static inline void cpu_probe_mips(struct cpuinfo_mips *c)
{
decode_configs(c);
switch (c->processor_id & 0xff00) {
case PRID_IMP_4KC:
c->cputype = CPU_4KC;
break;
case PRID_IMP_4KEC:
c->cputype = CPU_4KEC;
break;
case PRID_IMP_4KECR2:
c->cputype = CPU_4KEC;
break;
...
The type for PRID_IMP_4KEC should be CPU_4KC.
Maybe the probing code should read the ISA revision level from the AR
bits (12:10) of the Config0 register to figure out which revision of the
ISA is implemented.
Nigel
