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

2016-11-28 Thread Christian Lamparter 
On Saturday, November 26, 2016 11:08:30 AM CET Yousong Zhou wrote:
> On 26/11/2016, Christian Lamparter  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 , 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

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

2016-11-25 Thread Yousong Zhou 
On 26/11/2016, Christian Lamparter  wrote:
> On Saturday, November 26, 2016 12:43:38 AM CET Yousong Zhou wrote:
>> On 25 November 2016 at 01:29, Christian Lamparter
>>  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 0x0004))
>> >>
>> >> Signed-off-by: Yousong Zhou 
>> >> ---
>> >> 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
>> > 0x0004)"
>> > 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 , 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 wh

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

2016-11-25 Thread Christian Lamparter 
On Saturday, November 26, 2016 12:43:38 AM CET Yousong Zhou wrote:
> On 25 November 2016 at 01:29, Christian Lamparter
>  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 0x0004))
> >>
> >> Signed-off-by: Yousong Zhou 
> >> ---
> >> 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 
> > 0x0004)"
> > 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 , 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] 

[1] 
[2] 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2016-11-25 Thread Yousong Zhou 
On 25 November 2016 at 01:29, Christian Lamparter
 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 0x0004))
>>
>> Signed-off-by: Yousong Zhou 
>> ---
>> 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 
> 0x0004)"
> 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.  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 will provide a updated patch in the following days.

yousong

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2016-11-25 Thread Yousong Zhou 
On 25 November 2016 at 00:52, Felix Fietkau  wrote:
> On 2016-11-24 17:03, 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 0x0004))
>>
>> Signed-off-by: Yousong Zhou 
>> ---
>> 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 think if we merge this, we could drop the realview target.
>
> - Felix
>

Yes, I also thought about this.  If realview target is only intended
to be used as a dev platform and not for daily use, then I expect
armvirt to provide better performance and to be made more convenient
with various virtio features, e.g. 9p-fs over virtio for file sharing
between host and guest.

yousong

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2016-11-24 Thread Christian Lamparter 
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 0x0004))
> 
> Signed-off-by: Yousong Zhou 
> ---
> 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 0x0004)"
there when I compiled a initramfs with neon-vfpv4.


Regards,
Christian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2016-11-24 Thread Felix Fietkau 
On 2016-11-24 17:03, 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 0x0004))
> 
> Signed-off-by: Yousong Zhou 
> ---
> 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 think if we merge this, we could drop the realview target.

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2016-11-24 Thread Yousong Zhou 
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 0x0004))

Signed-off-by: Yousong Zhou 
---
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.

Anyway it is posted here in case someone may be interested to play with it and
to quote the lwn.net article [1]

 > we can only speculate about its future uses in the green data center of the
 > future, as the hypervisor of choice for ARM-based networking equipment, or
 > even ARM-based laptops and desktops.

Prebuilt binaries are uploaded to Google Drive [2] in case someone may want to
give it a quick try

 [1] Supporting KVM on the ARM architecture, https://lwn.net/Articles/557132/
 [2] https://drive.google.com/drive/folders/0B0ollk-mJJJAUGplUnJaZ2RuUW8

 target/linux/armvirt/Makefile  |  27 +++
 target/linux/armvirt/README|  14 ++
 .../linux/armvirt/base-files/etc/board.d/00_model  |  14 ++
 target/linux/armvirt/base-files/etc/inittab|   3 +
 target/linux/armvirt/config-default| 230 +
 target/linux/armvirt/image/Makefile|  24 +++
 6 files changed, 312 insertions(+)
 create mode 100644 target/linux/armvirt/Makefile
 create mode 100644 target/linux/armvirt/README
 create mode 100755 target/linux/armvirt/base-files/etc/board.d/00_model
 create mode 100644 target/linux/armvirt/base-files/etc/inittab
 create mode 100644 target/linux/armvirt/config-default
 create mode 100644 target/linux/armvirt/image/Makefile

diff --git a/target/linux/armvirt/Makefile b/target/linux/armvirt/Makefile
new file mode 100644
index 000..f0d063e
--- /dev/null
+++ b/target/linux/armvirt/Makefile
@@ -0,0 +1,27 @@
+#
+# Copyright (C) 2016 Yousong Zhou 
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+include $(TOPDIR)/rules.mk
+
+ARCH:=arm
+BOARD:=armvirt
+BOARDNAME:=QEMU ARM Virtual Machine
+FEATURES:=ext4 fpu pci ramdisk rtc
+CPU_TYPE:=cortex-a15
+CPU_SUBTYPE:=neon
+MAINTAINER:=Yousong Zhou 
+
+KERNEL_PATCHVER:=4.4
+
+define Target/Description
+  Build images for QEMU ARM Virtual Machine
+endef
+
+include $(INCLUDE_DIR)/target.mk
+
+KERNELNAME:=zImage
+
+$(eval $(call BuildTarget))
diff --git a/target/linux/armvirt/README b/target/linux/armvirt/README
new file mode 100644
index 000..6ccb628
--- /dev/null
+++ b/target/linux/armvirt/README
@@ -0,0 +1,14 @@
+This is intended to be used with LEDE project to provide image for use with
+QEMU arm-softmmu virt machine.
+
+Example usages
+
+   # boot with initramfs embedded in
+   qemu-system-arm -nographic -M virt -m 64 -kernel 
lede-armvirt-zImage-initramfs
+
+   # boot with accel=kvm
+   qemu-system-arm -nographic -M virt,accel=kvm -cpu host -m 64 -kernel 
lede-armvirt-zImage-initramfs
+
+   # boot with a separate rootfs
+   qemu-system-arm -nographic -M virt -m 64 -kernel lede-armvirt-zImage \
+ -drive file=lede-armvirt-root.ext4,format=raw,if=virtio -append 
'root=/dev/vda rootwait'
diff --git a/target/linux/armvirt/base-files/etc/board.d/00_model 
b/target/linux/armvirt/base-files/etc/board.d/00_model
new file mode 100755
index 000..6ba51b8
--- /dev/null
+++ b/target/linux/armvirt/base-files/etc/board.d/00_model
@@ -0,0 +1,14 @@
+#!/bin/sh
+# Copyright (C) 2015 OpenWrt.org
+# Copyright (C) 2016 Yousong Zhou 
+
+. /lib/functions/uci-defaults.sh
+
+board_config_update
+
+ucidef_set_board_id "armvirt"
+ucidef_set_model_name "QEMU ARM Virtual Machine"
+
+board_config_flush
+
+exit 0
diff --git a/target/linux/armvirt/base-files/etc/inittab 
b/target/linux/armvirt/base-files/etc/inittab
new file mode 100644
index 000..9991ac4
--- /dev/null
+++ b/target/linux/armvirt/base-files/etc/inittab
@@ -0,0 +1,3 @@
+::sysinit:/etc/init.d/rcS S boot
+::shutdown:/etc/init.d/rcS K shutdown
+ttyAMA0::askfirst:/usr/libexec/login.sh
diff --git a/target/linux/armvirt/config-default 
b/target/linux/armvirt/config-default
new file mode 100644
index 000..e39cff8
--- /dev/null
+++ b/target/linux/armvirt/config-default
@@ -0,0 +1,230 @@
+CONFIG_ALIGNMENT_TRAP=y
+CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
+CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
+CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
+CONFIG_ARCH_HAS_SG_CHAIN=y
+CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
+CONFIG_ARCH_MULTIPLATFORM=y
+# CONFIG_ARCH_MULTI_CPU_AUTO is n