VFP handling in multiplatform feroceon kernels

Catalin Marinas
2014-06-24T14:25:05Z

On Tue, Jun 24, 2014 at 03:14:23PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 03:10:56PM +0100, Catalin Marinas wrote:
> > On Tue, Jun 24, 2014 at 03:04:14PM +0100, Nicolas Pitre wrote:
> > > On Tue, 24 Jun 2014, Catalin Marinas wrote:
> > >
> > > > On Tue, Jun 24, 2014 at 02:17:06PM +0100, Arnd Bergmann wrote:
> > > > > Since 3.16, we have the ability to build a multiplatform kernel
> > > > > that includes both kirkwood (feroceon) and some other ARMv5 CPU.
> > > > >
> > > > > I accidentally stumbled over a bug in the VFP code that looks
> > > > > like it will break at least ARM9 VFP support if CPU_FEROCEON
> > > > > is also enabled, introduced by this (old) commit:
> > > >
> > > > I would argue that the bug is in the CPU (feroceon). See the end of this
> > > > email:
> > > >
> > > > http://www.spinics.net/lists/arm-kernel/msg41460.html
> > > >
> > > > and my follow-up. Basically you can't avoid the conditional compilation
> > > > as Feroceon doesn't follow the VFP sub-architecture spec and doesn't
> > > > present itself as a different CPU from an _ARM_ 9. Unless things have
> > > > changed with Marvell's hardware implementation and they got a new id, I
> > > > suggest you don't enable this for multi-platform.
> > >
> > > Only the early revision did hijack the ARM9 ID but still. We certainly
> > > can determine at run time if the platform being booted is equiped with a
> > > Feroceon before user space is started. In that case I'd suggest some
> > > runtime code patching to branch to some out-of-line assembly code for
> > > Feroceon.
> >
> > You don't even need to branch to out of line assembly, just branch over
> > the imprecise VFP abort handling in arch/arm/vfp/vfphw.S.
>
> This is not just about VFP - it's much bigger than that. Feroceon can't
> use proc-arm926.S (it has errata in the cache maintanence instructions)
> which also need handing. That's why we have a separate implementation
> (proc-feroceon.S) so that ARM926 is not hurt by this stupidity.

As Arnd suggested, we could enable multi-platform only for newer
Feroceon chips which presumably have different id, keeping
CONFIG_CPU_FEROCEON_OLD_ID disabled. The VFP code needs to be changed to
depend on CPU_FEROCEON_OLD_ID, otherwise do proper id checking.

Are there other places where we need to check for CPU_FEROCEON_OLD_ID?

--
Catalin