VFP handling in multiplatform feroceon kernels

VFP handling in multiplatform feroceon kernels

[Arnd Bergmann]

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:

commit 85d6943af50537d3aec58b967ffbd3fec88453e9
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Sat May 30 14:00:18 2009 +0100

    Fix the VFP handling on the Feroceon CPU
    
    This CPU generates synchronous VFP exceptions in a non-standard way -
    the FPEXC.EX bit set but without the FPSCR.IXE bit being set like in the
    VFP subarchitecture 1 or just the FPEXC.DEX bit like in VFP
    subarchitecture 2. The main problem is that the faulty instruction
    (which needs to be emulated in software) will be restarted several times
    (normally until a context switch disables the VFP). This patch ensures
    that the VFP exception is treated as synchronous.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Nicolas Pitre <nico@cam.org>

 diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
 index 83c4e38..1aeae38 100644 
 --- a/arch/arm/vfp/vfphw.S
 +++ b/arch/arm/vfp/vfphw.S
 @@ -100,6 +100,7 @@ ENTRY(vfp_support_entry)
        beq     no_old_VFP_process
        VFPFSTMIA r4, r5                @ save the working registers
        VFPFMRX r5, FPSCR               @ current status
 +#ifndef CONFIG_CPU_FEROCEON
        tst     r1, #FPEXC_EX           @ is there additional state to save?
        beq     1f
        VFPFMRX r6, FPINST              @ FPINST (only if FPEXC.EX is set)
 @@ -107,6 +108,7 @@ ENTRY(vfp_support_entry)
        beq     1f
        VFPFMRX r8, FPINST2             @ FPINST2 if needed (and present)
  1:
 +#endif
        stmia   r4, {r1, r5, r6, r8}    @ save FPEXC, FPSCR, FPINST, FPINST2
                                        @ and point r4 at the word at the
                                        @ start of the register dump
   ...


Any ideas for how this should be done better? I suppose we need a run-time
check for feroceon of some sort.

	Arnd

VFP handling in multiplatform feroceon kernels

[Andrew Lunn]

On Tue, Jun 24, 2014 at 03:17:06PM +0200, 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:

Hi Arnd

CPU_FEROCEAN is currently selected by Orion5x, Kirkwood and mv78xx0.
These are all ARMv5 machines. As far as i understand, we cannot
combine ARMv5 with ARMv6 and above. So is this really an issue? Should
we put in something defensive to prevent it being selected on anything
other than ARMv5?

	 Andrew

VFP handling in multiplatform feroceon kernels

[Catalin Marinas]

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.

-- 
Catalin

VFP handling in multiplatform feroceon kernels

[Arnd Bergmann]

On Tuesday 24 June 2014 15:31:57 Andrew Lunn wrote:
> On Tue, Jun 24, 2014 at 03:17:06PM +0200, 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:
> 
> Hi Arnd
> 
> CPU_FEROCEAN is currently selected by Orion5x, Kirkwood and mv78xx0.
> These are all ARMv5 machines. As far as i understand, we cannot
> combine ARMv5 with ARMv6 and above. So is this really an issue? Should
> we put in something defensive to prevent it being selected on anything
> other than ARMv5?

I don't think we have to worry about ARMv6 and above, we just need
to solve it for ARM926E(J), which is the same architecture level
as Feroceon and can now be built into the same kernel in reasonable
configurations.

	Arnd

VFP handling in multiplatform feroceon kernels

[Arnd Bergmann]

On Tuesday 24 June 2014 14:42:49 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.

We only support multiplatform configurations with Feroceon variants
that identify as Marvell-made, not the fake ARM CPU ID, and we already
rely on detecting the correct CPU type in other places, so we can e.g.
set up the cache correctly.

For all I can tell, the problem now exists only if you enable the
kirkwood platform, which does have its own ID. If this gets made
conditional on the CPU ID, we probably still also need to leave your
existing hack in place for the case of CONFIG_CPU_FEROCEON_OLD_ID
on a feroceon-only kernel.

	Arnd

VFP handling in multiplatform feroceon kernels

[Nicolas Pitre]

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.


Nicolas

VFP handling in multiplatform feroceon kernels

[Russell King - ARM Linux]

On Tue, Jun 24, 2014 at 03:17:06PM +0200, 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:

