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

[Yousong Zhou]

On 26/11/2016, Christian Lamparter <chunkeey at 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
>> <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
>

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