Support NEON cortex-a9 on mvebu platform

Feature Requests
1

So mvebu platform is capable to support NEON instructions on Armada375 and Armada38x. Last time reason behind not include it was to limit target platforms. Now cortex-a9_neon is build via 'imx' platform anyway. I know that will require split between non-NEON chips and NEON one for mvebu but we had this PR already.
Currently I'm running 24.01.1 NEON enabled build on Armada385 based WD Cloud mirror gen2 with great results.

1 Like
2

Don't see this changing anytime soon.

3

For Cortex-A9, esp on the Armada 3** series, NEON ran on the VFPv3 registers, and you had to choose to use NEON or VFP instructions (you can't mix).

Armada only had 16 64-bit registers (VFPV3-D16), and NEON needed to break into two loads - so instruction issue is 1/2 clock rate.

Most applications, VFP was better as it was IEEE754 compliant... the delta between NEON and VFP was close to nil...

Debian has an older writeup on this.

4

This seems wrong, for most devices you can change from the default 16 registers to:

-CPU_SUBTYPE:=vfpv3-d16
+CPU_SUBTYPE:=vfpv3

if not:

CPU_SUBTYPE:=vfpv3-d16
+CPU_SUBTYPE:=neon-vfpv3
1 Like
5

If you define for NEON, you essentially get vfp3 anyways...

Looking at the supported capabilities, the maintainers cast a wide net to cover all of the supported SoC's within the mvebu Cortex-A9 (and in the case of Armada XP) and keep the maintance work to a minimum.

6
  • yes, just makes it explicit
  • yes, they catered to the lowest common denominator, a few knockoff dev boards that failed when compiled with 32 registers, the minority
  • the XP (wrt1900ac / mamba) actually runs built for 32 registers
  • ergo my first post in this thread

Edit: the long and short of it, unless the code is explicitly hand coded SIMD assembler (i.e. openssl), there ain't much to be bought.

1 Like
7

Agreed...

Interesting to note that Armada XP was actually a Marvell designed core - they had an architecture license much like Apple and Qualcomm - IIRC it was fairly performant and compared well to the off the shelf Cortex-A9's...

The move from their Sheeva core over to Cortex-A9 wasn't a technical decision - it was a business choice because of a couple of lawsuits from Patent Trolls...

Anyways, Cortex-A9 was an odd-duck, as both VPF and NEON were optional - note that there were a lot of Broadcom SoC's back in the day that didn't support either feature.

Anyways - old history - these are all pretty old chips these days - support is good, and we still see signifcant interest in them - but it would be hard to justify any new work on them when we have better/newer alternatives...

1 Like
8

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.