This is down confusion in the ID registers, and is something we've
known about for a very long time.

There is nothing that can be done about this: Marvell specifically
designed this variant of the Feroceon to look 100% identical to an
ARM926 in every respect, so it could in theory run anything that
checked for an ARM926 CPU.  However, the implementation is soo buggy
that the result is that software written for ARM926 can't run on it.

The net result is that the Feroceon is indistinguishable from an
ARM926 in every respect, except you need the work-arounds for
Feroceon to work.  This makes Feroceon fundamentally incompatible
with a single zImage.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

VFP handling in multiplatform feroceon kernels

[Catalin Marinas]

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.

-- 
Catalin

VFP handling in multiplatform feroceon kernels

[Russell King - ARM Linux]

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.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

VFP handling in multiplatform feroceon kernels

[Catalin Marinas]

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

VFP handling in multiplatform feroceon kernels

[Arnd Bergmann]

On Tuesday 24 June 2014 15:25:05 Catalin Marinas wrote:
> 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:
> > > > 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.

Note that we do disable CONFIG_CPU_FEROCEON_OLD_ID for both
kirkwood_defconfig and mvebu_v5_defconfig, and we don't even
support multiplatform on orion5x (yet), which is the platform
that needs CONFIG_CPU_FEROCEON_OLD_ID. It would be good to know
if all Orion5x suffer from this problem, or just the older ones.
I'm also not sure about mv78xx0, but it's possible we won't need
to care about that one much longer.

> The VFP code needs to be changed to
> depend on CPU_FEROCEON_OLD_ID, otherwise do proper id checking.

Right, that is all I was asking for.

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

For all I can tell, the VFP assembly is the only code that doesn't use the
proc-feroceon.S abstraction.

	Arnd

VFP handling in multiplatform feroceon kernels

[Russell King - ARM Linux]

On Tue, Jun 24, 2014 at 03:25:05PM +0100, Catalin Marinas wrote:
> On Tue, Jun 24, 2014 at 03:14:23PM +0100, Russell King - ARM Linux wrote:
> > 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?

Then someone tries to boot on a Feroceon platform which is supported by
the kernel (because some versions have the CPUs with the new ID) but
they have an old ID, and they get the ARM926 code being used instead,
resulting in god knows what happening (I actually don't know, but given
that it's buggy cache ops, I suspect the result is some kind of data
corruption, which could result in filesystem corruption.)

My personal stance on this is that I did not want the ARM926 crap ID
ever merged into mainline.  Nicolas was (as ever) extremely forceful
over that and got his way.

The CPU/MMU stuff is already handled, but absolutely requires that
CPU_FEROCEON_OLD_ID is set correctly: you can't support both the old
Feroceon ID and ARM926 in the same kernel, it's one or the other.  So
either you enable this option and not boot the kernel on any ARM926
platform, or you keep it disabled and not boot it on anything using
the old plagerised ID.

As I point out, the problem is that if we build a kernel with ARM926
plus Feroceon support (thus including some of the Feroceon platforms),
and omitting the plagerised ID, how do we stop the potential data
corruption occuring should we boot on a Feroceon platform with the
old IDs.

It may be far better and less error prone just to say that we support
a single zImage containing ARM926 support _or_ a single zImage
containing Feroceon support, but not both ARM926 and (any) Feroceon
together.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

VFP handling in multiplatform feroceon kernels

[Nicolas Pitre]

On Tue, 24 Jun 2014, Arnd Bergmann wrote:

> On Tuesday 24 June 2014 15:25:05 Catalin Marinas wrote:
> > 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:
> > > > > 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.
> 
> Note that we do disable CONFIG_CPU_FEROCEON_OLD_ID for both
> kirkwood_defconfig and mvebu_v5_defconfig, and we don't even
> support multiplatform on orion5x (yet), which is the platform
> that needs CONFIG_CPU_FEROCEON_OLD_ID. It would be good to know
> if all Orion5x suffer from this problem, or just the older ones.

Only the early revisions did suffer from this.


Nicolas

VFP handling in multiplatform feroceon kernels

[Nicolas Pitre]

On Tue, 24 Jun 2014, 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.

Even better.  I looked too quickly at the patch seeing a #ifdef while it 
is in fact #ifndef.

