[RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition

[RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition

[Dmitry Eremin-Solenikov]

Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too
little to run necessary applications. Add a new arm configuration based
on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM.

Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
---
 meta/conf/machine/qemuarma9.conf | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 meta/conf/machine/qemuarma9.conf

diff --git a/meta/conf/machine/qemuarma9.conf b/meta/conf/machine/qemuarma9.conf
new file mode 100644
index 0000000..119d172
--- /dev/null
+++ b/meta/conf/machine/qemuarma9.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: arm_versatile_cortexa9
+#@DESCRIPTION: arm_versatile_cortexa9
+
+require conf/machine/include/qemu.inc
+require conf/machine/include/tune-cortexa9.inc
+
+KERNEL_IMAGETYPE = "zImage"
+KERNEL_DEVICETREE = "vexpress-v2p-ca9.dtb"
+
+SERIAL_CONSOLE = "115200 ttyAMA0"
-- 
2.1.4

[RESEND][PATCH 2/3] scripts/runqemu: factor out some qemuarm configuration options

[Dmitry Eremin-Solenikov]

In preparation of adding qemuarma9 support to runqemu scripts, factor
out some qemuarm-related options to be handled in a more generic way.

Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
---
 scripts/runqemu-internal | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index bc2a355..f17bb05 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -124,6 +124,10 @@ if [ "$SLIRP_ENABLED" = "yes" ]; then
         QEMU_NETWORK_CMD=""
         DROOT="/dev/vda"
         ROOTFS_OPTIONS="-drive file=$ROOTFS,if=virtio,format=raw"
+    elif [ "$MACHINE" = "qemuarm" -o "$MACHINE" = "qemuarmv6" -o "$MACHINE" = "qemuarmv7" ]; then
+        QEMU_NETWORK_CMD=""
+        DROOT="/dev/sda"
+        ROOTFS_OPTIONS="-hda $ROOTFS"
     else
         QEMU_NETWORK_CMD=""
         DROOT="/dev/hda"
@@ -267,6 +271,11 @@ else
             DROOT="/dev/hda"
             ROOTFS_OPTIONS="-hda $ROOTFS"
         fi
+        if [ "$MACHINE" = "qemuarm" -o "$MACHINE" = "qemuarmv6" -o "$MACHINE" = "qemuarmv7" ]; then
+            QEMU_NETWORK_CMD="-net nic,vlan=0 $QEMU_TAP_CMD"
+            DROOT="/dev/sda"
+            ROOTFS_OPTIONS="-hda $ROOTFS"
+        fi
         if [ "$MACHINE" = "qemuarm64" ]; then
             QEMU_NETWORK_CMD="-netdev tap,id=net0,ifname=$TAP,script=no,downscript=no -device virtio-net-device,netdev=net0 "
             DROOT="/dev/vda"
@@ -359,8 +368,8 @@ if [ "$MACHINE" = "qemuarm" -o "$MACHINE" = "qemuarmv6" -o "$MACHINE" = "qemuarm
     QEMU_UI_OPTIONS="$QEMU_UI_OPTIONS"
     # QEMU_UI_OPTIONS="$QEMU_UI_OPTIONS -force-pointer"
     if [ "${FSTYPE:0:3}" = "ext" -o "$FSTYPE" = "btrfs" ]; then
-        KERNCMDLINE="root=/dev/sda rw console=ttyAMA0,115200 console=tty $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off"
-        QEMUOPTIONS="$QEMU_NETWORK_CMD -M ${MACHINE_SUBTYPE} -hda $ROOTFS -no-reboot $QEMU_UI_OPTIONS"
+        KERNCMDLINE="root=$DROOT rw console=ttyAMA0,115200 console=tty $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off"
+        QEMUOPTIONS="$QEMU_NETWORK_CMD -M ${MACHINE_SUBTYPE} $ROOTFS_OPTIONS -no-reboot $QEMU_UI_OPTIONS"
     fi
     if [ "$FSTYPE" = "nfs" ]; then
         if [ "$NFS_SERVER" = "192.168.7.1" -a ! -d "$NFS_DIR" ]; then
-- 
2.1.4

[RESEND][PATCH 3/3] scripts/runqemu: add qemuarma9 support

[Dmitry Eremin-Solenikov]

Support new qemuarma9 machine type. It mostly reuses existing qemuarm
setup, but the virtio-based network and disk devices.

Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
---
 scripts/runqemu          |  9 ++++++---
 scripts/runqemu-internal | 35 +++++++++++++++++++++++++++++++----
 2 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 84ece4d..87834f9 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -108,7 +108,7 @@ process_filename() {
 while true; do
     arg=${1}
     case "$arg" in
-        "qemux86" | "qemux86-64" | "qemuarm" | "qemuarm64" | "qemumips" | "qemumipsel" | \
+        "qemux86" | "qemux86-64" | "qemuarm" | "qemuarma9" | "qemuarm64" | "qemumips" | "qemumipsel" | \
         "qemumips64" | "qemush4"  | "qemuppc" | "qemumicroblaze" | "qemuzynq")
             [ -z "$MACHINE" ] && MACHINE=$arg || \
                 error "conflicting MACHINE types [$MACHINE] and [$arg]"
@@ -232,13 +232,13 @@ fi
 
 if [ -z "$MACHINE" ]; then
     if [ "x$FSTYPE" = "xvmdk" ]; then
-        MACHINE=`basename $VM | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
+        MACHINE=`basename $VM | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarma9\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
         if [ -z "$MACHINE" ]; then
             error "Unable to set MACHINE from vmdk filename [$VM]"
         fi
         echo "Set MACHINE to [$MACHINE] based on vmdk [$VM]"
     else
-        MACHINE=`basename $KERNEL | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
+        MACHINE=`basename $KERNEL | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarma9\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
         if [ -z "$MACHINE" ]; then
             error "Unable to set MACHINE from kernel filename [$KERNEL]"
         fi
@@ -304,6 +304,9 @@ QEMUX86_64_DEFAULT_FSTYPE=ext4
 QEMUARM_DEFAULT_KERNEL=zImage-qemuarm.bin
 QEMUARM_DEFAULT_FSTYPE=ext4
 
+QEMUARMA9_DEFAULT_KERNEL=zImage-qemuarma9.bin
+QEMUARMA9_DEFAULT_FSTYPE=ext4
+
 QEMUARM64_DEFAULT_KERNEL=Image-qemuarm64.bin
 QEMUARM64_DEFAULT_FSTYPE=ext4
 
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index f17bb05..a70c2cc 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -50,6 +50,9 @@ else
         "qemuarm")
             mem_size=128
             ;;
+        "qemuarma9")
+            mem_size=512
+            ;;
         "qemuarm64")
             mem_size=512
             ;;
