| Message ID | 20230320131845.3138015-7-ardb@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: vfp: Switch to C API to en/disable softirqs | expand |
On Mon, Mar 20, 2023 at 2:19 PM Ard Biesheuvel <ardb@kernel.org> wrote: > Feroceon CPUs have a non-standard implementation of VFP which reports > synchronous VFP exceptions using the async VFP flag. This requires a > workaround which is difficult to reconcile with other implementations, > making it tricky to support both versions in a single image. > > Since this is a v5 CPU, it is not supported by armhf and so the > likelihood that anybody is using this with recent distros/kernels and > rely on the VFP at the same time is extremely low. So let's just disable > VFP support on these cores, so we can remove the workaround. > > This will help future development to support v5 and v6 CPUs with a > single kernel image. > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> I agree, I have one of those systems as my NAS, currently running an (unsupported) version of ArchLinuxARM: $ cat /proc/cpuinfo processor : 0 model name : Feroceon 88FR131 rev 1 (v5l) BogoMIPS : 83.33 Features : swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part : 0x131 CPU revision : 1 Hm doesn't even have any VFP, I don't know what spins of this Marvell silicon that even does? Reviewed-by: Linus Walleij <linus.walleij@linaro.org> I think this is again on the level of a tree falling in the forest and no-one being there to hear it, but let's page Nico again because I am pretty sure if anyone worked with this it was him. Yours, Linus Walleij
On Tue, 21 Mar 2023 at 15:44, Linus Walleij <linus.walleij@linaro.org> wrote: > > On Mon, Mar 20, 2023 at 2:19 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > > Feroceon CPUs have a non-standard implementation of VFP which reports > > synchronous VFP exceptions using the async VFP flag. This requires a > > workaround which is difficult to reconcile with other implementations, > > making it tricky to support both versions in a single image. > > > > Since this is a v5 CPU, it is not supported by armhf and so the > > likelihood that anybody is using this with recent distros/kernels and > > rely on the VFP at the same time is extremely low. So let's just disable > > VFP support on these cores, so we can remove the workaround. > > > > This will help future development to support v5 and v6 CPUs with a > > single kernel image. > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > I agree, I have one of those systems as my NAS, currently running > an (unsupported) version of ArchLinuxARM: > > $ cat /proc/cpuinfo > processor : 0 > model name : Feroceon 88FR131 rev 1 (v5l) > BogoMIPS : 83.33 > Features : swp half thumb fastmult edsp > CPU implementer : 0x56 > CPU architecture: 5TE > CPU variant : 0x2 > CPU part : 0x131 > CPU revision : 1 > > Hm doesn't even have any VFP, I don't know what spins of this Marvell > silicon that even does? Arnd might have some more insight in that. Does this kernel have CONFIG_VFP enabled? > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > > I think this is again on the level of a tree falling in the forest and no-one > being there to hear it, but let's page Nico again because I am pretty > sure if anyone worked with this it was him. > > Yours, > Linus Walleij
On Tue, 21 Mar 2023, Linus Walleij wrote: > On Mon, Mar 20, 2023 at 2:19 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > > Feroceon CPUs have a non-standard implementation of VFP which reports > > synchronous VFP exceptions using the async VFP flag. This requires a > > workaround which is difficult to reconcile with other implementations, > > making it tricky to support both versions in a single image. > > > > Since this is a v5 CPU, it is not supported by armhf and so the > > likelihood that anybody is using this with recent distros/kernels and > > rely on the VFP at the same time is extremely low. So let's just disable > > VFP support on these cores, so we can remove the workaround. > > > > This will help future development to support v5 and v6 CPUs with a > > single kernel image. > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > I agree, I have one of those systems as my NAS, currently running > an (unsupported) version of ArchLinuxARM: > > $ cat /proc/cpuinfo > processor : 0 > model name : Feroceon 88FR131 rev 1 (v5l) > BogoMIPS : 83.33 > Features : swp half thumb fastmult edsp > CPU implementer : 0x56 > CPU architecture: 5TE > CPU variant : 0x2 > CPU part : 0x131 > CPU revision : 1 > > Hm doesn't even have any VFP, I don't know what spins of this Marvell > silicon that even does? > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > > I think this is again on the level of a tree falling in the forest and no-one > being there to hear it, but let's page Nico again because I am pretty > sure if anyone worked with this it was him. That was more than 15 years ago it seems. Not getting any younger. I don't think (or rather I don't remember to be more accurate) that any Marvell ARMv5TE had any VFP support. In any case, as stated above, no ARMv5 compatible distros have VFP support. Acked-by: Nicolas Pitre <nico@fluxnic.net> Nicolas
On Tue, Mar 21, 2023 at 4:43 PM Ard Biesheuvel <ardb@kernel.org> wrote: > On Tue, 21 Mar 2023 at 15:44, Linus Walleij <linus.walleij@linaro.org> wrote: > > Hm doesn't even have any VFP, I don't know what spins of this Marvell > > silicon that even does? > > Arnd might have some more insight in that. Does this kernel have > CONFIG_VFP enabled? Ah no, it's the mvebu_v5_defconfig which apparently doesn't even enable this. So even lesser chance of running into it. Yours, Linus Walleij
On Tue, Mar 21, 2023, at 16:42, Ard Biesheuvel wrote: > On Tue, 21 Mar 2023 at 15:44, Linus Walleij <linus.walleij@linaro.org> wrote: >> I agree, I have one of those systems as my NAS, currently running >> an (unsupported) version of ArchLinuxARM: >> >> $ cat /proc/cpuinfo >> processor : 0 >> model name : Feroceon 88FR131 rev 1 (v5l) >> BogoMIPS : 83.33 >> Features : swp half thumb fastmult edsp >> CPU implementer : 0x56 >> CPU architecture: 5TE >> CPU variant : 0x2 >> CPU part : 0x131 >> CPU revision : 1 >> >> Hm doesn't even have any VFP, I don't know what spins of this Marvell >> silicon that even does? > > Arnd might have some more insight in that. I did the research again last week when we discussed this on IRC. It turns out that the information I had put into Documentation/arm/marvell.rst is actually correct, and out of the various Feroceon/Mohawk CPU cores, only the very last dual-issue "Jolteon" cores have VFP, the numbers are 88fr571-vd (used in mv78xx0), and Feroceon-2850 88fr531-vd (used in Orion-2 88F5281, but not more common Orion 88F518x and Kirkwood). On a board level, none of the machines using DT have these chips, the only remaining board files in 6.3 are TERASTATION_WXL, TERASTATION_PRO2 and TS409. The first two of those are being actively supported by the https://github.com/1000001101000/Debian_on_Buffalo project, but the maintainer confirmed that they don't expect any user to run VFP-enabled binaries on the Debian armel distro. Arnd
diff --git a/arch/arm/mm/proc-feroceon.S b/arch/arm/mm/proc-feroceon.S index 61ce82aca6f0d603..072ff9b451f846bf 100644 --- a/arch/arm/mm/proc-feroceon.S +++ b/arch/arm/mm/proc-feroceon.S @@ -56,6 +56,10 @@ ENTRY(cpu_feroceon_proc_init) movne r2, r2, lsr #2 @ turned into # of sets sub r2, r2, #(1 << 5) stmia r1, {r2, r3} +#ifdef CONFIG_VFP + mov r1, #1 @ disable quirky VFP + str_l r1, VFP_arch_feroceon, r2 +#endif ret lr /* diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S index 4d8478264d82b3d2..8049c6830eeb1380 100644 --- a/arch/arm/vfp/vfphw.S +++ b/arch/arm/vfp/vfphw.S @@ -110,7 +110,6 @@ 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 tst r1, #FPEXC_EX @ is there additional state to save? beq 1f VFPFMRX r6, FPINST @ FPINST (only if FPEXC.EX is set) @@ -118,7 +117,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: @@ -153,7 +151,6 @@ vfp_reload_hw: VFPFLDMIA r10, r5 @ reload the working registers while @ FPEXC is in a safe state ldmia r10, {r1, r5, r6, r8} @ load FPEXC, FPSCR, FPINST, FPINST2 -#ifndef CONFIG_CPU_FEROCEON tst r1, #FPEXC_EX @ is there additional state to restore? beq 1f VFPFMXR FPINST, r6 @ restore FPINST (only if FPEXC.EX is set) @@ -161,7 +158,6 @@ vfp_reload_hw: beq 1f VFPFMXR FPINST2, r8 @ FPINST2 if needed (and present) 1: -#endif VFPFMXR FPSCR, r5 @ restore status @ The context stored in the VFP hardware is up to date with this thread diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index 039c8dab990699e2..dd31d13ca1d8fc8a 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -42,7 +42,11 @@ static bool have_vfp __ro_after_init; * Used in startup: set to non-zero if VFP checks fail * After startup, holds VFP architecture */ -static unsigned int __initdata VFP_arch; +static unsigned int VFP_arch; + +#ifdef CONFIG_CPU_FEROCEON +extern unsigned int VFP_arch_feroceon __alias(VFP_arch); +#endif /* * The pointer to the vfpstate structure of the thread which currently @@ -357,14 +361,12 @@ void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) } if (fpexc & FPEXC_EX) { -#ifndef CONFIG_CPU_FEROCEON /* * Asynchronous exception. The instruction is read from FPINST * and the interrupted instruction has to be restarted. */ trigger = fmrx(FPINST); regs->ARM_pc -= 4; -#endif } else if (!(fpexc & FPEXC_DEX)) { /* * Illegal combination of bits. It can be caused by an
Feroceon CPUs have a non-standard implementation of VFP which reports synchronous VFP exceptions using the async VFP flag. This requires a workaround which is difficult to reconcile with other implementations, making it tricky to support both versions in a single image. Since this is a v5 CPU, it is not supported by armhf and so the likelihood that anybody is using this with recent distros/kernels and rely on the VFP at the same time is extremely low. So let's just disable VFP support on these cores, so we can remove the workaround. This will help future development to support v5 and v6 CPUs with a single kernel image. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- arch/arm/mm/proc-feroceon.S | 4 ++++ arch/arm/vfp/vfphw.S | 4 ---- arch/arm/vfp/vfpmodule.c | 8 +++++--- 3 files changed, 9 insertions(+), 7 deletions(-)