[PATCH 0/2] scripts/runqemu: 'qemuzynq' and 'qemumicroblaze'

[PATCH 0/2] scripts/runqemu: 'qemuzynq' and 'qemumicroblaze'

[Nathan Rossi]

The following patches add support to the runqemu scripts to allow for
the machines named 'qemuzynq' and 'qemumicroblaze' to be booted within
qemu. These target machines reside in the 'meta-xilinx' layer.

Regards,
Nathan

Nathan Rossi (2):
  scripts/runqemu: Add support for 'qemuzynq' machine
  scripts/runqemu: Add support for 'qemumicroblaze' machine

 scripts/runqemu          |    9 ++++++++-
 scripts/runqemu-internal |   28 ++++++++++++++++++++++++++++
 2 files changed, 36 insertions(+), 1 deletions(-)

-- 
1.7.5.4

[PATCH 1/2] scripts/runqemu: Add support for 'qemuzynq' machine

[Nathan Rossi]

* Add support to boot the 'qemuzynq' machine in qemu-system-arm
* Use the specific machine model for Zynq 'xilinx-zynq-a9'
* Use the DTB generated from the kernel build as the DTB for boot
* Force use of initrd rootfs (either in ext or cpio formats)

Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
---
 scripts/runqemu          |    6 +++++-
 scripts/runqemu-internal |   15 +++++++++++++++
 2 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index f2eb2e1..01ef741 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -107,7 +107,8 @@ KVM_ENABLED="no"
 while true; do
     arg=${1}
     case "$arg" in
-        "qemux86" | "qemux86-64" | "qemuarm" | "qemumips" | "qemumipsel" | "qemumips64" | "qemush4"  | "qemuppc")
+        "qemux86" | "qemux86-64" | "qemuarm" | "qemumips" | "qemumipsel" | \
+        "qemumips64" | "qemush4"  | "qemuppc" | "qemuzynq")
             [ -z "$MACHINE" ] && MACHINE=$arg || \
                 error "conflicting MACHINE types [$MACHINE] and [$arg]"
             ;;
@@ -308,6 +309,9 @@ QEMUSH4_DEFAULT_FSTYPE=ext3
 QEMUPPC_DEFAULT_KERNEL=vmlinux-qemuppc.bin
 QEMUPPC_DEFAULT_FSTYPE=ext3
 
+QEMUZYNQ_DEFAULT_KERNEL=uImage
+QEMUZYNQ_DEFAULT_FSTYPE=cpio
+
 AKITA_DEFAULT_KERNEL=zImage-akita.bin
 AKITA_DEFAULT_FSTYPE=jffs2
 
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 4f3ba7b..f156c4d 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -59,6 +59,9 @@ else
         "qemush4")
             mem_size=1024
             ;;
+        "qemuzynq")
+            mem_size=1024
+            ;;
         *)
             mem_size=64
             ;;
@@ -270,6 +273,7 @@ case "$MACHINE" in
     "qemuarmv7") ;;
     "qemux86") ;;
     "qemux86-64") ;;
+    "qemuzynq") ;;
     "akita") ;;
     "spitz") ;;
     *)
@@ -492,6 +496,17 @@ if [ "$MACHINE" = "akita" ]; then
     fi
 fi
 
+if [ "$MACHINE" = "qemuzynq" ]; then
+    QEMU=qemu-system-arm
+    QEMU_SYSTEM_OPTIONS="-M xilinx-zynq-a9 -serial null -serial mon:stdio -dtb $KERNEL-$MACHINE.dtb"
+    # zynq serial ports are named 'ttyPS0' and 'ttyPS1', fixup the default values
+    SCRIPT_KERNEL_OPT=$(echo "$SCRIPT_KERNEL_OPT" | sed 's/console=ttyS/console=ttyPS/g')
+    if [ "${FSTYPE:0:3}" = "ext" -o "${FSTYPE:0:4}" = "cpio" ]; then
+        KERNCMDLINE="earlyprintk root=/dev/ram rw"
+        QEMUOPTIONS="$QEMU_SYSTEM_OPTIONS -initrd $ROOTFS"
+    fi
+fi
+
 if [ "x$RAMFS" = "xtrue" ]; then
     QEMUOPTIONS="-initrd $ROOTFS -nographic"
     KERNCMDLINE="root=/dev/ram0 debugshell"
-- 
1.7.5.4

[PATCH 2/2] scripts/runqemu: Add support for 'qemumicroblaze' machine

[Nathan Rossi]

* Add support to boot the 'qemumicroblaze' machine in
  qemu-system-microblazeel
* Use the specific machine model for a MicroBlaze system 'petalogix-ml605'
* Use the DTB generated from the kernel build as the DTB for boot
* Force use of initrd rootfs (either in ext or cpio formats)

Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
---
 scripts/runqemu          |    5 ++++-
 scripts/runqemu-internal |   13 +++++++++++++
 2 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 01ef741..5f7f252 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -108,7 +108,7 @@ while true; do
     arg=${1}
     case "$arg" in
         "qemux86" | "qemux86-64" | "qemuarm" | "qemumips" | "qemumipsel" | \
-        "qemumips64" | "qemush4"  | "qemuppc" | "qemuzynq")
+        "qemumips64" | "qemush4"  | "qemuppc" | "qemumicroblaze" | "qemuzynq")
             [ -z "$MACHINE" ] && MACHINE=$arg || \
                 error "conflicting MACHINE types [$MACHINE] and [$arg]"
             ;;
@@ -309,6 +309,9 @@ QEMUSH4_DEFAULT_FSTYPE=ext3
 QEMUPPC_DEFAULT_KERNEL=vmlinux-qemuppc.bin
 QEMUPPC_DEFAULT_FSTYPE=ext3
 