@@ -128,6 +131,11 @@ if [ "$SLIRP_ENABLED" = "yes" ]; then
         QEMU_NETWORK_CMD=""
         DROOT="/dev/sda"
         ROOTFS_OPTIONS="-hda $ROOTFS"
+    elif [ "$MACHINE" = "qemuarma9" ]; then
+        QEMU_UI_OPTIONS="-nographic"
+        QEMU_NETWORK_CMD=""
+        DROOT="/dev/vda"
+        ROOTFS_OPTIONS="-drive id=disk0,file=$ROOTFS -device virtio-blk-device,drive=disk0"
     else
         QEMU_NETWORK_CMD=""
         DROOT="/dev/hda"
@@ -276,6 +284,11 @@ else
             DROOT="/dev/sda"
             ROOTFS_OPTIONS="-hda $ROOTFS"
         fi
+        if [ "$MACHINE" = "qemuarma9" ]; then
+            QEMU_NETWORK_CMD="-netdev tap,id=net0,ifname=$TAP,script=no,downscript=no -device virtio-net-device,netdev=net0 "
+            DROOT="/dev/vda"
+            ROOTFS_OPTIONS="-drive id=disk0,file=$ROOTFS -device virtio-blk-device,drive=disk0"
+        fi
         if [ "$MACHINE" = "qemuarm64" ]; then
             QEMU_NETWORK_CMD="-netdev tap,id=net0,ifname=$TAP,script=no,downscript=no -device virtio-net-device,netdev=net0 "
             DROOT="/dev/vda"
@@ -284,7 +297,7 @@ else
 
         KERNCMDLINE="mem=$QEMU_MEMORY"
         QEMU_UI_OPTIONS="-show-cursor -usb -usbdevice wacom-tablet"
-        if [ $MACHINE = 'qemuarm64' ]; then
+        if [ $MACHINE = 'qemuarm64' -o $MACHINE = 'qemuarma9' ]; then
             QEMU_UI_OPTIONS="-nographic"
         fi
 
