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
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.)
> 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))
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 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?
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>
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
