fpu woes (TX3912)

fpu woes (TX3912)

[Ryan Martindale]

I'm using the tx3912 processor for an embedded device and since it
doesn't have an fpu, I don't have coprocessor #1.  Recently, I remember
seeing a fix in process.c for exit_thread and flush_thread, and did
apply it - but there still is a problem (at least for me). In traps.c,
the save_fp_context and restore_fp_context are set to _save_fp_context
(in r2300_fpu.S) which don't check to see if I have a coprocessor
available. As I am rather new to the linux/linux-mips development world,
I thought I'd give a heads up (it is causing my embedded system to
crash). Any direction on fixing it would be welcome, but I'm not sure
I'll get to the point where I will submit any patches any time soon.

Ryan Martindale
QSI Corporation

Re: fpu woes (TX3912)

[Kevin D. Kissell]

> I'm using the tx3912 processor for an embedded device and since it
> doesn't have an fpu, I don't have coprocessor #1.  Recently, I remember
> seeing a fix in process.c for exit_thread and flush_thread, and did
> apply it - but there still is a problem (at least for me). In traps.c,
> the save_fp_context and restore_fp_context are set to _save_fp_context
> (in r2300_fpu.S) which don't check to see if I have a coprocessor
> available. As I am rather new to the linux/linux-mips development world,
> I thought I'd give a heads up (it is causing my embedded system to
> crash). Any direction on fixing it would be welcome, but I'm not sure
> I'll get to the point where I will submit any patches any time soon.

People break things from time to time, but at least at one point
in history, R3xxx platforms were correctly supported by the
FPU emulator code.  Looking at the source code on my 
system, it looks like traps.c has been "cleaned up" in a
somewhat wierd manner, such that the test for whether
there is an FPU happens redundantly, once in the specific
case of a 4K family CPU (which you would not hit on your
TX39), and again just after the switch on the CPU type.
Did someone screw up the setting of mips_cpu.options
for a TX39xx or something?  Is that code missing from
the sources that you're using?  Are you sure that it isn't
something else blowing up on you?  There have been
mods made locally here and there that might have
broken the FPU emulator for R3xxx platforms, but
I didn't think that any of them were up on OSS.sgi.com
or kernel.org.

            Regards,

            Kevin K.

Re: fpu woes (TX3912)

[Kevin D. Kissell]

> I'm using the tx3912 processor for an embedded device and since it
> doesn't have an fpu, I don't have coprocessor #1.  Recently, I remember
> seeing a fix in process.c for exit_thread and flush_thread, and did
> apply it - but there still is a problem (at least for me). In traps.c,
> the save_fp_context and restore_fp_context are set to _save_fp_context
> (in r2300_fpu.S) which don't check to see if I have a coprocessor
> available. As I am rather new to the linux/linux-mips development world,
> I thought I'd give a heads up (it is causing my embedded system to
> crash). Any direction on fixing it would be welcome, but I'm not sure
> I'll get to the point where I will submit any patches any time soon.

People break things from time to time, but at least at one point
in history, R3xxx platforms were correctly supported by the
FPU emulator code.  Looking at the source code on my 
system, it looks like traps.c has been "cleaned up" in a
somewhat wierd manner, such that the test for whether
there is an FPU happens redundantly, once in the specific
case of a 4K family CPU (which you would not hit on your
TX39), and again just after the switch on the CPU type.
Did someone screw up the setting of mips_cpu.options
for a TX39xx or something?  Is that code missing from
the sources that you're using?  Are you sure that it isn't
something else blowing up on you?  There have been
mods made locally here and there that might have
broken the FPU emulator for R3xxx platforms, but
I didn't think that any of them were up on OSS.sgi.com
or kernel.org.

            Regards,

            Kevin K.

Re: fpu woes (TX3912)

[Ryan Martindale]

