[LEDE-DEV] [RFC] target: armvirt: new target

[Christian Lamparter]

On Saturday, November 26, 2016 11:08:30 AM CET Yousong Zhou wrote:
> On 26/11/2016, Christian Lamparter <chunkeey at googlemail.com> wrote:
> > On Saturday, November 26, 2016 12:43:38 AM CET Yousong Zhou wrote:
> > So, given that information: Selecting just neon would automatically mean:
> > neon and vfpv4... However, Since the build-script isn't that clever it
> > will make an extra target and the phase2 builder would essentially build
> > the same stuff twice.
> >
> > (the older A9 and A8 had neon-vfpv3 tops [2] - but they can be a different
> > subtarget.)
> 
> That neon in FEATURES will be used to form gcc flag -mfpu=neon which
> according to gcc doc is an alias for -mfpu=neon-vfpv3, so I guess
> that's why neon and neon-vfpv4 are built separately.
"NEON" is an alias for "Advanced SIMD". ARM updated Advanced SIMD for 
the Cortex-A7 and A15 chips called it "Advanced SIMDv2" (they added
FMA and half-precision). So from that perspective it makes sense to
map fpu=neon to neon-vfpv3... but also have the neon-vfpv4 (for 
A7, A15, +++)

> >> The allwinner-a20 soc (dual-core cortex-a7) on cubieboard2 is also
> >> capable
> >> of neon-vfpv4 and I just assembled a small binary with ".fpu neon-vfpv4"
> >> from gas testsuite and it runs to end just fine with accel=kvm.  It
> >> should
> >> also work with accel=tcg as qemu can provide the emulation.  But I am not
> >> sure how it will work out with accel=kvm on a hardware without
> >> neon-vfpv4...
> >
> > I think the best idea would to make it like the brcm2708 targets and
> > have multiple subtargets each with different CPU_TYPE and CPU_SUBTYPEs.
> >
> > This is mainly because the RPI, RPI2 and now the RPI3 had all very
> > different
> > CPUs (RPI1 had a ARMv6 with just vfp, the RPI2 had an A7 with neon-vfpv4
> > and
> > the RPI3 had A53 with everything as well).
> >
> > So looking at <http://phase2.builds.lede-project.org/builders>, There are
> > already existing targets that compile:
> > A5 (at91)
> > A7 (Mediatek ARM? - really no features?)
> > A7-neon-vfpv4 (RPI2/bcm2709, (ipq4xxx))
> > A8-vfpv3 (sunxi(Allwinner A1X/A20/A3x),
> > A9 (layerscape)
> > A9-neon (zynq,imx6)
> > A9-vfpv3 (omap,mvebu)
> > A15-neon-vfpv4 (ipq806x)
> > A53-neon-vfpv4 (RPI3/bcm2710 (in the making))
> >
> 
> This list can be compacted a liitle to lift more burden on buildbots,
> e.g. -mtune only for a7, a15, a53
I've already posted a patch to the ML that set neon-vfpv4 for the MediaTek ARM.
Another candidate should be the layerscape platform (A9-neon?). omap could be
moved to the A9-Neon too. However the mvebu can't (The old Armada-370 doesn't
support NEON, but all other do.).

As for the armvirt target: If you only want to stick with a single target,
I think the A7 would be a better pick for the ARMv7... Not that it changes
much.
 
> >> I will provide a updated patch in the following days.
> > I very much like the idea. Getting kvm on arm and lede/openwrt is a bit
> > clunky.
> > Do you know of any qemu+kvm packages for openwrt/lede? Or should we try our
> >
> > hands at it?
> >
> 
> I opened a pr about qemu few days ago:
> https://github.com/openwrt/packages/pull/3550 .  I am going to disable
> a few features explicitly, otherwise it may fail when built by
> buildbots
Thanks, that's very useful. 

Regards,
Christian