Serious bug in 4.9.0 (FP ctxt corruption on some ppc-e500 BSPs except mvme3100)

[Till Straumann]

Joel Sherrill wrote:
> Till Straumann wrote:
>> The new multilib variant m8540 by default enables -mfloat-gprs=single
>> and is as such useless for now since we don't implement 
>> context-switching
>> the upper 32-bit of e500 GPRs.
>>   
> So what is required to implement "proper context switching"?
> I can't see that it is a whole lot.
>
> + what is the cpp conditional to detect the "proper way"?
Currently there is none.

Unfortunately, the bookE architecture complicates things
by introducing 'APU's (auxiliary processing units) which
are not defined by bookE itself but are processor-dependent.

Any APU may introduce additional registers which require
being saved/restored across a context switch.

The e500 defines two APUs, the use of which (ABI) is described
in the e500 ABI User's guide.

a) There is a SPE (signal/vector-processing) APU
b) There is a floating-point APU, i.e., FP operations are not
     carried out by a FPU as defined by the PowerPC/bookE
     architecture but by a specialized APU

BTW: Motorola says that neither of these will be supported
by next-generation PowerQUICC CPUs.

The register context of the SPE and FP APUs consists of
the 32 GPRs (but SPE and vector-single-precicion or
double-precision FP require all 64-bits of the GPRs)

The SPE has an 'accumulator register'
SPE and FP APU use a (shared) 'status register'
> + what does it change in the context structures?
Given the undefinedness of possible future APUs
what we need IMO is an API for supporting
'context-switch plugins'. Roughly, such an API
would define methods for an API

a) detecting presence of supported APU
b) providing size-alignment reqs of APU context
c) providing a context-init routine/callback
d) providing a context-switch routine/callback

a+b would be used during initialization to make
sure the task context is big enough. During this
step the callbacks c+d are installed.

E.g., to support the e500's SPE/SPFP APU the
respective plugin would

a) check (run-time) for proper CPU
b) return size of upper-half of 32 GPRs plus
    SPE accumulator, status reg etc.

c) set MSR[SPE] in context

d) switch upper 32-bits of GPRs, SPE accu and
    status reg.

Provisions for lazy switching of APU contexts
could be added.
>
> + what does it change in the context switch code?
>
> + Does it change anything in ISR processing?
I don't think so (ISRs are integer-only)

At any rate, this should be a 4.10 issue. 4.9.1 needs to add -msoft-float
to the CPU_CFLAGS of all affected BSPs.

T.
>> *********************************
>> -> Any e500 MUST use -msoft-float
>> *********************************
>> (and may therefore as well use -mpowerpc -msoft-float)
>>
>> There are several new BSPs which use -m8540 without soft-float which
>> will experience corruption of floating-point data since FP registers
>> are not properly saved/restored.
>>
>> In the future -- once we have proper context-switching in place -- the
>> new multilib variant may indeed be useful but ATM it must not be used!
>>
>>
>> -- Till
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>   
>
>