"Kevin D. Kissell" wrote:
> 
> > I'm using the tx3912 processor for an embedded device and since it
> > doesn't have an fpu, I don't have coprocessor #1.  Recently, I remember
> > seeing a fix in process.c for exit_thread and flush_thread, and did
> > apply it - but there still is a problem (at least for me). In traps.c,
> > the save_fp_context and restore_fp_context are set to _save_fp_context
> > (in r2300_fpu.S) which don't check to see if I have a coprocessor
> > available. As I am rather new to the linux/linux-mips development world,
> > I thought I'd give a heads up (it is causing my embedded system to
> > crash). Any direction on fixing it would be welcome, but I'm not sure
> > I'll get to the point where I will submit any patches any time soon.
> 
> People break things from time to time, but at least at one point
> in history, R3xxx platforms were correctly supported by the
> FPU emulator code.  Looking at the source code on my
> system, it looks like traps.c has been "cleaned up" in a
> somewhat wierd manner, such that the test for whether
> there is an FPU happens redundantly, once in the specific
> case of a 4K family CPU (which you would not hit on your
> TX39), and again just after the switch on the CPU type.
> Did someone screw up the setting of mips_cpu.options
> for a TX39xx or something?  Is that code missing from
> the sources that you're using?  Are you sure that it isn't
> something else blowing up on you?  There have been
> mods made locally here and there that might have
> broken the FPU emulator for R3xxx platforms, but
> I didn't think that any of them were up on OSS.sgi.com
> or kernel.org.
> 
>             Regards,
> 
>             Kevin K.

I am actually using the 2.4.18 stable kernel source, although I did
check the 2.5.14 source tree I have to see if any modifications had
taken place. My problem is the in signal.c function setup_sigcontext
has:

	if (current->used_math) {	/* fp is active.  */
		set_cp0_status(ST0_CU1);
		err |= save_fp_context(sc);
		last_task_used_math = NULL;
		regs->cp0_status &= ~ST0_CU1;
		current->used_math = 0;
	}

There is no check to see if I have an FPU. I modified it to:

	if (current->used_math) {	/* fp is active.  */
		if (mips_cpu.options & MIPS_CPU_FPU) {
			set_cp0_status(ST0_CU1);
			err |= save_fp_context(sc);
			regs->cp0_status &= ~ST0_CU1;
		}
		last_task_used_math = NULL;
		current->used_math = 0;
	}

And now I am not crashing. As far as how it is supposed to be setup, I
don't really know - like I said, I'm pretty new at this. I don't see any
ifdefs/checks around the code in traps.c

	case CPU_R2000:
	case CPU_R3000:
	case CPU_R3000A:
	case CPU_R3041:
	case CPU_R3051:
	case CPU_R3052:
	case CPU_R3081:
	case CPU_R3081E:
	case CPU_TX3912:
	case CPU_TX3922:
	case CPU_TX3927:
	        save_fp_context = _save_fp_context;
		restore_fp_context = _restore_fp_context;

I would think that traps.c would be were you would set up to handle
emulation (indeed it appears that there is an emulator option set up for
the processors with MIPS_CPU_4KEX && MIPS_CPU_4KTLB options set, but no
other locations seem to be concerned about this. Is this where floating
point should be dealt with?

Ryan

Re: fpu woes (TX3912)

[Kevin D. Kissell]

> I am actually using the 2.4.18 stable kernel source, although I did
> check the 2.5.14 source tree I have to see if any modifications had
> taken place. My problem is the in signal.c function setup_sigcontext
> has:

If you mean 2.4.18 from kernel.org, it's missing a lot of MIPS
fixes, I'm sorry to say.  Most of them went in at 2.4.19-pre2 or so.

> if (current->used_math) { /* fp is active.  */
> set_cp0_status(ST0_CU1);
> err |= save_fp_context(sc);
> last_task_used_math = NULL;
> regs->cp0_status &= ~ST0_CU1;
> current->used_math = 0;
> }
> 
> There is no check to see if I have an FPU. I modified it to:
> 
> if (current->used_math) { /* fp is active.  */
> if (mips_cpu.options & MIPS_CPU_FPU) {
> set_cp0_status(ST0_CU1);
> err |= save_fp_context(sc);
> regs->cp0_status &= ~ST0_CU1;
> }
> last_task_used_math = NULL;
> current->used_math = 0;
> }

This is a known (and old) problem, with a fix that somehow didn't
get distributed widely enough.   There are probably related problems
in the sources you are using that will likewise cause random core
dumps when the FP is used on a loaded system.  The 2.4.x branch
of the sources at http://oss.sgi.com/mips/ should have the full set
of fixes.

> And now I am not crashing. As far as how it is supposed to be setup, I
> don't really know - like I said, I'm pretty new at this. I don't see any
> ifdefs/checks around the code in traps.c
> 
> case CPU_R2000:
> case CPU_R3000:
> case CPU_R3000A:
> case CPU_R3041:
> case CPU_R3051:
> case CPU_R3052:
> case CPU_R3081:
> case CPU_R3081E:
> case CPU_TX3912:
> case CPU_TX3922:
> case CPU_TX3927:
>         save_fp_context = _save_fp_context;
>         restore_fp_context = _restore_fp_context;

The following lines in my copy of the file are:
                memcpy((void *)(KSEG0 + 0x80), &except_vec3_generic, 0x80);
                break;

        case CPU_UNKNOWN:
        default:
                panic("Unknown CPU type");
        }
        if (!(mips_cpu.options & MIPS_CPU_FPU)) {
                save_fp_context = fpu_emulator_save_context;
                restore_fp_context = fpu_emulator_restore_context;
        }

