VFP available on a single CPU in a dual-CPU complex
arnd at arndb.de
Fri Aug 15 02:03:01 PDT 2014
On Friday 15 August 2014, Florian Fainelli wrote:
> On Broadcom's BCM63138 SoC, the second Cortex A9 CPU does not have
> VFP, which is a problem as one might imagine because we currently
> assume it is available for all CPUs within the complex.
Wow, that is pretty crazy.
> I started to patch vfp_support_entry to test for CPU1 and branch to a
> different location, but that raises a bunch of question, in particular
> what to do if NEON/VFP came from the kernel, how can we migrate that
> execution to CPU0?
> If the answer is don't use VFP, I guess that's fine, and I can have a
> runtime check in vfp_init() that checks for BCM63138 and set
> vfp_vector to vfp_null_entry even though we are running on a multi-v7
> kernel with VFP enabled.
I think adding hooks to the scheduler for this case is problematic, so
the easiest way would of course be to give the user a choice between
VFP or SMP on this hardware. For anything beyond that, you could do
a prototype patch (possibly for integration into OpenWRT) so we can
see how ugly it gets to support this setup.
One potentially workable approach may be to just forbid in-kernel
VFP (there is very little of that already, and we might not be
handling it right in a multiplatform kernel, I haven't checked)
if not all CPUs support it. For user space, you could mandate that
user space sets the right affinity mask for any process using VFP.
A general-purpose distro that relies on VFP wouldn't work on this
machine anyway, so we can reasonably assume that there is custom
user space involved if there is any VFP.
More information about the linux-arm-kernel