Re: R2300 (not the hay baler)

[Paul Burton <paul.burton@imgtec.com>]

On 19/11/13 11:21, Ralf Baechle wrote:
> On Tue, Nov 19, 2013 at 11:07:22AM +0000, Paul Burton wrote:
>
>> Does anyone still care about the R2300? I ask because I'm working on
>> the FP context switching code & noticed that I'm pretty sure the
>> fpu_save_single & fpu_restore_single macros used only from
>> r2300_switch.S are broken. They store each 32 bit value at the start
>> of the location of the 64 bit FP registers context in memory, which I
>> believe:
>>
>> 1) Won't work for odd indexed FP registers with the FPU emulator,
>>     ptrace or other code which assumes that 32 bit FP data is held in
>>     the even-indexed 64 bit FP register context.
>
> Note that much of that code has changed for 3.13 and the new code may or
> may not have inherited this bug.
>

May I ask which code you mean? Is there some FP work not in mips-for-
linux-next or on the mailing list?

>> 2) On big endian systems the 32 bit values will get saved to the most
>>     significant bits of the 64 bit context which I imagine will cause
>>     yet more problems.
>>
>> It seems like the only changes to r2300_switch.S for a *long* time have
>> been to keep it in sync with r4k_switch.S & the CPU is old enough that
>> all I get when I google for it is information about some hay baler.
>>
>> In short: does anyone care if I just submit a patch removing the R2300
>> code instead of blindly attempting to fix it up?
>
> Linux/MIPS is a product of the post-R3000 era - but Maciej (on cc) is doing
> his best to keep it alive and going on DECstations, including R2000 and
> R3000 based ones.  DECstations are little endian and all of them have a
> R2010 rsp R3010, that is have hardware floating point.
>
> I myself have an R3000-based workstation, a clone of a MIPS RS3230 (I think)
> sitting on my floor and waiting to be reactivated.  It's still running
> RISC/os.
>
>    Ralf
>

Fair enough, I'll leave the r2300_switch.S & fpu_{save,restore}_single
code alone (apart from changes which will leave the bug as-is).

Thanks,
     Paul