@@ -308,6 +321,7 @@ case "$MACHINE" in
     "qemuppc") ;;
     "qemuarmv6") ;;
     "qemuarmv7") ;;
+    "qemuarma9") ;;
     "qemux86") ;;
     "qemux86-64") ;;
     "qemuzynq") ;;
@@ -361,14 +375,23 @@ if [ "$FSTYPE" = "nfs" ]; then
     NFSRUNNING="true"
 fi
 
-if [ "$MACHINE" = "qemuarm" -o "$MACHINE" = "qemuarmv6" -o "$MACHINE" = "qemuarmv7" ]; then
+if [ "$MACHINE" = "qemuarm" -o "$MACHINE" = "qemuarmv6" -o "$MACHINE" = "qemuarmv7" -o "$MACHINE" = "qemuarma9" ]; then
     QEMU=qemu-system-arm
-    MACHINE_SUBTYPE=versatilepb
+    if [ "$MACHINE" = "qemuarma9" ]; then
+        MACHINE_SUBTYPE="vexpress-a9"
+    else
+        MACHINE_SUBTYPE="versatilepb"
+    fi
     export QEMU_AUDIO_DRV="none"
     QEMU_UI_OPTIONS="$QEMU_UI_OPTIONS"
     # QEMU_UI_OPTIONS="$QEMU_UI_OPTIONS -force-pointer"
+    if [ "$MACHINE" = "qemuarma9" ]; then
+        TTYCONSOLE=""
+    else
+        TTYCONSOLE="console=tty"
+    fi
     if [ "${FSTYPE:0:3}" = "ext" -o "$FSTYPE" = "btrfs" ]; then
-        KERNCMDLINE="root=$DROOT rw console=ttyAMA0,115200 console=tty $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off"
+        KERNCMDLINE="root=$DROOT rw console=ttyAMA0,115200 $TTYCONSOLE $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY highres=off"
         QEMUOPTIONS="$QEMU_NETWORK_CMD -M ${MACHINE_SUBTYPE} $ROOTFS_OPTIONS -no-reboot $QEMU_UI_OPTIONS"
     fi
     if [ "$FSTYPE" = "nfs" ]; then
