On 26/11/2016, Christian Lamparter <chunk...@googlemail.com> wrote: > On Saturday, November 26, 2016 12:43:38 AM CET Yousong Zhou wrote: >> On 25 November 2016 at 01:29, Christian Lamparter >> <chunk...@googlemail.com> wrote: >> > Hello, >> > >> > On Friday, November 25, 2016 12:03:54 AM CET Yousong Zhou wrote: >> >> An ARM Cortex-A machine provided by QEMU. >> >> >> >> Kernel drivers enabled: >> >> >> >> - pl011, uart >> >> - pl031, rtc >> >> - pl061, gpio >> >> - pci-host-generic >> >> - virtio_{mmio,pci,net,blk,scsi,console,balloon} >> >> - ext4 >> >> - DEBUG_BUGVERBOSE for debug purposes >> >> - neon, vfp extensions support (otherwise userland will fail with >> >> illegal instruction signal (code 0x00000004)) >> >> >> >> Signed-off-by: Yousong Zhou <yszhou4t...@gmail.com> >> >> --- >> >> I prepared this target initially only for the purposes of proper >> >> testing KVM >> >> support on Cubieboard2 as I cannot find an usable prebuilt binary on >> >> the net. >> >> >> >> It is posted as RFC because it will introduce a new target combination >> >> cortex-a15_neon and may place an extra burden on the build system of >> >> LEDE and >> >> the target users at the moment may be quite small. >> > >> > I started up initramfs image with qemu. And the /proc/cpuinfo stated: >> > Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt >> > vfpd32 lpae evtstrm >> > >> > So, wouldn't it make sense to change the >> > >> > CPU_SUBTYPE:=neon >> > >> > to >> > >> > CPU_SUBTYPE:=neon-vfpv4 >> > >> > Because, this way it will share the same "packages" with ipq806x. >> > So it will be less work for the phase2 builds. >> > >> > (Note: I haven't tested this with kvm on a A15, but only >> > qemu-system-arm >> > on a x86). But I haven't seen any "illegal instruction signal (code >> > 0x00000004)" >> > there when I compiled a initramfs with neon-vfpv4. >> > >> > >> > Regards, >> > Christian >> >> Yes, turning to neon-vfpv3 seems to be a fair trade-off as cortex-a15 >> is expected to have that feature on. > And that's what I don't understand. Because even the first Cortex-A15 (and > all A7) revisions that went into mass-production comes according to > ARM's Cortex-A15 Technical Reference Manual Table 14.1 [0] in the following > configurations: > - Neon (Advanced SIMDv2) and vfpv4 supported. > - only vfp4 > - no neon and no vfpv4 >
oops, not knowing that it also has this many variants > 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. > >> 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 > So adding a subtarget for those for your armvirt would come at no cost to > the phase2 builders. > > (Funnily enough, I also looked at the arm64 target and the README states > that it's currently kind of a virtual platform as well. So this can > be integrated as well?) > I tend to leave arm64 as is for now. arm64 and arm are too different to be listed under the same target. The other thing is that I have no arm64 hardware to play with :) >> 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 yousong > Regards, > Christian > > [0] > <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0438d/CEGCDBHC.html> > [1] <https://en.wikipedia.org/wiki/ARM_Cortex-A15> > [2] <https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures> > > -- yousong _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev