On Saturday, November 26, 2016 11:08:30 AM CET Yousong Zhou wrote: > On 26/11/2016, Christian Lamparter <chunk...@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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