@@ -386,6 +409,10 @@ if [ "$MACHINE" = "qemuarm" -o "$MACHINE" = "qemuarmv6" -o "$MACHINE" = "qemuarm
     if [ "$MACHINE" = "qemuarmv7" ]; then
         QEMUOPTIONS="$QEMUOPTIONS -cpu cortex-a8"
     fi
+    if [ "$MACHINE" = "qemuarma9" ]; then
+        DTB="`dirname $KERNEL`/`basename $KERNEL -$MACHINE.bin`-vexpress-v2p-ca9.dtb"
+        QEMUOPTIONS="-dtb $DTB $QEMUOPTIONS -cpu cortex-a9"
+    fi
 fi
 
 if [ "$MACHINE" = "qemuarm64" ]; then
-- 
2.1.4

Re: [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
wrote:

> Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too
> little to run necessary applications. Add a new arm configuration based
> on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM.
>

Not sure I'm keen on oe-core having two almost-identical qemuarm machines.
Why not just change the qemuarm machine to use the A9?

Ross

[-- Attachment #2: Type: text/html, Size: 858 bytes --]

Re: [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition

[Martin Jansa]

On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote:
> On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
> wrote:
> 
> > Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too
> > little to run necessary applications. Add a new arm configuration based
> > on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM.
> >
> 
> Not sure I'm keen on oe-core having two almost-identical qemuarm machines.
> Why not just change the qemuarm machine to use the A9?

Then we should officially drop thumb1 support, because current qemuarm
builds are quite broken when thumb is enabled and dropping current
qemuarm or replacing it with A9 variant will prevent oe-core to be
testable on autobuilder. See
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition

[Andre McCurdy]

On Tue, May 12, 2015 at 7:47 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote:
>> On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
>> wrote:
>>
>> > Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too
>> > little to run necessary applications. Add a new arm configuration based
>> > on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM.
>> >
>>
>> Not sure I'm keen on oe-core having two almost-identical qemuarm machines.
>> Why not just change the qemuarm machine to use the A9?
>
> Then we should officially drop thumb1 support, because current qemuarm
> builds are quite broken when thumb is enabled and dropping current
> qemuarm or replacing it with A9 variant will prevent oe-core to be
> testable on autobuilder. See
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717

+1 for updating qemuarm to an ARMv7 CPU.

As for dropping thumb1 support that's probably fine too - although
technically (if someone really did want to keep thumb1 support alive)
I guess nothing prevents testing thumb1 binaries on an ARMv7 CPU?

> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition

[Richard Purdie]

On Wed, 2015-05-13 at 18:17 -0700, Andre McCurdy wrote:
> On Tue, May 12, 2015 at 7:47 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote:
> >> On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
> >> wrote:
> >>
> >> > Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too
> >> > little to run necessary applications. Add a new arm configuration based
> >> > on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM.
> >> >
> >>
> >> Not sure I'm keen on oe-core having two almost-identical qemuarm machines.
> >> Why not just change the qemuarm machine to use the A9?
> >
> > Then we should officially drop thumb1 support, because current qemuarm
> > builds are quite broken when thumb is enabled and dropping current
> > qemuarm or replacing it with A9 variant will prevent oe-core to be
> > testable on autobuilder. See
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
> 
> +1 for updating qemuarm to an ARMv7 CPU.

One thing I did notice about the new proposed arm machine was the lack
of graphics support. We really do need a machine with graphics. If we
could get a machine which had graphics and more memory that would be
much more attractive to switch to.

This also has implications on the kernel support (cc Bruce).

> As for dropping thumb1 support that's probably fine too - although
> technically (if someone really did want to keep thumb1 support alive)
> I guess nothing prevents testing thumb1 binaries on an ARMv7 CPU?

Just guessing but they might work in some cases an a v7 CPU but fail on
older ones due to alignment constraints?

Cheers,

Richard

Re: [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition

[Bruce Ashfield]

On 2015-05-14 09:46 AM, Richard Purdie wrote:
> On Wed, 2015-05-13 at 18:17 -0700, Andre McCurdy wrote:
>> On Tue, May 12, 2015 at 7:47 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote:
>>>> On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
>>>> wrote:
>>>>
>>>>> Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too
>>>>> little to run necessary applications. Add a new arm configuration based
>>>>> on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM.
>>>>>
>>>>
>>>> Not sure I'm keen on oe-core having two almost-identical qemuarm machines.
>>>> Why not just change the qemuarm machine to use the A9?
>>>
>>> Then we should officially drop thumb1 support, because current qemuarm
>>> builds are quite broken when thumb is enabled and dropping current
>>> qemuarm or replacing it with A9 variant will prevent oe-core to be
>>> testable on autobuilder. See
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
>>
>> +1 for updating qemuarm to an ARMv7 CPU.
>
> One thing I did notice about the new proposed arm machine was the lack
> of graphics support. We really do need a machine with graphics. If we
> could get a machine which had graphics and more memory that would be
> much more attractive to switch to.
>
> This also has implications on the kernel support (cc Bruce).

I've been using the qemuarma9 machine in some different contexts for
a while now, and in fact, there's a BSP definition in linux-yocto
already for it.

So from that point of view, the kernel impacts are understood.

But not only does the qemuarma9 lack graphics, it also has issues
with disk and USB, so generally it isn't as usable as the arm926
qemu variant.

There are other options that have newer CPUs, or just changing the
cpu .. but a wholesale switch to the "qemuarma9" machine tends to
bring some new challenges.

Bruce

>
>> As for dropping thumb1 support that's probably fine too - although
>> technically (if someone really did want to keep thumb1 support alive)
>> I guess nothing prevents testing thumb1 binaries on an ARMv7 CPU?
>
> Just guessing but they might work in some cases an a v7 CPU but fail on
> older ones due to alignment constraints?
>
> Cheers,
>
> Richard
>
>

Re: [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition

[Dmitry Eremin-Solenikov]

On 05/14/2015 05:37 PM, Bruce Ashfield wrote:
> On 2015-05-14 09:46 AM, Richard Purdie wrote:
>> On Wed, 2015-05-13 at 18:17 -0700, Andre McCurdy wrote:
>>> On Tue, May 12, 2015 at 7:47 AM, Martin Jansa
>>> <martin.jansa@gmail.com> wrote:
>>>> On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote:
>>>>> On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov
>>>>> <dmitry_eremin@mentor.com>
>>>>> wrote:
>>>>>
>>>>>> Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too
>>>>>> little to run necessary applications. Add a new arm configuration
>>>>>> based
>>>>>> on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM.
>>>>>>
>>>>>
>>>>> Not sure I'm keen on oe-core having two almost-identical qemuarm
>>>>> machines.
>>>>> Why not just change the qemuarm machine to use the A9?
>>>>
>>>> Then we should officially drop thumb1 support, because current qemuarm
>>>> builds are quite broken when thumb is enabled and dropping current
>>>> qemuarm or replacing it with A9 variant will prevent oe-core to be
>>>> testable on autobuilder. See
>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
>>>
>>> +1 for updating qemuarm to an ARMv7 CPU.
>>
>> One thing I did notice about the new proposed arm machine was the lack
>> of graphics support. We really do need a machine with graphics. If we
>> could get a machine which had graphics and more memory that would be
>> much more attractive to switch to.
>>
>> This also has implications on the kernel support (cc Bruce).
>
> I've been using the qemuarma9 machine in some different contexts for
> a while now, and in fact, there's a BSP definition in linux-yocto
> already for it.
>
> So from that point of view, the kernel impacts are understood.
>
> But not only does the qemuarma9 lack graphics, it also has issues
> with disk and USB, so generally it isn't as usable as the arm926
> qemu variant.

I ended up enabling virtio to get disc working in qemuarma9. Such setup 
is used in provided runqemu patches. However I did not include a patch 
to linux-yocto recipe/git tree.

>
> There are other options that have newer CPUs, or just changing the
> cpu .. but a wholesale switch to the "qemuarma9" machine tends to
> bring some new challenges.

Yes, that is why in the patches I proposed qemuarma9 as an alternative 
(rather then a replacement) to plain qemuarm.

-- 
With best wishes
Dmitry

Re: [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition

[Bruce Ashfield]

On 2015-05-15 03:18 AM, Dmitry Eremin-Solenikov wrote:
> On 05/14/2015 05:37 PM, Bruce Ashfield wrote:
>> On 2015-05-14 09:46 AM, Richard Purdie wrote:
>>> On Wed, 2015-05-13 at 18:17 -0700, Andre McCurdy wrote:
>>>> On Tue, May 12, 2015 at 7:47 AM, Martin Jansa
>>>> <martin.jansa@gmail.com> wrote:
>>>>> On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote:
>>>>>> On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov
>>>>>> <dmitry_eremin@mentor.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too
>>>>>>> little to run necessary applications. Add a new arm configuration
>>>>>>> based
>>>>>>> on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of
>>>>>>> RAM.
>>>>>>>
>>>>>>
>>>>>> Not sure I'm keen on oe-core having two almost-identical qemuarm
>>>>>> machines.
>>>>>> Why not just change the qemuarm machine to use the A9?
>>>>>
>>>>> Then we should officially drop thumb1 support, because current qemuarm
>>>>> builds are quite broken when thumb is enabled and dropping current
>>>>> qemuarm or replacing it with A9 variant will prevent oe-core to be
>>>>> testable on autobuilder. See
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
>>>>
>>>> +1 for updating qemuarm to an ARMv7 CPU.
>>>
>>> One thing I did notice about the new proposed arm machine was the lack
>>> of graphics support. We really do need a machine with graphics. If we
>>> could get a machine which had graphics and more memory that would be
>>> much more attractive to switch to.
>>>
>>> This also has implications on the kernel support (cc Bruce).
>>
>> I've been using the qemuarma9 machine in some different contexts for
>> a while now, and in fact, there's a BSP definition in linux-yocto
>> already for it.
>>
>> So from that point of view, the kernel impacts are understood.
>>
>> But not only does the qemuarma9 lack graphics, it also has issues
>> with disk and USB, so generally it isn't as usable as the arm926
>> qemu variant.
>
> I ended up enabling virtio to get disc working in qemuarma9. Such setup
> is used in provided runqemu patches. However I did not include a patch
> to linux-yocto recipe/git tree.

Interesting. That didn't work all that well when I tried, but that was
over a year ago. The solution was to use SD card images here, but they
have limitations as well.

>
>>
>> There are other options that have newer CPUs, or just changing the
>> cpu .. but a wholesale switch to the "qemuarma9" machine tends to
>> bring some new challenges.
>
> Yes, that is why in the patches I proposed qemuarma9 as an alternative
> (rather then a replacement) to plain qemuarm.

Agreed (and I got that part), but my counter argument is that there are
other machines to chose from and it is better to find one that meets all
the needs, versus maintaining two.

Bruce

>