What about something like this?

diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index be807625ed..d46eb84884 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -115,7 +115,7 @@ ENTRY(vfp_support_entry)
 	beq	vfp_reload_hw		@ then the hw state needs reloading
 	VFPFSTMIA r4, r5		@ save the working registers
 	VFPFMRX	r5, FPSCR		@ current status
-#ifndef CONFIG_CPU_FEROCEON
+vfp_extra:
 	tst	r1, #FPEXC_EX		@ is there additional state to save?
 	beq	1f
 	VFPFMRX	r6, FPINST		@ FPINST (only if FPEXC.EX is set)
@@ -123,7 +123,6 @@ ENTRY(vfp_support_entry)
 	beq	1f
 	VFPFMRX	r8, FPINST2		@ FPINST2 if needed (and present)
 1:
-#endif
 	stmia	r4, {r1, r5, r6, r8}	@ save FPEXC, FPSCR, FPINST, FPINST2
 vfp_reload_hw:
 
@@ -219,6 +218,19 @@ process_exception:
 					@ retry the faulted instruction
 ENDPROC(vfp_support_entry)
 
+#ifdef CONFIG_CPU_FEROCEON
+ENTRY(vfp_feroceon_quirk)
+	/* force a skip over the imprecise VFP abort handling */
+	adr	r0, vfp_extra
+	ldr	r1, .L_eq_insn
+	str	r1, [r0]
+	add	r1, r0, #4
+	b	feroceon_coherent_kern_range
+.L_eq_insn:
+	teq	r0, r0
+ENDPROC(vfp_feroceon_quirk)
+#endif
+
 ENTRY(vfp_save_state)
 	@ Save the current VFP state
 	@ r0 - save location

Then suffice to call vfp_feroceon_quirk() during boot when appropriate.


Nicolas

VFP handling in multiplatform feroceon kernels

[Arnd Bergmann]

On Tuesday 24 June 2014 10:49:23 Nicolas Pitre wrote:
> > 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.
> 
> Even better.  I looked too quickly at the patch seeing a #ifdef while it 
> is in fact #ifndef.
> 
> What about something like this?
> 

I should have posted the entire original patch. There are in fact three
#ifndef that were introduced there, two in vfphw.S and one in vfpmodule.c,
so it needs to be slightly more verbose, but the principle seems right.

	Arnd

VFP handling in multiplatform feroceon kernels

[Nicolas Pitre]

On Tue, 24 Jun 2014, Russell King - ARM Linux wrote:

> As I point out, the problem is that if we build a kernel with ARM926
> plus Feroceon support (thus including some of the Feroceon platforms),
> and omitting the plagerised ID, how do we stop the potential data
> corruption occuring should we boot on a Feroceon platform with the
> old IDs.

That's a valid concern.

I don't know if all the Feroceon CPU cores are buggy wrt the VFP, 
however only some of the Orion5x platforms had a Feroceon core using the 
plagerised ID.  Probably those two issues should be handled separately.

So for the later I'd simply forbid any Orion5x platforms from being part 
of a multi-platform kernel.


Nicolas

VFP handling in multiplatform feroceon kernels

[Arnd Bergmann]

On Tuesday 24 June 2014 10:56:44 Nicolas Pitre wrote:
> On Tue, 24 Jun 2014, Russell King - ARM Linux wrote:
> 
> > As I point out, the problem is that if we build a kernel with ARM926
> > plus Feroceon support (thus including some of the Feroceon platforms),
> > and omitting the plagerised ID, how do we stop the potential data
> > corruption occuring should we boot on a Feroceon platform with the
> > old IDs.
> 
> That's a valid concern.
> 
> I don't know if all the Feroceon CPU cores are buggy wrt the VFP, 
> however only some of the Orion5x platforms had a Feroceon core using the 
> plagerised ID.  Probably those two issues should be handled separately.
> 
> So for the later I'd simply forbid any Orion5x platforms from being part 
> of a multi-platform kernel.

We should definitely allow building a multiplatform kernel with both
Orion5x and Kirkwood, but we could make Orion5x conditional on ARM926
being disabled. Or we add a runtime-check in the Orion code to ensure
it only gets booted with the new CPU ID if ARM926 is enabled.

	Arnd