+QEMUMICROBLAZE_DEFAULT_KERNEL=linux.bin.ub
+QEMUMICROBLAZE_DEFAULT_FSTYPE=cpio
+
 QEMUZYNQ_DEFAULT_KERNEL=uImage
 QEMUZYNQ_DEFAULT_FSTYPE=cpio
 
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index f156c4d..9619bec 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -50,6 +50,9 @@ else
         "qemuarm")
             mem_size=128
             ;;
+        "qemumicroblaze")
+            mem_size=64
+            ;;
         "qemumips"|"qemumips64")
             mem_size=128
             ;;
@@ -264,6 +267,7 @@ fi
 
 case "$MACHINE" in
     "qemuarm") ;;
+    "qemumicroblaze") ;;
     "qemumips") ;;
     "qemumipsel") ;;
     "qemumips64") ;;
@@ -496,6 +500,15 @@ if [ "$MACHINE" = "akita" ]; then
     fi
 fi
 
+if [ "$MACHINE" = "qemumicroblaze" ]; then
+    QEMU=qemu-system-microblazeel
+    QEMU_SYSTEM_OPTIONS="-M petalogix-ml605 -serial mon:stdio -dtb $KERNEL-$MACHINE.dtb"
+    if [ "${FSTYPE:0:3}" = "ext" -o "${FSTYPE:0:4}" = "cpio" ]; then
+        KERNCMDLINE="earlyprintk root=/dev/ram rw"
+        QEMUOPTIONS="$QEMU_SYSTEM_OPTIONS -initrd $ROOTFS"
+    fi
+fi
+
 if [ "$MACHINE" = "qemuzynq" ]; then
     QEMU=qemu-system-arm
     QEMU_SYSTEM_OPTIONS="-M xilinx-zynq-a9 -serial null -serial mon:stdio -dtb $KERNEL-$MACHINE.dtb"
-- 
1.7.5.4

Re: [PATCH 0/2] scripts/runqemu: 'qemuzynq' and 'qemumicroblaze'

[Paul Eggleton]

Hi Nathan/all,

On Thursday 04 July 2013 17:42:26 Nathan Rossi wrote:
> The following patches add support to the runqemu scripts to allow for
> the machines named 'qemuzynq' and 'qemumicroblaze' to be booted within
> qemu. These target machines reside in the 'meta-xilinx' layer.

I think we should look at changing runqemu so that it can be extended to 
support additional machines in the layers that add support for the machines 
themselves. I'm not entirely sure how we would implement this, but it should 
be possible assuming runqemu can know the path to all layers that are enabled 
(just query bitbake for BBLAYERS?) and there was some standard mechanism 
within the layer to add the machine-specific parts for the runqemu script.

Since this is unlikely to happen immediately I've acked these patches going 
in, but I think we'll need to look at doing this some time soon.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 0/2] scripts/runqemu: 'qemuzynq' and 'qemumicroblaze'

[Burton, Ross]

On 9 July 2013 16:54, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> Since this is unlikely to happen immediately I've acked these patches going
> in, but I think we'll need to look at doing this some time soon.

Agreed.  To make sure this doesn't get forgotten, I filed #4827 yesterday.

Ross

Re: [PATCH 0/2] scripts/runqemu: 'qemuzynq' and 'qemumicroblaze'

[Nathan Rossi]

> -----Original Message-----
> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> Sent: Wednesday, July 10, 2013 1:54 AM
> To: openembedded-core@lists.openembedded.org
> Cc: Nathan Rossi; meta-xilinx@yoctoproject.org
> Subject: Re: [OE-core] [PATCH 0/2] scripts/runqemu: 'qemuzynq' and
> 'qemumicroblaze'
>
> Hi Nathan/all,
>
> On Thursday 04 July 2013 17:42:26 Nathan Rossi wrote:
> > The following patches add support to the runqemu scripts to allow for
> > the machines named 'qemuzynq' and 'qemumicroblaze' to be booted within
> > qemu. These target machines reside in the 'meta-xilinx' layer.
>
> I think we should look at changing runqemu so that it can be extended to
> support additional machines in the layers that add support for the
> machines
> themselves. I'm not entirely sure how we would implement this, but it
> should
> be possible assuming runqemu can know the path to all layers that are
> enabled
> (just query bitbake for BBLAYERS?) and there was some standard mechanism
> within the layer to add the machine-specific parts for the runqemu script.

Here are some ideas I had when I was initially looking at implementing the addition of the zynq and microblaze QEMU machines.

In the same way the Kernel, U-boot, etc have variables set in machine.conf's it might be worth looking at defining certain options for QEMU. This could even allow users to runqemu for the machine they are building, which is not a qemu* machine (these variables could be retrieved via a similar mechanism to bitbake -e?). This might be beneficial as opposed to allowing some sort of cross-layer sub-script execution?

e.g.
# qemuarm
MACHINE_QEMU = "qemu-system-arm"
MACHINE_QEMU_MODEL = "versatilepb"


There is interest (for meta-xilinx) to support Device-Tree driven QEMU models (of which the feature hasn't made it into upstream QEMU yet). This might be interesting for those that want to test/simulate on systems that more closely resemble their target device, which could also allow for QA on machines that are outside of the oe-core layer.

microblaze_generic_fdt : http://lists.nongnu.org/archive/html/qemu-devel/2012-09/msg02437.html
arm_generic_fdt (still in development) : https://github.com/Xilinx/qemu/blob/xilinx-master/hw/arm/arm_generic_fdt.c

Regards,
Nathan

>
> Since this is unlikely to happen immediately I've acked these patches
> going
> in, but I think we'll need to look at doing this some time soon.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.