This should overwrite the fp_context save/restore pointers
with those of the emulator.  If that clause doesn't appear
in your traps.c file, please try putting it in.

            Regards,

            Kevin K.

Re: fpu woes (TX3912)

[Kevin D. Kissell]

> I am actually using the 2.4.18 stable kernel source, although I did
> check the 2.5.14 source tree I have to see if any modifications had
> taken place. My problem is the in signal.c function setup_sigcontext
> has:

If you mean 2.4.18 from kernel.org, it's missing a lot of MIPS
fixes, I'm sorry to say.  Most of them went in at 2.4.19-pre2 or so.

> if (current->used_math) { /* fp is active.  */
> set_cp0_status(ST0_CU1);
> err |= save_fp_context(sc);
> last_task_used_math = NULL;
> regs->cp0_status &= ~ST0_CU1;
> current->used_math = 0;
> }
> 
> There is no check to see if I have an FPU. I modified it to:
> 
> if (current->used_math) { /* fp is active.  */
> if (mips_cpu.options & MIPS_CPU_FPU) {
> set_cp0_status(ST0_CU1);
> err |= save_fp_context(sc);
> regs->cp0_status &= ~ST0_CU1;
> }
> last_task_used_math = NULL;
> current->used_math = 0;
> }

This is a known (and old) problem, with a fix that somehow didn't
get distributed widely enough.   There are probably related problems
in the sources you are using that will likewise cause random core
dumps when the FP is used on a loaded system.  The 2.4.x branch
of the sources at http://oss.sgi.com/mips/ should have the full set
of fixes.

> And now I am not crashing. As far as how it is supposed to be setup, I
> don't really know - like I said, I'm pretty new at this. I don't see any
> ifdefs/checks around the code in traps.c
> 
> case CPU_R2000:
> case CPU_R3000:
> case CPU_R3000A:
> case CPU_R3041:
> case CPU_R3051:
> case CPU_R3052:
> case CPU_R3081:
> case CPU_R3081E:
> case CPU_TX3912:
> case CPU_TX3922:
> case CPU_TX3927:
>         save_fp_context = _save_fp_context;
>         restore_fp_context = _restore_fp_context;

The following lines in my copy of the file are:
                memcpy((void *)(KSEG0 + 0x80), &except_vec3_generic, 0x80);
                break;

        case CPU_UNKNOWN:
        default:
                panic("Unknown CPU type");
        }
        if (!(mips_cpu.options & MIPS_CPU_FPU)) {
                save_fp_context = fpu_emulator_save_context;
                restore_fp_context = fpu_emulator_restore_context;
        }

This should overwrite the fp_context save/restore pointers
with those of the emulator.  If that clause doesn't appear
in your traps.c file, please try putting it in.

            Regards,

            Kevin K.

Re: fpu woes (TX3912)

[Maciej W. Rozycki]

On Mon, 15 Jul 2002, Kevin D. Kissell wrote:

> The following lines in my copy of the file are:
>                 memcpy((void *)(KSEG0 + 0x80), &except_vec3_generic, 0x80);
>                 break;
> 
>         case CPU_UNKNOWN:
>         default:
>                 panic("Unknown CPU type");
>         }
>         if (!(mips_cpu.options & MIPS_CPU_FPU)) {
>                 save_fp_context = fpu_emulator_save_context;
>                 restore_fp_context = fpu_emulator_restore_context;
>         }
> 
> This should overwrite the fp_context save/restore pointers
> with those of the emulator.  If that clause doesn't appear
> in your traps.c file, please try putting it in.

 It's worded a bit differently in the CVS:

	case CPU_UNKNOWN:
	default:
		panic("Unknown CPU type");
	}

	flush_icache_range(KSEG0, KSEG0 + 0x400);

	if (mips_cpu.options & MIPS_CPU_FPU) {
		save_fp_context = _save_fp_context;
		restore_fp_context = _restore_fp_context;
	} else {
		save_fp_context = fpu_emulator_save_context;
		restore_fp_context = fpu_emulator_restore_context;
	}

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +