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

[Christian Lamparter]

On Saturday, November 26, 2016 12:43:38 AM CET Yousong Zhou wrote:
> On 25 November 2016 at 01:29, Christian Lamparter
> <chunkeey at 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 <yszhou4tech at 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>