[PATCH 0/4] Add qemumips64 machine support

[PATCH 0/4] Add qemumips64 machine support

[Khem Raj]

This patchset adds a new qemu based machine target for mips64 Big-endian
linux-yocto recipe is modified to have it in tree to support qemumips64
machine

  image-vmdk.bbclass: disable the NOISO = "1" (2013-05-12 09:37:21 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib kraj/qemumips64
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/qemumips64

Bruce Ashfield (1):
  linux-yocto: add qemumips64 compatibility

Khem Raj (3):
  runqemu: Replace use of ifconfig with ip
  binutils: Add broadcom XLP support
  machine/qemumips64: Add machine definition

 meta/conf/machine/qemumips64.conf                  |  13 +
 meta/recipes-devtools/binutils/binutils-2.23.2.inc |   1 +
 .../binutils-2.23.2/binutils-xlp-support.patch     | 398 +++++++++++++++++++++
 meta/recipes-kernel/linux/linux-yocto-dev.bb       |   2 +-
 meta/recipes-kernel/linux/linux-yocto_3.8.bb       |   2 +-
 scripts/runqemu-gen-tapdevs                        |   6 +-
 scripts/runqemu-ifup                               |   6 +-
 scripts/runqemu-internal                           |   6 +-
 8 files changed, 423 insertions(+), 11 deletions(-)
 create mode 100644 meta/conf/machine/qemumips64.conf
 create mode 100644 meta/recipes-devtools/binutils/binutils-2.23.2/binutils-xlp-support.patch

-- 
1.8.2.1

[PATCH 1/4] runqemu: Replace use of ifconfig with ip

[Khem Raj]

ifconfig and its ilk (net-tools package) is deprecated in favour of iproute2 package
and is now removed by many distro's e.g. Archlinux. So we replace ifconfig with ip utility

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 scripts/runqemu-gen-tapdevs | 6 +++---
 scripts/runqemu-ifup        | 6 +++---
 scripts/runqemu-internal    | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/scripts/runqemu-gen-tapdevs b/scripts/runqemu-gen-tapdevs
index f5be30a..d3b27be 100755
--- a/scripts/runqemu-gen-tapdevs
+++ b/scripts/runqemu-gen-tapdevs
@@ -59,10 +59,10 @@ if [ ! -x "$RUNQEMU_IFUP" ]; then
 	exit 1
 fi
 
-IFCONFIG=`which ifconfig 2> /dev/null`
+IFCONFIG=`which ip 2> /dev/null`
 if [ -z "$IFCONFIG" ]; then
 	# Is it ever anywhere else?
-	IFCONFIG=/sbin/ifconfig
+	IFCONFIG=/sbin/ip
 fi
 if [ ! -x "$IFCONFIG" ]; then
        echo "$IFCONFIG cannot be executed"
@@ -70,7 +70,7 @@ if [ ! -x "$IFCONFIG" ]; then
 fi
 
 # Ensure we start with a clean slate
-for tap in `$IFCONFIG | grep ^tap | awk '{ print \$1 }' | sed s/://`; do
+for tap in `$IFCONFIG link | grep tap | awk '{ print \$2 }' | sed s/://`; do
 	echo "Note: Destroying pre-existing tap interface $tap..."
 	$TUNCTL -d $tap
 done
diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup
index 0926faf..8948153 100755
--- a/scripts/runqemu-ifup
+++ b/scripts/runqemu-ifup
@@ -70,10 +70,10 @@ if [ $STATUS -ne 0 ]; then
 	fi
 fi
 
-IFCONFIG=`which ifconfig 2> /dev/null`
+IFCONFIG=`which ip 2> /dev/null`
 if [ "x$IFCONFIG" = "x" ]; then
 	# better than nothing...
-	IFCONFIG=/sbin/ifconfig
+	IFCONFIG=/sbin/ip
 fi
 if [ ! -x "$IFCONFIG" ]; then
 	echo "$IFCONFIG cannot be executed"
@@ -100,7 +100,7 @@ if [ ! -x "$IPTABLES" ]; then
 fi
 
 n=$[ (`echo $TAP | sed 's/tap//'` * 2) + 1 ]
-$IFCONFIG $TAP 192.168.7.$n netmask 255.255.255.255
+$IFCONFIG addr add 192.168.7.$n/32 dev $TAP
 
 dest=$[ (`echo $TAP | sed 's/tap//'` * 2) + 2 ]
 $ROUTE add -host 192.168.7.$dest $TAP
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 3bd0a09..3c5282d 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -139,16 +139,16 @@ if [ ! -d "$LOCKDIR" ]; then
     chmod 777 $LOCKDIR
 fi
 
-IFCONFIG=`which ifconfig 2> /dev/null`
+IFCONFIG=`which ip 2> /dev/null`
 if [ -z "$IFCONFIG" ]; then
-    IFCONFIG=/sbin/ifconfig
+    IFCONFIG=/sbin/ip
 fi
 if [ ! -x "$IFCONFIG" ]; then
        echo "$IFCONFIG cannot be executed"
        exit 1
 fi
 
-POSSIBLE=`$IFCONFIG -a | grep '^tap' | awk '{print $1}' | sed s/://`
+POSSIBLE=`$IFCONFIG link | grep 'tap' | awk '{print $2}' | sed s/://`
 TAP=""
 LOCKFILE=""
 for tap in $POSSIBLE; do
-- 
1.8.2.1

[PATCH 2/4] linux-yocto: add qemumips64 compatibility

[Khem Raj]

From: Bruce Ashfield <bruce.ashfield@windriver.com>

The 3.8 and linux-yocto-dev kernel trees carry qemumips64 support. Adding
the board to the compatibility directly in the recipes is the first step
to adding mips64 support to the broader set of packages.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_3.8.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index fdea085..598c82c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -38,7 +38,7 @@ LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
 PR = "r0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"
+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64)"
 
 # Functionality flags
 KERNEL_FEATURES_append = " features/netfilter/netfilter.scc"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.8.bb b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
index 2fcaddd..b79fa4e 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
@@ -20,7 +20,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 
 KMETA = "meta"
 
-COMPATIBLE_MACHINE = "qemuarm|qemux86|qemuppc|qemumips|qemux86-64"
+COMPATIBLE_MACHINE = "qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
 
 # Functionality flags
 KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
-- 
1.8.2.1

[PATCH 3/4] binutils: Add broadcom XLP support

[Khem Raj]

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-devtools/binutils/binutils-2.23.2.inc |   1 +
 .../binutils-2.23.2/binutils-xlp-support.patch     | 398 +++++++++++++++++++++
 2 files changed, 399 insertions(+)
 create mode 100644 meta/recipes-devtools/binutils/binutils-2.23.2/binutils-xlp-support.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.23.2.inc b/meta/recipes-devtools/binutils/binutils-2.23.2.inc
index ddbe522..07bc7e0 100644
--- a/meta/recipes-devtools/binutils/binutils-2.23.2.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.23.2.inc
@@ -29,6 +29,7 @@ SRC_URI = "\
      file://mips64-default-ld-emulation.patch \
      ${BACKPORT} \
      file://binutils-fix-over-array-bounds-issue.patch \
+     file://binutils-xlp-support.patch \
      "
 
 BACKPORT = "\
diff --git a/meta/recipes-devtools/binutils/binutils-2.23.2/binutils-xlp-support.patch b/meta/recipes-devtools/binutils/binutils-2.23.2/binutils-xlp-support.patch
new file mode 100644
index 0000000..b0f727a
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils-2.23.2/binutils-xlp-support.patch
@@ -0,0 +1,398 @@
+Upstream-Status: Unknown
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+
+From 26adb06ce515aadfec08ce13109b4b98287f677b Mon Sep 17 00:00:00 2001
+From: Nebu Philips <nphilips@netlogicmicro.com>
+Date: Fri, 30 Jul 2010 15:10:03 -0700
+Subject: [PATCH] Add support for Netlogic XLP
+
+Using the mipsisa64r2nlm target, add support for XLP from
+Netlogic. Also, update vendor name to NLM wherever applicable.
+---
+ bfd/aoutx.h           |    1 +
+ bfd/archures.c        |    1 +
+ bfd/bfd-in2.h         |    1 +
+ bfd/config.bfd        |    5 +++++
+ bfd/cpu-mips.c        |    6 ++++--
+ bfd/elfxx-mips.c      |    8 ++++++++
+ binutils/readelf.c    |    1 +
+ config.sub            |    6 ++++++
+ gas/config/tc-mips.c  |    7 ++++++-
+ gas/configure         |    3 +++
+ gas/configure.tgt     |    2 +-
+ gas/doc/c-mips.texi   |    3 ++-
+ include/elf/mips.h    |    1 +
+ include/opcode/mips.h |    6 +++++-
+ ld/configure.tgt      |    2 ++
+ opcodes/mips-dis.c    |    6 ++++++
+ opcodes/mips-opc.c    |   31 ++++++++++++++++++++-----------
+ 17 files changed, 73 insertions(+), 17 deletions(-)
+
+Index: binutils-2.23.2/bfd/aoutx.h
+===================================================================
+--- binutils-2.23.2.orig/bfd/aoutx.h	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/bfd/aoutx.h	2013-04-16 04:19:52.741282087 -0700
+@@ -798,6 +798,7 @@
+ 	case bfd_mach_mipsisa64r2:
+ 	case bfd_mach_mips_sb1:
+ 	case bfd_mach_mips_xlr:
++	case bfd_mach_mips_xlp:
+ 	  /* FIXME: These should be MIPS3, MIPS4, MIPS16, MIPS32, etc.  */
+ 	  arch_flags = M_MIPS2;
+ 	  break;
+Index: binutils-2.23.2/bfd/archures.c
+===================================================================
+--- binutils-2.23.2.orig/bfd/archures.c	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/bfd/archures.c	2013-04-16 04:19:52.741282087 -0700
+@@ -179,6 +179,7 @@
+ .#define bfd_mach_mips_octeonp		6601
+ .#define bfd_mach_mips_octeon2		6502
+ .#define bfd_mach_mips_xlr              887682   {* decimal 'XLR'  *}
++.#define bfd_mach_mips_xlp              887680   {* decimal 'XLP'  *}
+ .#define bfd_mach_mipsisa32             32
+ .#define bfd_mach_mipsisa32r2           33
+ .#define bfd_mach_mipsisa64             64
+Index: binutils-2.23.2/bfd/bfd-in2.h
+===================================================================
+--- binutils-2.23.2.orig/bfd/bfd-in2.h	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/bfd/bfd-in2.h	2013-04-16 04:19:52.745282088 -0700
+@@ -1908,6 +1908,7 @@
+ #define bfd_mach_mips_octeonp          6601
+ #define bfd_mach_mips_octeon2          6502
+ #define bfd_mach_mips_xlr              887682   /* decimal 'XLR'  */
++#define bfd_mach_mips_xlp              887680   /* decimal 'XLP'  */
+ #define bfd_mach_mipsisa32             32
+ #define bfd_mach_mipsisa32r2           33
+ #define bfd_mach_mipsisa64             64
+Index: binutils-2.23.2/bfd/config.bfd
+===================================================================
+--- binutils-2.23.2.orig/bfd/config.bfd	2013-04-16 04:19:50.897282052 -0700
++++ binutils-2.23.2/bfd/config.bfd	2013-04-16 04:19:52.745282088 -0700
+@@ -992,6 +992,11 @@
+     targ_defvec=bfd_elf32_littlemips_vec
+     targ_selvecs="bfd_elf32_bigmips_vec bfd_elf64_bigmips_vec bfd_elf64_littlemips_vec"
+     ;;
++  mipsisa64*-*-elf*)
++	targ_defvec=bfd_elf32_tradbigmips_vec
++	targ_selvecs="bfd_elf32_tradlittlemips_vec bfd_elf64_tradbigmips_vec bfd_elf64_tradlittlemips_vec"
++	want64=true
++	;;
+   mips*-*-elf* | mips*-*-rtems* | mips*-*-vxworks | mips*-*-windiss)
+     targ_defvec=bfd_elf32_bigmips_vec
+     targ_selvecs="bfd_elf32_littlemips_vec bfd_elf64_bigmips_vec bfd_elf64_littlemips_vec"
+Index: binutils-2.23.2/bfd/cpu-mips.c
+===================================================================
+--- binutils-2.23.2.orig/bfd/cpu-mips.c	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/bfd/cpu-mips.c	2013-04-16 04:27:21.097290918 -0700
+@@ -97,7 +97,8 @@
+   I_mipsocteonp,
+   I_mipsocteon2,
+   I_xlr,
+-  I_micromips
++  I_micromips,
++  I_xlp
+ };
+ 
+ #define NN(index) (&arch_info_struct[(index) + 1])
+@@ -140,7 +141,8 @@
+   N (64, 64, bfd_mach_mips_octeonp,"mips:octeon+",  FALSE, NN(I_mipsocteonp)),
+   N (64, 64, bfd_mach_mips_octeon2,"mips:octeon2",  FALSE, NN(I_mipsocteon2)),
+   N (64, 64, bfd_mach_mips_xlr, "mips:xlr",       FALSE, NN(I_xlr)),
+-  N (64, 64, bfd_mach_mips_micromips,"mips:micromips",FALSE,0)
++  N (64, 64, bfd_mach_mips_micromips,"mips:micromips",FALSE,NN(I_micromips)),
++  N (64, 64, bfd_mach_mips_xlp, "mips:xlp",      FALSE, 0)
+ };
+ 
+ /* The default architecture is mips:3000, but with a machine number of
+Index: binutils-2.23.2/bfd/elfxx-mips.c
+===================================================================
+--- binutils-2.23.2.orig/bfd/elfxx-mips.c	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/bfd/elfxx-mips.c	2013-04-16 04:19:52.749282089 -0700
+@@ -6293,6 +6293,9 @@
+     case E_MIPS_MACH_XLR:
+       return bfd_mach_mips_xlr;
+ 
++	case E_MIPS_MACH_XLP:
++      return bfd_mach_mips_xlp;
++
+     default:
+       switch (flags & EF_MIPS_ARCH)
+ 	{
+@@ -11048,6 +11051,10 @@
+       val = E_MIPS_ARCH_64R2 | E_MIPS_MACH_OCTEON2;
+       break;
+ 
++	case bfd_mach_mips_xlp:
++	  val = E_MIPS_ARCH_64R2 | E_MIPS_MACH_XLP;
++	  break;
++
+     case bfd_mach_mipsisa32:
+       val = E_MIPS_ARCH_32;
+       break;
+@@ -13639,6 +13646,7 @@
+   { bfd_mach_mips_octeon2, bfd_mach_mips_octeonp },
+   { bfd_mach_mips_octeonp, bfd_mach_mips_octeon },
+   { bfd_mach_mips_octeon, bfd_mach_mipsisa64r2 },
++  { bfd_mach_mips_xlp, bfd_mach_mipsisa64r2 },
+ 
+   /* MIPS64 extensions.  */
+   { bfd_mach_mipsisa64r2, bfd_mach_mipsisa64 },
+Index: binutils-2.23.2/binutils/readelf.c
+===================================================================
+--- binutils-2.23.2.orig/binutils/readelf.c	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/binutils/readelf.c	2013-04-16 04:19:52.753282089 -0700
+@@ -2435,6 +2435,7 @@
+ 	    case E_MIPS_MACH_OCTEON: strcat (buf, ", octeon"); break;
+ 	    case E_MIPS_MACH_OCTEON2: strcat (buf, ", octeon2"); break;
+ 	    case E_MIPS_MACH_XLR:  strcat (buf, ", xlr"); break;
++		case E_MIPS_MACH_XLP:  strcat (buf, ", xlp"); break;
+ 	    case 0:
+ 	    /* We simply ignore the field in this case to avoid confusion:
+ 	       MIPS ELF does not specify EF_MIPS_MACH, it is a GNU
+Index: binutils-2.23.2/gas/config/tc-mips.c
+===================================================================
+--- binutils-2.23.2.orig/gas/config/tc-mips.c	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/gas/config/tc-mips.c	2013-04-16 04:19:52.761282087 -0700
+@@ -530,6 +530,7 @@
+    || mips_opts.arch == CPU_RM7000                    \
+    || mips_opts.arch == CPU_VR5500                    \
+    || mips_opts.micromips                             \
++   || mips_opts.arch == CPU_XLP                       \
+    )
+ 
+ /* Whether the processor uses hardware interlocks to protect reads
+@@ -558,6 +559,7 @@
+     && mips_opts.isa != ISA_MIPS3)                    \
+    || mips_opts.arch == CPU_R4300                     \
+    || mips_opts.micromips                             \
++   || mips_opts.arch == CPU_XLP                       \
+    )
+ 
+ /* Whether the processor uses hardware interlocks to protect reads
+@@ -19176,9 +19178,12 @@
+   { "octeon+",	      0,      ISA_MIPS64R2,   CPU_OCTEONP },
+   { "octeon2",	      0,      ISA_MIPS64R2,   CPU_OCTEON2 },
+ 
+-  /* RMI Xlr */
++  /* Netlogic Xlr */
+   { "xlr",	      0,      ISA_MIPS64,     CPU_XLR },
+ 
++  /* Netlogic Xlp */
++  { "xlp",	      0,      ISA_MIPS64R2,   CPU_XLP },
++
+   /* Broadcom XLP.
+      XLP is mostly like XLR, with the prominent exception that it is
+      MIPS64R2 rather than MIPS64.  */
+Index: binutils-2.23.2/gas/configure
+===================================================================
+--- binutils-2.23.2.orig/gas/configure	2013-04-16 04:19:50.353282044 -0700
++++ binutils-2.23.2/gas/configure	2013-04-16 04:19:52.765282087 -0700
+@@ -12695,6 +12695,9 @@
+ 	  mipsisa64r2 | mipsisa64r2el)
+ 	    mips_cpu=mips64r2
+ 	    ;;
++	  mipsisa64r2nlm | mipsisa64r2nlmel)
++		mips_cpu=xlp
++		;;
+ 	  mipstx39 | mipstx39el)
+ 	    mips_cpu=r3900
+ 	    ;;
+Index: binutils-2.23.2/gas/configure.tgt
+===================================================================
+--- binutils-2.23.2.orig/gas/configure.tgt	2013-04-16 04:19:50.097282037 -0700
++++ binutils-2.23.2/gas/configure.tgt	2013-04-16 04:19:52.765282087 -0700
+@@ -310,7 +310,7 @@
+   mips-*-sysv4*MP* | mips-*-gnu*)	fmt=elf em=tmips ;;
+   mips*-sde-elf*)			fmt=elf em=tmips ;;
+   mips-*-sysv*)				fmt=ecoff ;;
+-  mips-*-elf* | mips-*-rtems*)		fmt=elf ;;
++  mips-*-elf* | mips-*-rtems*)		fmt=elf em=tmips ;;
+   mips-*-netbsd*)			fmt=elf em=tmips ;;
+   mips-*-openbsd*)			fmt=elf em=tmips ;;
+ 
+Index: binutils-2.23.2/include/elf/mips.h
+===================================================================
+--- binutils-2.23.2.orig/include/elf/mips.h	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/include/elf/mips.h	2013-04-16 04:19:52.765282087 -0700
+@@ -268,6 +268,7 @@
+ #define E_MIPS_MACH_SB1         0x008a0000
+ #define E_MIPS_MACH_OCTEON	0x008b0000
+ #define E_MIPS_MACH_XLR     	0x008c0000
++#define E_MIPS_MACH_XLP         0x008e0000
+ #define E_MIPS_MACH_OCTEON2	0x008d0000
+ #define E_MIPS_MACH_5400	0x00910000
+ #define E_MIPS_MACH_5500	0x00980000
+Index: binutils-2.23.2/include/opcode/mips.h
+===================================================================
+--- binutils-2.23.2.orig/include/opcode/mips.h	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/include/opcode/mips.h	2013-04-16 04:19:52.769282089 -0700
+@@ -772,8 +772,10 @@
+ #define INSN_LOONGSON_2F          0x80000000
+ /* Loongson 3A.  */
+ #define INSN_LOONGSON_3A          0x00000400
+-/* RMI Xlr instruction */
++/* Netlogic Xlr instruction */
+ #define INSN_XLR              	  0x00000020
++/* Netlogic Xlp instruction */
++#define INSN_XLP                  0x00000040
+ 
+ /* MCU (MicroController) ASE */
+ #define INSN_MCU		  0x00000010
+@@ -833,6 +835,7 @@
+ #define CPU_OCTEONP	6601
+ #define CPU_OCTEON2	6502
+ #define CPU_XLR     	887682   	/* decimal 'XLR'   */
++#define CPU_XLP         887680      /* decimal 'XLP'   */
+ 
+ /* Return true if the given CPU is included in INSN_* mask MASK.  */
+ 
+@@ -897,6 +900,9 @@
+     case CPU_XLR:
+       return (mask & INSN_XLR) != 0;
+ 
++    case CPU_XLP:
++      return (mask & INSN_XLP) != 0;
++
+     default:
+       return FALSE;
+     }
+Index: binutils-2.23.2/ld/configure.tgt
+===================================================================
+--- binutils-2.23.2.orig/ld/configure.tgt	2013-04-16 04:19:50.897282052 -0700
++++ binutils-2.23.2/ld/configure.tgt	2013-04-16 04:19:52.769282089 -0700
+@@ -426,6 +426,8 @@
+ 			targ_extra_emuls="elf32btsmip elf32ltsmipn32 elf64ltsmip elf32btsmipn32 elf64btsmip" ;;
+ mips*-sde-elf*)		targ_emul=elf32btsmip
+ 			targ_extra_emuls="elf32ltsmip elf32btsmipn32 elf64btsmip elf32ltsmipn32 elf64ltsmip" ;;
++mipsisa64*-*-elf*)     targ_emul=elf32btsmip
++			targ_extra_emuls="elf32ltsmip elf64btsmip elf64ltsmip" ;;
+ mips*el-*-elf*)		targ_emul=elf32elmip ;;
+ mips*-*-elf*)		targ_emul=elf32ebmip ;;
+ mips*-*-rtems*)		targ_emul=elf32ebmip ;;
+Index: binutils-2.23.2/opcodes/mips-dis.c
+===================================================================
+--- binutils-2.23.2.orig/opcodes/mips-dis.c	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/opcodes/mips-dis.c	2013-04-16 04:19:52.769282089 -0700
+@@ -627,6 +627,12 @@
+     mips_cp0sel_names_xlr, ARRAY_SIZE (mips_cp0sel_names_xlr),
+     mips_hwr_names_numeric },
+ 
++  { "xlp", 1, bfd_mach_mips_xlp, CPU_XLP,
++	(ISA_MIPS64R2 | INSN_XLP),
++	mips_cp0_names_mips3264r2,
++	mips_cp0sel_names_mips3264r2, ARRAY_SIZE (mips_cp0sel_names_mips3264r2),
++	mips_hwr_names_mips3264r2 },
++
+   /* This entry, mips16, is here only for ISA/processor selection; do
+      not print its name.  */
+   { "",		1, bfd_mach_mips16, CPU_MIPS16, ISA_MIPS3,
+Index: binutils-2.23.2/opcodes/mips-opc.c
+===================================================================
+--- binutils-2.23.2.orig/opcodes/mips-opc.c	2013-04-16 04:19:48.241282004 -0700
++++ binutils-2.23.2/opcodes/mips-opc.c	2013-04-16 04:19:52.773282090 -0700
+@@ -126,6 +126,7 @@
+ #define IOCTP	(INSN_OCTEONP | INSN_OCTEON2)
+ #define IOCT2	INSN_OCTEON2
+ #define XLR     INSN_XLR
++#define XLP     INSN_XLP
+ 
+ #define G1      (T3             \
+                  )
+@@ -606,6 +607,7 @@
+ {"cins",    "t,r,+p,+s",0x70000032, 0xfc00003f, WR_t|RD_s,		0,		IOCT	},
+ {"clo",     "U,s",      0x70000021, 0xfc0007ff, WR_d|WR_t|RD_s, 	0,		I32|N55 },
+ {"clz",     "U,s",      0x70000020, 0xfc0007ff, WR_d|WR_t|RD_s, 	0,		I32|N55 },
++{"crc",     "d,s,t",  0x7000001c, 0xfc0007ff, WR_d|RD_s|RD_t,   0, XLP },
+ {"ctc0",    "t,G",	0x40c00000, 0xffe007ff,	COD|RD_t|WR_CC,		0,		I1,		IOCT|IOCTP|IOCT2	},
+ {"ctc1",    "t,G",	0x44c00000, 0xffe007ff,	COD|RD_t|WR_CC|FP_S,	0,		I1	},
+ {"ctc1",    "t,S",	0x44c00000, 0xffe007ff,	COD|RD_t|WR_CC|FP_S,	0,		I1	},
+@@ -638,10 +640,11 @@
+ {"daddiu",  "t,r,j",	0x64000000, 0xfc000000, WR_t|RD_s,		0,		I3	},
+ {"daddu",   "d,v,t",	0x0000002d, 0xfc0007ff, WR_d|RD_s|RD_t,		0,		I3	},
+ {"daddu",   "t,r,I",	0,    (int) M_DADDU_I,	INSN_MACRO,		0,		I3	},
+-{"daddwc",  "d,s,t", 	0x70000038, 0xfc0007ff, WR_d|RD_s|RD_t|WR_C0|RD_C0,	0,	XLR	},
++{"daddwc",  "d,s,t", 	0x70000038, 0xfc0007ff, WR_d|RD_s|RD_t|WR_C0|RD_C0,0, XLR|XLP	},
+ {"dbreak",  "",		0x7000003f, 0xffffffff,	0,			0,		N5	},
+ {"dclo",    "U,s",      0x70000025, 0xfc0007ff, RD_s|WR_d|WR_t, 	0,		I64|N55 },
+ {"dclz",    "U,s",      0x70000024, 0xfc0007ff, RD_s|WR_d|WR_t, 	0,		I64|N55 },
++{"dcrc",    "d,s,t",  0x7000001d, 0xfc0007ff, WR_d|RD_s|RD_t, 0, XLP },
+ /* dctr and dctw are used on the r5000.  */
+ {"dctr",    "o(b)",	0xbc050000, 0xfc1f0000, RD_b,			0,		I3	},
+ {"dctw",    "o(b)",	0xbc090000, 0xfc1f0000, RD_b,			0,		I3	},
+@@ -697,6 +700,7 @@
+ {"dmfc0",   "t,G",	0x40200000, 0xffe007ff,	LCD|WR_t|RD_C0,		0,		I3	},
+ {"dmfc0",   "t,+D",	0x40200000, 0xffe007f8,	LCD|WR_t|RD_C0,		0,		I64	},
+ {"dmfc0",   "t,G,H",	0x40200000, 0xffe007f8,	LCD|WR_t|RD_C0,		0,		I64	},
++{"dmfur",   "t,d",      0x7000001e, 0xffe007ff, WR_t,  0, XLP},
+ {"dmt",     "",		0x41600bc1, 0xffffffff, TRAP,			0,		MT32	},
+ {"dmt",     "t",	0x41600bc1, 0xffe0ffff, TRAP|WR_t,		0,		MT32	},
+ {"dmtc0",   "t,G",	0x40a00000, 0xffe007ff,	COD|RD_t|WR_C0|WR_CC,	0,		I3	},
+@@ -710,6 +714,8 @@
+ /* dmtc2 is at the bottom of the table.  */
+ /* dmfc3 is at the bottom of the table.  */
+ /* dmtc3 is at the bottom of the table.  */
++{"dmtur",   "t,d",      0x7000001f, 0xffe007ff, RD_t,   0, XLP},
++{"dmul",    "d,s,t",   0x70000006, 0xfc0007ff, WR_d|RD_s|RD_t, 0, XLP},
+ {"dmul",    "d,v,t",	0x70000003, 0xfc0007ff, WR_d|RD_s|RD_t|WR_HILO,	0,		IOCT	},
+ {"dmul",    "d,v,t",	0,    (int) M_DMUL,	INSN_MACRO,		0,		I3	},
+ {"dmul",    "d,v,I",	0,    (int) M_DMUL_I,	INSN_MACRO,		0,		I3	},
+@@ -848,9 +854,9 @@
+ {"ld",      "t,o(b)",	0,    (int) M_LD_OB,	INSN_MACRO,		0,		I1	},
+ {"ld",      "t,o(b)",	0xdc000000, 0xfc000000, WR_t|RD_b,		0,		I3	},
+ {"ld",      "t,A(b)",	0,    (int) M_LD_AB,	INSN_MACRO,		0,		I1	},
+-{"ldaddw",  "t,b",	0x70000010, 0xfc00ffff,	SM|RD_t|WR_t|RD_b,	0,		XLR	},
+-{"ldaddwu", "t,b",	0x70000011, 0xfc00ffff,	SM|RD_t|WR_t|RD_b,	0,		XLR	},
+-{"ldaddd",  "t,b",	0x70000012, 0xfc00ffff,	SM|RD_t|WR_t|RD_b,	0,		XLR	},
++{"ldaddw",  "t,b",	0x70000010, 0xfc00ffff,	SM|RD_t|WR_t|RD_b,	0,		XLR|XLP	},
++{"ldaddwu", "t,b",	0x70000011, 0xfc00ffff,	SM|RD_t|WR_t|RD_b,	0,		XLR|XLP	},
++{"ldaddd",  "t,b",	0x70000012, 0xfc00ffff,	SM|RD_t|WR_t|RD_b,	0,		XLR|XLP	},
+ {"ldc1",    "T,o(b)",	0xd4000000, 0xfc000000, CLD|RD_b|WR_T|FP_D,	0,		I2	},
+ {"ldc1",    "E,o(b)",	0xd4000000, 0xfc000000, CLD|RD_b|WR_T|FP_D,	0,		I2	},
+ {"ldc1",    "T,A(b)",	0,    (int) M_LDC1_AB,	INSN_MACRO,		INSN2_M_FP_D,	I2	},
+@@ -985,7 +991,7 @@
+ {"mflo",    "d",	0x00000012, 0xffff07ff,	WR_d|RD_LO,		0,		I1	},
+ {"mflo",    "d,9",	0x00000012, 0xff9f07ff, WR_d|RD_LO,		0,		D32	},
+ {"mflhxu",  "d",	0x00000052, 0xffff07ff,	WR_d|MOD_HILO,		0,		SMT	},
+-{"mfcr",    "t,s",	0x70000018, 0xfc00ffff, WR_t,			0,		XLR 	},
++{"mfcr",    "t,s",	0x70000018, 0xfc00ffff, WR_t,			0,		XLR|XLP },
+ {"min.ob",  "X,Y,Q",	0x78000006, 0xfc20003f,	WR_D|RD_S|RD_T|FP_D,	0,		MX|SB1	},
+ {"min.ob",  "D,S,T",	0x4ac00006, 0xffe0003f,	WR_D|RD_S|RD_T,		0,		N54	},
+ {"min.ob",  "D,S,T[e]",	0x48000006, 0xfe20003f,	WR_D|RD_S|RD_T,		0,		N54	},
+@@ -1029,10 +1035,13 @@
+ /* move is at the top of the table.  */
+ {"msgn.qh", "X,Y,Q",	0x78200000, 0xfc20003f,	WR_D|RD_S|RD_T|FP_D,	0,		MX	},
+ {"msgsnd",  "t",	0,    (int) M_MSGSND,	INSN_MACRO,		0,             XLR	},
++{"msgsnds", "d,t",      0x4a000001, 0xffe007ff, WR_d|RD_t|RD_C0|WR_C0,  0, XLP  },
+ {"msgld",   "", 	0,    (int) M_MSGLD,	INSN_MACRO,		0,             XLR	},
+ {"msgld",   "t",	0,    (int) M_MSGLD_T,	INSN_MACRO,		0,             XLR	},
+-{"msgwait", "", 	0,    (int) M_MSGWAIT,	INSN_MACRO,		0,             XLR	},
+-{"msgwait", "t",	0,    (int) M_MSGWAIT_T,INSN_MACRO,		0,             XLR	},
++{"msglds",  "d,t",      0x4a000002, 0xffe007ff, WR_d|RD_t|RD_C0|WR_C0,  0, XLP  },
++{"msgwait", "", 	0,    (int) M_MSGWAIT,	INSN_MACRO,		0, 			   XLR|XLP	},
++{"msgwait", "t",	0,    (int) M_MSGWAIT_T,INSN_MACRO,		0, 			   XLR|XLP	},
++{"msgsync", "",         0x4a000004, 0xffffffff, 0,                      0, XLP  },
+ {"msub.d",  "D,R,S,T",	0x4c000029, 0xfc00003f, RD_R|RD_S|RD_T|WR_D|FP_D, 0,		I4_33	},
+ {"msub.d",	"D,S,T",	0x46200019,	0xffe0003f,	RD_S|RD_T|WR_D|FP_D,	0,	IL2E	},
+ {"msub.d",	"D,S,T",	0x72200019,	0xffe0003f,	RD_S|RD_T|WR_D|FP_D,	0,	IL2F	},
+@@ -1066,7 +1075,7 @@
+ {"mtlo",    "s",	0x00000013, 0xfc1fffff,	RD_s|WR_LO,		0,		I1	},
+ {"mtlo",    "s,7",	0x00000013, 0xfc1fe7ff, RD_s|WR_LO,		0,		D32	},
+ {"mtlhx",   "s",	0x00000053, 0xfc1fffff,	RD_s|MOD_HILO,		0,		SMT	},
+-{"mtcr",    "t,s",      0x70000019, 0xfc00ffff, RD_t,			0,		XLR	},
++{"mtcr",    "t,s",      0x70000019, 0xfc00ffff, RD_t,			0,		XLR|XLP	},
+ {"mtm0",    "s",	0x70000008, 0xfc1fffff, RD_s,			0,		IOCT	},
+ {"mtm1",    "s",	0x7000000c, 0xfc1fffff, RD_s,			0,		IOCT	},
+ {"mtm2",    "s",	0x7000000d, 0xfc1fffff, RD_s,			0,		IOCT	},
+@@ -1425,9 +1434,9 @@
+ {"suxc1",   "S,t(b)",   0x4c00000d, 0xfc0007ff, SM|RD_S|RD_t|RD_b|FP_D,	0,		I5_33|N55},
+ {"sw",      "t,o(b)",	0xac000000, 0xfc000000,	SM|RD_t|RD_b,		0,		I1	},
+ {"sw",      "t,A(b)",	0,    (int) M_SW_AB,	INSN_MACRO,		0,		I1	},
+-{"swapw",   "t,b",	0x70000014, 0xfc00ffff, SM|RD_t|WR_t|RD_b,	0,		XLR	},
+-{"swapwu",  "t,b",	0x70000015, 0xfc00ffff, SM|RD_t|WR_t|RD_b,	0,		XLR	},
+-{"swapd",   "t,b",	0x70000016, 0xfc00ffff, SM|RD_t|WR_t|RD_b,	0,		XLR	},
++{"swapw",   "t,b",	0x70000014, 0xfc00ffff, SM|RD_t|WR_t|RD_b,	0,		XLR|XLP	},
++{"swapwu",  "t,b",	0x70000015, 0xfc00ffff, SM|RD_t|WR_t|RD_b,	0,		XLR|XLP	},
++{"swapd",   "t,b",	0x70000016, 0xfc00ffff, SM|RD_t|WR_t|RD_b,	0,		XLR|XLP	},
+ {"swc0",    "E,o(b)",	0xe0000000, 0xfc000000,	SM|RD_C0|RD_b,		0,		I1,		IOCT|IOCTP|IOCT2	},
+ {"swc0",    "E,A(b)",	0,    (int) M_SWC0_AB,	INSN_MACRO,		0,		I1,		IOCT|IOCTP|IOCT2	},
+ {"swc1",    "T,o(b)",	0xe4000000, 0xfc000000,	SM|RD_T|RD_b|FP_S,	0,		I1	},
-- 
1.8.2.1

[PATCH 4/4] machine/qemumips64: Add machine definition

[Khem Raj]

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/conf/machine/qemumips64.conf | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 meta/conf/machine/qemumips64.conf

diff --git a/meta/conf/machine/qemumips64.conf b/meta/conf/machine/qemumips64.conf
new file mode 100644
index 0000000..b2c7998
--- /dev/null
+++ b/meta/conf/machine/qemumips64.conf
@@ -0,0 +1,13 @@
+#@TYPE: Machine
+#@NAME: mti-malta64-be MIPS64
+#@DESCRIPTION: mti-malta64-be
+
+require conf/machine/include/qemu.inc
+require conf/machine/include/tune-mips64.inc
+
+KERNEL_IMAGETYPE = "vmlinux"
+KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
+
+SERIAL_CONSOLE = "115200 ttyS0"
+
+MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
-- 
1.8.2.1

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

[-- Attachment #1.1: Type: text/plain, Size: 2404 bytes --]

On Mon, May 13, 2013 at 1:41 AM, Khem Raj <raj.khem@gmail.com> wrote:
> This patchset adds a new qemu based machine target for mips64 Big-endian
> linux-yocto recipe is modified to have it in tree to support qemumips64
> machine

My machine seems to build fine, but I can't seem to fully boot the
resulting image properly.

Build Configuration:
BB_VERSION        = "1.19.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "openSUSE-project-12.3"
TARGET_SYS        = "mips64-poky-linux"
MACHINE           = "qemumips64"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20130513"
TUNE_FEATURES     = "n64 bigendian fpu-hard"
TARGET_FPU        = ""
meta
meta-yocto
meta-yocto-bsp    = "master:f7afeeb75993b159bb8959e0309bc5eb3978a8fb"
meta              =
"kraj/qemumips64:b0592ab08273e17cb1511384ad189281f88c8b03"



layers:
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/trevor/devel/yocto/git/meta-poky/meta \
  /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
  /home/trevor/devel/yocto/git/meta-poky/meta-yocto-bsp \
  /home/trevor/devel/yocto/git/openembedded-core/meta \
  "
BBLAYERS_NON_REMOVABLE ?= " \
  /home/trevor/devel/yocto/git/meta-poky/meta \
  /home/trevor/devel/yocto/git/meta-poky/meta-yocto \



config:
BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"
MACHINE = "qemumips64"
DL_DIR = "/home/trevor/devel/Downloads"
SSTATE_DIR = "/home/trevor/devel/yocto/sstate-cache"
TMPDIR = "${TOPDIR}/tmp"
DISTRO ?= "poky"
PACKAGE_CLASSES ?= "package_rpm"
#SDKMACHINE ?= "i686"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
#IMAGETEST = "qemu"
#TEST_SCEN = "sanity bat sanity:boot toolchain"
#TEST_SERIALIZE = "1"
#OE_TERMINAL = "auto"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K"
CONF_VERSION = "1"



When I run:

    $ runqemu qemumips64

the virtual machine doens't appear to throw any errors (perhaps "hda:
unknown partition table"?),
however the boot simply stops without ever getting to a cmdline (see
attached image).

[-- Attachment #1.2: Type: text/html, Size: 3381 bytes --]

[-- Attachment #2: qemumips64.png --]
[-- Type: image/png, Size: 14545 bytes --]

Re: [PATCH 0/4] Add qemumips64 machine support

[Khem Raj]

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


On May 13, 2013, at 9:45 AM, Trevor Woerner <twoerner@gmail.com> wrote:

> On Mon, May 13, 2013 at 1:41 AM, Khem Raj <raj.khem@gmail.com> wrote:
> > This patchset adds a new qemu based machine target for mips64 Big-endian
> > linux-yocto recipe is modified to have it in tree to support qemumips64
> > machine
> 
> My machine seems to build fine, but I can't seem to fully boot the resulting image properly.

try  runqemu qemumips64 bootparams="root=/dev/sda"

does that boot ?

> 
> Build Configuration:
> BB_VERSION        = "1.19.0"
> BUILD_SYS         = "x86_64-linux"
> NATIVELSBSTRING   = "openSUSE-project-12.3"
> TARGET_SYS        = "mips64-poky-linux"
> MACHINE           = "qemumips64"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.3+snapshot-20130513"
> TUNE_FEATURES     = "n64 bigendian fpu-hard"
> TARGET_FPU        = ""
> meta              
> meta-yocto        
> meta-yocto-bsp    = "master:f7afeeb75993b159bb8959e0309bc5eb3978a8fb"
> meta              = "kraj/qemumips64:b0592ab08273e17cb1511384ad189281f88c8b03"
> 
> 
> 
> layers:
> # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
> # changes incompatibly
> LCONF_VERSION = "6"
> 
> BBPATH = "${TOPDIR}"
> BBFILES ?= ""
> 
> BBLAYERS ?= " \
>   /home/trevor/devel/yocto/git/meta-poky/meta \
>   /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
>   /home/trevor/devel/yocto/git/meta-poky/meta-yocto-bsp \
>   /home/trevor/devel/yocto/git/openembedded-core/meta \
>   "
> BBLAYERS_NON_REMOVABLE ?= " \
>   /home/trevor/devel/yocto/git/meta-poky/meta \
>   /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
> 
> 
> 
> config:
> BB_NUMBER_THREADS = "4"
> PARALLEL_MAKE = "-j 4"
> MACHINE = "qemumips64"
> DL_DIR = "/home/trevor/devel/Downloads"
> SSTATE_DIR = "/home/trevor/devel/yocto/sstate-cache"
> TMPDIR = "${TOPDIR}/tmp"
> DISTRO ?= "poky"
> PACKAGE_CLASSES ?= "package_rpm"
> #SDKMACHINE ?= "i686"
> EXTRA_IMAGE_FEATURES = "debug-tweaks"
> USER_CLASSES ?= "buildstats image-mklibs image-prelink"
> #IMAGETEST = "qemu"
> #TEST_SCEN = "sanity bat sanity:boot toolchain"
> #TEST_SERIALIZE = "1"
> #OE_TERMINAL = "auto"
> PATCHRESOLVE = "noop"
> BB_DISKMON_DIRS = "\
>     STOPTASKS,${TMPDIR},1G,100K \
>     STOPTASKS,${DL_DIR},1G,100K \
>     STOPTASKS,${SSTATE_DIR},1G,100K \
>     ABORT,${TMPDIR},100M,1K \
>     ABORT,${DL_DIR},100M,1K \
>     ABORT,${SSTATE_DIR},100M,1K"
> CONF_VERSION = "1"
> 
> 
> 
> When I run:
> 
>     $ runqemu qemumips64
> 
> the virtual machine doens't appear to throw any errors (perhaps "hda: unknown partition table"?),
> however the boot simply stops without ever getting to a cmdline (see attached image).
> <qemumips64.png>


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

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

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

On Mon, May 13, 2013 at 2:33 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On May 13, 2013, at 9:45 AM, Trevor Woerner <twoerner@gmail.com> wrote:
> try  runqemu qemumips64 bootparams="root=/dev/sda"
>
> does that boot ?

It gets a little further but doesn't succeed. I have now tried booting a
number of
times using various combinations of "serial" and "bootparams". Currently I'm
using:

    $ runqemu qemumips64 serial bootparams="root=/dev/sda probe_mask=0x3f"

How far the boot gets seems random, but sometimes I'll get the following
panic:


[...snip...]
Creating 3 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000100000 : "YAMON"
0x000000100000-0x0000003e0000 : "User FS"
0x0000003e0000-0x000000400000 : "Board Config"
pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
pcnet32: PCnet/PCI II 79C970A at 0x1020, 52:54:00:12:34:56 assigned IRQ 10
pcnet32: eth0: registered as PCnet/PCI II 79C970A
pcnet32: 1 cards_found
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mousedev: PS/2 mouse device common for all mice
usbcore: registered new interface driver wacom
input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
input: ImExPS/2 Generic Explorer Mouse as
/devices/platform/i8042/serio1/input/input1
md: raid10 personality registered for level 10
md: multipath personality registered for level -4
md: faulty personality registered for level -5
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised:
dm-devel@redhat.com
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
Reserved instruction in kernel code[#1]:
Cpu 0
$ 0   : 0000000000000000 ffffffff80968790 0000000000000001 0000000000000000
$ 4   : 0000000000000001 ffffffff80850000 ffffffffffffffff ffffffffffffffff
$ 8   : 0000000000000000 9000000010000010 0000000000000000 0000000000000000
$12   : 0000000000000000 0000000000000488 000000000000000f 0000000000000007
$16   : 0000000000000006 0000000000000001 ffffffff808f0000 0000000000000000
$20   : ffffffff809b0000 ffffffff808e0000 000000000000008b ffffffff809b0000
$24   : 0000000000000000 0000000000000000
$28   : 9800000007c80000 9800000007c83cd0 9800000007c83cd0 ffffffff80968790
Hi    : 0000000000000000
Lo    : 0000000000000000
epc   : ffffffff80635910 reset_counters+0x60/0x90
    Not tainted
ra    : ffffffff80968790 mipsxx_init+0x1d4/0x2d8
Status: 1400a4e2    KX SX UX KERNEL EXL
Cause : 00800028
PrId  : 000182a0 (MIPS 20Kc)
Modules linked in:
Process swapper (pid: 1, threadinfo=9800000007c80000,
task=9800000007c38000, tls=0000000000000000)
Stack : 9800000007c83ce0 9800000007c83ce0 000000000000008b ffffffff809b0000
        9800000007c83d00 0000000000000006 ffffffff80a778a0 ffffffff80936930
        9800000007c83d20 ffffffff80968528 ffffffff80930000 0000000000000000
        ffffffffffffffff 0000000000000006 ffffffff80a70000 ffffffff80a70000
        9800000007c83d60 ffffffff809683ec 9800000007c83d70 0000000000000006
        ffffffff809b0000 ffffffff809683bc 9800000007c83d90 ffffffff80100530
        ffffffff809b0000 0000000000000006 0000000000000030 ffffffff809b0000
        ffffffff809b1578 ffffffff8097d960 9800000007c83dd0 ffffffff80948c98
        0000000000000000 0000000000000000 0000000000000000 0000000000000000
        0000000000000000 0000000000000000 0000000000000000 0000000000000000
        ...
Call Trace:
[<ffffffff80635910>] reset_counters+0x60/0x90
[<ffffffff80968790>] mipsxx_init+0x1d4/0x2d8
[<ffffffff80968528>] oprofile_arch_init+0x84/0x118
[<ffffffff809683ec>] oprofile_init+0x30/0xb8
[<ffffffff80100530>] do_one_initcall+0x120/0x1a0
[<ffffffff80948c98>] kernel_init+0x194/0x258
[<ffffffff80103ffc>] kernel_thread_helper+0x24/0x30


Code: 4080c802  4080c803  4080c800 <4080c801> 03c0e82d  dfbe0008  03e00008
 67bd0010  00000000
---[ end trace 340dd7de1cdea432 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

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

Re: [PATCH 0/4] Add qemumips64 machine support

[Khem Raj]

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


On May 13, 2013, at 11:53 AM, Trevor Woerner <twoerner@gmail.com> wrote:

> Process swapper (pid: 1, threadinfo=9800000007c80000, task=9800000007c38000, tls=0000000000000000)
> Stack : 9800000007c83ce0 9800000007c83ce0 000000000000008b ffffffff809b0000
>         9800000007c83d00 0000000000000006 ffffffff80a778a0 ffffffff80936930
>         9800000007c83d20 ffffffff80968528 ffffffff80930000 0000000000000000
>         ffffffffffffffff 0000000000000006 ffffffff80a70000 ffffffff80a70000
>         9800000007c83d60 ffffffff809683ec 9800000007c83d70 0000000000000006
>         ffffffff809b0000 ffffffff809683bc 9800000007c83d90 ffffffff80100530
>         ffffffff809b0000 0000000000000006 0000000000000030 ffffffff809b0000
>         ffffffff809b1578 ffffffff8097d960 9800000007c83dd0 ffffffff80948c98
>         0000000000000000 0000000000000000 0000000000000000 0000000000000000
>         0000000000000000 0000000000000000 0000000000000000 0000000000000000
>         ...
> Call Trace:
> [<ffffffff80635910>] reset_counters+0x60/0x90
> [<ffffffff80968790>] mipsxx_init+0x1d4/0x2d8
> [<ffffffff80968528>] oprofile_arch_init+0x84/0x118
> [<ffffffff809683ec>] oprofile_init+0x30/0xb8
> [<ffffffff80100530>] do_one_initcall+0x120/0x1a0
> [<ffffffff80948c98>] kernel_init+0x194/0x258
> [<ffffffff80103ffc>] kernel_thread_helper+0x24/0x30
> 
> 


you must be using systemd. I am seeing same failure with systemd but only when my build host is archlinux


> Code: 4080c802  4080c803  4080c800 <4080c801> 03c0e82d  dfbe0008  03e00008  67bd0010  00000000 
> ---[ end trace 340dd7de1cdea432 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b


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

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

On Mon, May 13, 2013 at 3:02 PM, Khem Raj <raj.khem@gmail.com> wrote:
> you must be using systemd. I am seeing same failure with systemd but only when my build host is archlinux

Are you referring to the build host or target? My build host is
openSuSE 12.3 which does use systemd. For the target I'm just building
core-image-minimal which, as is my understanding, uses sysvinit by
default (i.e. I'm not doing anything explicit (that I'm aware) to
request systemd in my target).

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

On Mon, May 13, 2013 at 2:53 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> On Mon, May 13, 2013 at 2:33 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On May 13, 2013, at 9:45 AM, Trevor Woerner <twoerner@gmail.com> wrote:
>> try  runqemu qemumips64 bootparams="root=/dev/sda"
>>
>> does that boot ?
>
> It gets a little further but doesn't succeed. I have now tried booting a
> number of
> times using various combinations of "serial" and "bootparams". Currently I'm
> using:
>
>     $ runqemu qemumips64 serial bootparams="root=/dev/sda probe_mask=0x3f"
>
> How far the boot gets seems random, but sometimes I'll get the following
> panic:
>
>
> [...snip...]
> Creating 3 MTD partitions on "physmap-flash.0":
> 0x000000000000-0x000000100000 : "YAMON"
> 0x000000100000-0x0000003e0000 : "User FS"
> 0x0000003e0000-0x000000400000 : "Board Config"
> pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
> PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
> pcnet32: PCnet/PCI II 79C970A at 0x1020, 52:54:00:12:34:56 assigned IRQ 10
> pcnet32: eth0: registered as PCnet/PCI II 79C970A
> pcnet32: 1 cards_found
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> serio: i8042 KBD port at 0x60,0x64 irq 1
> serio: i8042 AUX port at 0x60,0x64 irq 12
> mousedev: PS/2 mouse device common for all mice
> usbcore: registered new interface driver wacom
> input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
> md: linear personality registered for level -1
> md: raid0 personality registered for level 0
> md: raid1 personality registered for level 1
> input: ImExPS/2 Generic Explorer Mouse as
> /devices/platform/i8042/serio1/input/input1
> md: raid10 personality registered for level 10
> md: multipath personality registered for level -4
> md: faulty personality registered for level -5
> device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised:
> dm-devel@redhat.com
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> Reserved instruction in kernel code[#1]:
> Cpu 0
> $ 0   : 0000000000000000 ffffffff80968790 0000000000000001 0000000000000000
> $ 4   : 0000000000000001 ffffffff80850000 ffffffffffffffff ffffffffffffffff
> $ 8   : 0000000000000000 9000000010000010 0000000000000000 0000000000000000
> $12   : 0000000000000000 0000000000000488 000000000000000f 0000000000000007
> $16   : 0000000000000006 0000000000000001 ffffffff808f0000 0000000000000000
> $20   : ffffffff809b0000 ffffffff808e0000 000000000000008b ffffffff809b0000
> $24   : 0000000000000000 0000000000000000
> $28   : 9800000007c80000 9800000007c83cd0 9800000007c83cd0 ffffffff80968790
> Hi    : 0000000000000000
> Lo    : 0000000000000000
> epc   : ffffffff80635910 reset_counters+0x60/0x90
>     Not tainted
> ra    : ffffffff80968790 mipsxx_init+0x1d4/0x2d8
> Status: 1400a4e2    KX SX UX KERNEL EXL
> Cause : 00800028
> PrId  : 000182a0 (MIPS 20Kc)
> Modules linked in:
> Process swapper (pid: 1, threadinfo=9800000007c80000, task=9800000007c38000,
> tls=0000000000000000)
> Stack : 9800000007c83ce0 9800000007c83ce0 000000000000008b ffffffff809b0000
>         9800000007c83d00 0000000000000006 ffffffff80a778a0 ffffffff80936930
>         9800000007c83d20 ffffffff80968528 ffffffff80930000 0000000000000000
>         ffffffffffffffff 0000000000000006 ffffffff80a70000 ffffffff80a70000
>         9800000007c83d60 ffffffff809683ec 9800000007c83d70 0000000000000006
>         ffffffff809b0000 ffffffff809683bc 9800000007c83d90 ffffffff80100530
>         ffffffff809b0000 0000000000000006 0000000000000030 ffffffff809b0000
>         ffffffff809b1578 ffffffff8097d960 9800000007c83dd0 ffffffff80948c98
>         0000000000000000 0000000000000000 0000000000000000 0000000000000000
>         0000000000000000 0000000000000000 0000000000000000 0000000000000000
>         ...
> Call Trace:
> [<ffffffff80635910>] reset_counters+0x60/0x90
> [<ffffffff80968790>] mipsxx_init+0x1d4/0x2d8
> [<ffffffff80968528>] oprofile_arch_init+0x84/0x118
> [<ffffffff809683ec>] oprofile_init+0x30/0xb8
> [<ffffffff80100530>] do_one_initcall+0x120/0x1a0
> [<ffffffff80948c98>] kernel_init+0x194/0x258
> [<ffffffff80103ffc>] kernel_thread_helper+0x24/0x30
>
>
> Code: 4080c802  4080c803  4080c800 <4080c801> 03c0e82d  dfbe0008  03e00008
> 67bd0010  00000000
> ---[ end trace 340dd7de1cdea432 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

This has been fixed multiple times. Looks like the wrong kernel SRCREV was
used.

qemumips definitely boots here, otherwise, we wouldn't have added the
compatibility
and sent the request.

I'm doing a systemd build at the moment and will have more info tomorrow.

Bruce

>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

There's something else that's going on that is strange. When I do a
"qemumips" build from the master repositories and run it, the
qemu-system-mips that is used is the one built as part of OE (i.e. the
one from the build sysroot). But when I build and run the "qemumips64"
image using this branch, the runqemu script is using my computer's
native qemu-system-mips64.

Did I configure something incorrectly?

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Trevor Woerner wrote:

> There's something else that's going on that is strange. When I do a
> "qemumips" build from the master repositories and run it, the
> qemu-system-mips that is used is the one built as part of OE (i.e.
> the one from the build sysroot). But when I build and run the
> "qemumips64" image using this branch, the runqemu script is using my
> computer's native qemu-system-mips64.

  having unwisely wandered into this MIPS64 minefield a couple weeks
back, i might as well see if i can get a build.  in short:

* switch to kraj/qemumips64 branch of openembedded-core-contrib
* add that as another layer along with oe-core
* MACHINE = "qemumips64"
* bitbake a core-image-minimal

  is there anything critical i'm forgetting? what's the safest simple
image to try to build?  fetching is now underway ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

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

On Mon, May 13, 2013 at 3:38 PM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
>   having unwisely wandered into this MIPS64 minefield a couple weeks
> back, i might as well see if i can get a build.  in short:
>
> * switch to kraj/qemumips64 branch of openembedded-core-contrib
> * add that as another layer along with oe-core


I believe you only need to add this oe-core/meta layer once. My
bblayers.conf contains:

     BBLAYERS ?= " \
          /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
          /home/trevor/devel/yocto/git/meta-poky/meta-yocto-bsp \
          /home/trevor/devel/yocto/git/openembedded-core/meta \
          "
     BBLAYERS_NON_REMOVABLE ?= " \
          /home/trevor/devel/yocto/git/openembedded-core/meta \
          /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
          "


> * MACHINE = "qemumips64"
> * bitbake a core-image-minimal
>
>   is there anything critical i'm forgetting? what's the safest simple
> image to try to build?  fetching is now underway ...

That's exactly what I tried.

I also removed the (default) poky/meta layer since (as I
understand it) the openembedded-core/meta layer replaces it.

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

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1690 bytes --]

On Mon, 13 May 2013, Trevor Woerner wrote:

> On Mon, May 13, 2013 at 3:38 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >   having unwisely wandered into this MIPS64 minefield a couple weeks
> > back, i might as well see if i can get a build.  in short:
> >
> > * switch to kraj/qemumips64 branch of openembedded-core-contrib
> > * add that as another layer along with oe-core
>
>
> I believe you only need to add this oe-core/meta layer once. My bblayers.conf contains:
>
>      BBLAYERS ?= " \
>           /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
>           /home/trevor/devel/yocto/git/meta-poky/meta-yocto-bsp \
>           /home/trevor/devel/yocto/git/openembedded-core/meta \
>           "
>      BBLAYERS_NON_REMOVABLE ?= " \
>           /home/trevor/devel/yocto/git/openembedded-core/meta \
>           /home/trevor/devel/yocto/git/meta-poky/meta-yocto \

  i have just:

BBLAYERS ?= " \
  /home/rpjday/oe/dist/layers/oe-core/meta \
  /home/rpjday/oe/dist/layers/openembedded-core-contrib/meta \
  "

BBLAYERS_NON_REMOVABLE ?= " \
  /home/rpjday/oe/dist/layers/oe-core/meta \
  "


and i'm just starting the build of core-image-minimal, all the
fetching worked fine.  i'll know shortly ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1767 bytes --]

On Mon, 13 May 2013, Trevor Woerner wrote:

> On Mon, May 13, 2013 at 3:38 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >   having unwisely wandered into this MIPS64 minefield a couple weeks
> > back, i might as well see if i can get a build.  in short:
> >
> > * switch to kraj/qemumips64 branch of openembedded-core-contrib
> > * add that as another layer along with oe-core
>
>
> I believe you only need to add this oe-core/meta layer once. My bblayers.conf contains:
>
>      BBLAYERS ?= " \
>           /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
>           /home/trevor/devel/yocto/git/meta-poky/meta-yocto-bsp \
>           /home/trevor/devel/yocto/git/openembedded-core/meta \
>           "
>      BBLAYERS_NON_REMOVABLE ?= " \
>           /home/trevor/devel/yocto/git/openembedded-core/meta \
>           /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
>           "
>
>
> > * MACHINE = "qemumips64"
> > * bitbake a core-image-minimal
> >
> >   is there anything critical i'm forgetting? what's the safest simple
> > image to try to build?  fetching is now underway ...
>
> That's exactly what I tried.

  so, once the build finishes, should i be expecting to run anything
other than (if memory serves):

$ runqemu qemumips64

???  any known issues or surprises?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

On Mon, May 13, 2013 at 3:59 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Mon, 13 May 2013, Trevor Woerner wrote:
>
>> On Mon, May 13, 2013 at 3:38 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>> >   having unwisely wandered into this MIPS64 minefield a couple weeks
>> > back, i might as well see if i can get a build.  in short:
>> >
>> > * switch to kraj/qemumips64 branch of openembedded-core-contrib
>> > * add that as another layer along with oe-core
>>
>>
>> I believe you only need to add this oe-core/meta layer once. My bblayers.conf contains:
>>
>>      BBLAYERS ?= " \
>>           /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
>>           /home/trevor/devel/yocto/git/meta-poky/meta-yocto-bsp \
>>           /home/trevor/devel/yocto/git/openembedded-core/meta \
>>           "
>>      BBLAYERS_NON_REMOVABLE ?= " \
>>           /home/trevor/devel/yocto/git/openembedded-core/meta \
>>           /home/trevor/devel/yocto/git/meta-poky/meta-yocto \
>>           "
>>
>>
>> > * MACHINE = "qemumips64"
>> > * bitbake a core-image-minimal
>> >
>> >   is there anything critical i'm forgetting? what's the safest simple
>> > image to try to build?  fetching is now underway ...
>>
>> That's exactly what I tried.
>
>   so, once the build finishes, should i be expecting to run anything
> other than (if memory serves):
>
> $ runqemu qemumips64
>
> ???  any known issues or surprises?

That's all you need, here's my output:

root@qemumips64:~# uname -a
Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Mon May 13 15:47:58
EDT 2013 mips64 GNU/Linux

That's built from scratch on Yocto master. So clearly there's something strange
going on in the failing configs.

Bruce

>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Bruce Ashfield wrote:

> On Mon, May 13, 2013 at 3:59 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> >   so, once the build finishes, should i be expecting to run anything
> > other than (if memory serves):
> >
> > $ runqemu qemumips64
> >
> > ???  any known issues or surprises?
>
> That's all you need, here's my output:
>
> root@qemumips64:~# uname -a
> Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Mon May 13 15:47:58
> EDT 2013 mips64 GNU/Linux
>
> That's built from scratch on Yocto master. So clearly there's
> something strange going on in the failing configs.

  build finished, and the run hung after printing:

"mousedev: PS/2 mouse device common for all mice"

so i killed it and re-executed ... oh, this is not good, kernel panic,
call trace, etc.  one more time ... same result, kernel panic, call
trace.  one more time ... hung after "pcnet32: 1 cards_found".

  so this is not working out for me.  thoughts?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 900 bytes --]

On Mon, 13 May 2013, Bruce Ashfield wrote:

> That's all you need, here's my output:
>
> root@qemumips64:~# uname -a
> Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Mon May 13 15:47:58
> EDT 2013 mips64 GNU/Linux
>
> That's built from scratch on Yocto master. So clearly there's
> something strange going on in the failing configs.

   i attached a screenshot of the last part of the boot which includes
the call trace, if that's of any interest.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

[-- Attachment #2: Type: IMAGE/png, Size: 16420 bytes --]

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

On Mon, May 13, 2013 at 4:51 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Mon, 13 May 2013, Bruce Ashfield wrote:
>
>> That's all you need, here's my output:
>>
>> root@qemumips64:~# uname -a
>> Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Mon May 13 15:47:58
>> EDT 2013 mips64 GNU/Linux
>>
>> That's built from scratch on Yocto master. So clearly there's
>> something strange going on in the failing configs.
>
>    i attached a screenshot of the last part of the boot which includes
> the call trace, if that's of any interest.

That's the same trace the Trevor saw, and that Khem and I have seen (and fixed)
a few times.

I'm betting everyone is using a different SRCREV for the kernel that I am, since
I've built and booted this multiple times.

Can you dump your board and meta top commits to the thread ?

Bruce

>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Bruce Ashfield wrote:

> On Mon, May 13, 2013 at 4:51 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > On Mon, 13 May 2013, Bruce Ashfield wrote:
> >
> >> That's all you need, here's my output:
> >>
> >> root@qemumips64:~# uname -a
> >> Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Mon May 13 15:47:58
> >> EDT 2013 mips64 GNU/Linux
> >>
> >> That's built from scratch on Yocto master. So clearly there's
> >> something strange going on in the failing configs.
> >
> >    i attached a screenshot of the last part of the boot which includes
> > the call trace, if that's of any interest.
>
> That's the same trace the Trevor saw, and that Khem and I have seen (and fixed)
> a few times.
>
> I'm betting everyone is using a different SRCREV for the kernel that
> I am, since I've built and booted this multiple times.
>
> Can you dump your board and meta top commits to the thread ?

  i'm using only the two layers.  here's oe-core:

commit cf5e40598ae9a83f22cabedc7b72000beb62703c
Author: Peter Seebach <peter.seebach@windriver.com>
Date:   Thu May 17 23:45:58 2012 +0000

    sanity.bbclass: Attach the missing value to a format string.

    The tuning changes to sanity.bbclass were almost right, but one of
    the messages had a %s with no % operator.

    Signed-off-by: Peter Seebach <peter.seebach@windriver.com>

and here's openembedded-core-contrib (the top few) on branch
kraj/qemumips64:

commit b0592ab08273e17cb1511384ad189281f88c8b03
Author: Khem Raj <raj.khem@gmail.com>
Date:   Tue Mar 26 18:01:56 2013 -0700

    machine/qemumips64: Add machine definition

    Signed-off-by: Khem Raj <raj.khem@gmail.com>

commit 74e3eb74194baade027edc3f23985aa72ce055eb
Author: Khem Raj <raj.khem@gmail.com>
Date:   Tue Apr 16 19:17:03 2013 -0700

    binutils: Add broadcom XLP support

    Signed-off-by: Khem Raj <raj.khem@gmail.com>

commit e4d9bfb01c5657a7f30597d83829375520d64627
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date:   Wed May 8 08:37:48 2013 -0700

    linux-yocto: add qemumips64 compatibility

    The 3.8 and linux-yocto-dev kernel trees carry qemumips64 support. Adding
    the board to the compatibility directly in the recipes is the first step
    to adding mips64 support to the broader set of packages.

    Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
    Signed-off-by: Khem Raj <raj.khem@gmail.com>


am i just not up to date somehow?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

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

Bruce, you said you were building 3.8.11, but I'm not. When I run my image,
my banner includes:

Linux version 3.4.43-yocto-standard (trevor@zzz) (gcc version 4.7.2 (GCC) )
#1 PREEMPT Mon May 13 12:14:42 EDT 2013

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

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Trevor Woerner wrote:

> Bruce, you said you were building 3.8.11, but I'm not. When I run my image, my banner includes:
> Linux version 3.4.43-yocto-standard (trevor@zzz) (gcc version 4.7.2 (GCC) ) #1 PREEMPT Mon May 13 12:14:42 EDT 2013

  from my build:

$ bitbake -s | grep linux
linux-dummy                                           :1.0-r1
linux-firmware
1:0.0+gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r0
linux-libc-headers                                    :3.8-r0
linux-yocto
:3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_dd089cb5ba37ea14e8f90a884bf2a5be64ed817d-r4.1
linuxdoc-tools-native                              :0.9.66-r3
nativesdk-linux-libc-headers                          :3.8-r0
nativesdk-ocf-linux                            :20120127-r3.0
ocf-linux                                      :20120127-r3.0
ocf-linux-native                               :20120127-r3.0
syslinux-native                                      :4.03-r9
util-linux                                         :2.22.2-r3
util-linux-native                                  :2.22.2-r3
$

  so it sure looks like i'm getting 3.8.11.  should i be trying to
build something other than a core-image-minimal?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

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

I'm building core-image-minimal, I assume that's what everyone else is
doing.

When I run the "bitbake -s" as Robert is, I get the following:

$ bitbake -s | grep linux
linux-dummy                                           :1.0-r1

linux-firmware
 1:0.0+gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r0

linux-libc-headers                                    :3.8-r0

linux-libc-headers-yocto
 :3.4+git-AUTOINC+a1cdb60720c452c3965eaec3ec2cd10f06261cc5_a1cdb60720c452c3965eaec3ec2cd10f06261cc5-r6

linux-yocto
:3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_dd089cb5ba37ea14e8f90a884bf2a5be64ed817d-r4.1
:3.4.43+gitAUTOINC+1bab5bd090948b4cc4c4ed57c834603a3cf9f235_fff57da7886cf5e99c07adf6649610cb1cd89330-r4.4
linuxdoc-tools-native                              :0.9.66-r3

nativesdk-linux-libc-headers                          :3.8-r0

nativesdk-linux-libc-headers-yocto
 :3.4+git-AUTOINC+a1cdb60720c452c3965eaec3ec2cd10f06261cc5_a1cdb60720c452c3965eaec3ec2cd10f06261cc5-r6

nativesdk-ocf-linux                            :20120127-r3.0

ocf-linux                                      :20120127-r3.0

ocf-linux-native                               :20120127-r3.0

syslinux-native                                      :4.03-r9

util-linux                                         :2.22.2-r3

util-linux-native                                  :2.22.2-r3


As you can see, I do have a 3.8.11 in my list too, but when I run "runqemu
qemumips64" my banner (from the VM) says my image is running 3.4.43.

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

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1478 bytes --]

On Mon, 13 May 2013, Trevor Woerner wrote:

> I'm building core-image-minimal, I assume that's what everyone else is doing.
> When I run the "bitbake -s" as Robert is, I get the following:
>
> $ bitbake -s | grep linux
> linux-dummy                                           :1.0-r1                          
> linux-firmware                      1:0.0+gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r0                    
>      
> linux-libc-headers                                    :3.8-r0                          
> linux-libc-headers-yocto          
>  :3.4+git-AUTOINC+a1cdb60720c452c3965eaec3ec2cd10f06261cc5_a1cdb60720c452c3965eaec3ec2cd10f06261cc5-r6              
>            
> linux-yocto                        
> :3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_dd089cb5ba37ea14e8f90a884bf2a5be64ed817d-r4.1
> :3.4.43+gitAUTOINC+1bab5bd090948b4cc4c4ed57c834603a3cf9f235_fff57da7886cf5e99c07adf6649610cb1cd89330-r4.4

 i'm confused ... why would you be building two versions of the
kernel?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

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

On Mon, May 13, 2013 at 5:30 PM, Robert P. J. Day <rpjday@crashcourse.ca>wrote:

> On Mon, 13 May 2013, Trevor Woerner wrote:
>
> > I'm building core-image-minimal, I assume that's what everyone else is
> doing.
> > When I run the "bitbake -s" as Robert is, I get the following:
> >
> > $ bitbake -s | grep linux
> > linux-dummy                                           :1.0-r1
>
> > linux-firmware
>  1:0.0+gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r0
>
> >
> > linux-libc-headers                                    :3.8-r0
>
> > linux-libc-headers-yocto
> >
>  :3.4+git-AUTOINC+a1cdb60720c452c3965eaec3ec2cd10f06261cc5_a1cdb60720c452c3965eaec3ec2cd10f06261cc5-r6
>
> >
> > linux-yocto
> >
> :3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_dd089cb5ba37ea14e8f90a884bf2a5be64ed817d-r4.1
> >
> :3.4.43+gitAUTOINC+1bab5bd090948b4cc4c4ed57c834603a3cf9f235_fff57da7886cf5e99c07adf6649610cb1cd89330-r4.4
>
>  i'm confused ... why would you be building two versions of the
> kernel?
>

I'm not explicitly trying to build two versions of the kernel :-)

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

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1922 bytes --]

On Mon, 13 May 2013, Trevor Woerner wrote:

> On Mon, May 13, 2013 at 5:30 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       On Mon, 13 May 2013, Trevor Woerner wrote:
>
> > I'm building core-image-minimal, I assume that's what everyone else is doing.
> > When I run the "bitbake -s" as Robert is, I get the following:
> >
> > $ bitbake -s | grep linux
> > linux-dummy                                           :1.0-r1                          
> > linux-firmware                      1:0.0+gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r0      
>              
> >      
> > linux-libc-headers                                    :3.8-r0                          
> > linux-libc-headers-yocto          
> >  :3.4+git-AUTOINC+a1cdb60720c452c3965eaec3ec2cd10f06261cc5_a1cdb60720c452c3965eaec3ec2cd10f06261cc5-r6
>              
> >            
> > linux-yocto                        
> >
> :3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_dd089cb5ba37ea14e8f90a884bf2a5be64ed817d-r4.1
> >
> :3.4.43+gitAUTOINC+1bab5bd090948b4cc4c4ed57c834603a3cf9f235_fff57da7886cf5e99c07adf6649610cb1cd89330-r4.4
>
>  i'm confused ... why would you be building two versions of the
> kernel?
>
> I'm not explicitly trying to build two versions of the kernel :-)

  i know, bad choice of wording. :-) anyway, i'm open to suggestions
as to what to try next.  how can we be getting such differences when
trying to build the same thing?  how odd ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

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

Okay, I'm going to start over :-)

I have a layer, meta-poky, which is:
$ git remote -v
contrib git://git.pokylinux.org/poky-contrib (fetch)
contrib git://git.pokylinux.org/poky-contrib (push)
origin  git://git.yoctoproject.org/poky (fetch)
origin  git://git.yoctoproject.org/poky (push)

Currently I have the master branch checked out from
origin: f7afeeb75993b159bb8959e0309bc5eb3978a8fb


I also have openembedded-core, which is:
$ git remote -v
contrib git://git.openembedded.org/openembedded-core-contrib (fetch)
contrib git://git.openembedded.org/openembedded-core-contrib (push)
origin  git://git.openembedded.org/openembedded-core (fetch)
origin  git://git.openembedded.org/openembedded-core (push)

Currently I have Khem's branch checked
out: b0592ab08273e17cb1511384ad189281f88c8b03


For my layers I'm only using:
meta-poky/meta-yocto (which I need so I can build an image with poky)
openembedded-core/meta (which I need for Khem's work, including the
qemumips64 MACHINE)


My understanding is that the things in openembedded-core/meta are meant to
replace
the corresponding directories from meta-poky/meta, which is why I'm not
including
meta-poky as a layer.

I am very confused by Robert's ability to build successfully with only the
following two layers:

BBLAYERS ?= " \
  /home/rpjday/oe/dist/layers/oe-core/meta \
  /home/rpjday/oe/dist/layers/openembedded-core-contrib/meta \
  "

Since, as far as I can tell, neither of them includes what is required to
build a poky image.
But I'll be trying out what Robert has done to see if I can get what he's
getting :-)
Maybe I'm still confused over all this meta-openembedded/openembedded-core
stuff.

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

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

On Mon, May 13, 2013 at 5:30 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>  i'm confused ... why would you be building two versions of the
> kernel?

Maybe I just need to provide a PREFERRED_PROVIDER_virtual/kernel?

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Bruce Ashfield wrote:

> On Mon, May 13, 2013 at 4:51 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > On Mon, 13 May 2013, Bruce Ashfield wrote:
> >
> >> That's all you need, here's my output:
> >>
> >> root@qemumips64:~# uname -a
> >> Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Mon May 13 15:47:58
> >> EDT 2013 mips64 GNU/Linux
> >>
> >> That's built from scratch on Yocto master. So clearly there's
> >> something strange going on in the failing configs.
> >
> >    i attached a screenshot of the last part of the boot which includes
> > the call trace, if that's of any interest.
>
> That's the same trace the Trevor saw, and that Khem and I have seen (and fixed)
> a few times.
>
> I'm betting everyone is using a different SRCREV for the kernel that I am, since
> I've built and booted this multiple times.
>
> Can you dump your board and meta top commits to the thread ?

$ bitbake core-image-minimal
Loading cache: 100%
|#############################################################################| ETA:  00:00:00
Loaded 2255 entries from dependency cache.

Build Configuration:
BB_VERSION        = "1.19.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS        = "mips64-oe-linux"
MACHINE           = "qemumips64"
DISTRO_VERSION    = "oe-core.0"
TUNE_FEATURES     = "n64 bigendian fpu-hard"
TARGET_FPU        = ""
meta              = "master:cf5e40598ae9a83f22cabedc7b72000beb62703c"
meta              = "kraj/qemumips64:b0592ab08273e17cb1511384ad189281f88c8b03"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 1608 tasks of which 1608 didn't need to
be rerun and all succeeded.
$

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Bruce Ashfield wrote:

> On Mon, May 13, 2013 at 4:51 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > On Mon, 13 May 2013, Bruce Ashfield wrote:
> >
> >> That's all you need, here's my output:
> >>
> >> root@qemumips64:~# uname -a
> >> Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Mon May 13 15:47:58
> >> EDT 2013 mips64 GNU/Linux
> >>
> >> That's built from scratch on Yocto master. So clearly there's
> >> something strange going on in the failing configs.
> >
> >    i attached a screenshot of the last part of the boot which includes
> > the call trace, if that's of any interest.
>
> That's the same trace the Trevor saw, and that Khem and I have seen (and fixed)
> a few times.
>
> I'm betting everyone is using a different SRCREV for the kernel that I am, since
> I've built and booted this multiple times.
>
> Can you dump your board and meta top commits to the thread ?

  for posterity, i'm wikifying my config and build attempt:

http://www.crashcourse.ca/wiki/index.php/Adding_MIPS64_QEMU_machine

so i don't have to repeat stuff.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Khem Raj]

Robert and Trevor

so whats your cross-gcc version ?
should be in tmpdir under

sysroots/x86_64-linux/usr/bin/mips64-angstrom-linux/mips64-angstrom-linux-gcc -v

On May 13, 2013, at 3:07 PM, "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:

> On Mon, 13 May 2013, Bruce Ashfield wrote:
> 
>> On Mon, May 13, 2013 at 4:51 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>>> On Mon, 13 May 2013, Bruce Ashfield wrote:
>>> 
>>>> That's all you need, here's my output:
>>>> 
>>>> root@qemumips64:~# uname -a
>>>> Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Mon May 13 15:47:58
>>>> EDT 2013 mips64 GNU/Linux
>>>> 
>>>> That's built from scratch on Yocto master. So clearly there's
>>>> something strange going on in the failing configs.
>>> 
>>>   i attached a screenshot of the last part of the boot which includes
>>> the call trace, if that's of any interest.
>> 
>> That's the same trace the Trevor saw, and that Khem and I have seen (and fixed)
>> a few times.
>> 
>> I'm betting everyone is using a different SRCREV for the kernel that I am, since
>> I've built and booted this multiple times.
>> 
>> Can you dump your board and meta top commits to the thread ?
> 
>  for posterity, i'm wikifying my config and build attempt:
> 
> http://www.crashcourse.ca/wiki/index.php/Adding_MIPS64_QEMU_machine
> 
> so i don't have to repeat stuff.
> 
> rday
> 
> -- 
> 
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                        http://crashcourse.ca
> 
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Khem Raj wrote:

> Robert and Trevor
>
> so whats your cross-gcc version ?
> should be in tmpdir under
>
> sysroots/x86_64-linux/usr/bin/mips64-angstrom-linux/mips64-angstrom-linux-gcc -v

  in the middle of a fresh build just to play it safe, i should know
in a few minutes.  so is my wiki description reasonable?

http://www.crashcourse.ca/wiki/index.php/Adding_MIPS64_QEMU_machine

AFAICT, i need only the two layers i list there, yes?  and my build
configuration looks sane, doesn't it?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Khem Raj wrote:

> Robert and Trevor
>
> so whats your cross-gcc version ?
> should be in tmpdir under
>
> sysroots/x86_64-linux/usr/bin/mips64-angstrom-linux/mips64-angstrom-linux-gcc -v

  my build is still going but i don't have a mips64-angstrom-linux
directory, i have a mips64-oe-linux directory, inside of which i have:

$ ./mips64-oe-linux-gcc -v
Using built-in specs.
COLLECT_GCC=./mips64-oe-linux-gcc
COLLECT_LTO_WRAPPER=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/mips64-oe-linux/gcc/mips64-oe-linux/4.7.2/lto-wrapper
Target: mips64-oe-linux
Configured with:
/home/rpjday/oe/builds/mips64/tmp-eglibc/work-shared/gcc-4.7.2-r20/gcc-4.7.2/configure
--build=x86_64-linux --host=x86_64-linux --target=mips64-oe-linux
--prefix=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr
--exec_prefix=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr
--bindir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/bin/mips64-oe-linux
--sbindir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/bin/mips64-oe-linux
--libexecdir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/mips64-oe-linux
--datadir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/share
--sysconfdir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/etc
--sharedstatedir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/com
--localstatedir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/var
--libdir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/lib/mips64-oe-linux
--includedir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/include
--oldincludedir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/include
--infodir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/share/info
--mandir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux
--with-gnu-ld --enable-shared --enable-languages=c,c++
--enable-threads=posix --disable-multilib --enable-c99
--enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=mips64-oe-linux- --without-local-prefix
--enable-target-optspace --enable-lto --enable-libssp
--disable-bootstrap --disable-libmudflap --with-system-zlib
--with-linker-hash-style=sysv --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--with-gxx-include-dir=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/qemumips64/usr/include/c++
--with-sysroot=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/qemumips64
--with-build-sysroot=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/qemumips64
--enable-poison-system-directories --disable-libunwind-exceptions
--with-mpfr=/home/rpjday/oe/builds/mips64/tmp-eglibc/sysroots/x86_64-linux/usr
--with-system-zlib --disable-nls --enable-__cxa_atexit --with-abi=64
--with-arch-64=mips64 --with-tune-64=mips64
Thread model: posix
gcc version 4.7.2 (GCC)
$

  are you suggesting i should have pulled in the angstrom layer?
anyway, must dash off for the evening but i'll check back later.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

On Mon, May 13, 2013 at 6:19 PM, Khem Raj <raj.khem@gmail.com> wrote:
> sysroots/x86_64-linux/usr/bin/mips64-angstrom-linux/mips64-angstrom-linux-gcc -v

angstrom??!

angstrom -> poky?

sysroots/x86_64-linux/usr/bin/mips64-poky-linux/mips64-poky-linux-gcc --version
mips64-poky-linux-gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Re: [PATCH 0/4] Add qemumips64 machine support

[Khem Raj]

On May 13, 2013, at 3:50 PM, Trevor Woerner <twoerner@gmail.com> wrote:

> On Mon, May 13, 2013 at 6:19 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> sysroots/x86_64-linux/usr/bin/mips64-angstrom-linux/mips64-angstrom-linux-gcc -v
> 
> angstrom??!
> 
> angstrom -> poky?

doesn't matter whatever your distro is.


> 
> sysroots/x86_64-linux/usr/bin/mips64-poky-linux/mips64-poky-linux-gcc --version
> mips64-poky-linux-gcc (GCC) 4.7.2
> Copyright (C) 2012 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

hmm ok so its 4.7

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Khem Raj wrote:

> Robert and Trevor
>
> so whats your cross-gcc version ?
> should be in tmpdir under
>
> sysroots/x86_64-linux/usr/bin/mips64-angstrom-linux/mips64-angstrom-linux-gcc -v

  after a fresh build, each attempt to boot qemumips64 hangs at some
point. i am definitely open to suggestions.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

By adding:

    PREFERRED_VERSION_linux-yocto := "3.8%"

to my conf/local.conf I was able to get the image to build/use 3.8.11;
but I too am still seeing the kernel panic as described before (i.e.
in reset_counters()).

Re: [PATCH 0/4] Add qemumips64 machine support

[Khem Raj]

cool, keep tuned I might have narrowed it down

On May 13, 2013, at 7:01 PM, Trevor Woerner <twoerner@gmail.com> wrote:

> By adding:
> 
>    PREFERRED_VERSION_linux-yocto := "3.8%"
> 
> to my conf/local.conf I was able to get the image to build/use 3.8.11;
> but I too am still seeing the kernel panic as described before (i.e.
> in reset_counters()).

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

On Mon, May 13, 2013 at 10:01 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> By adding:
>
>     PREFERRED_VERSION_linux-yocto := "3.8%"

Yep. This is what I was about to recommend, but did you apply Khem's patches, or
use his contrib branch ? The 3.4 kernel has no compatibility with
qemumips64, so it
should have never built, and you shouldn't have needed the version set.

Bruce

>
> to my conf/local.conf I was able to get the image to build/use 3.8.11;
> but I too am still seeing the kernel panic as described before (i.e.
> in reset_counters()).



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

On Mon, May 13, 2013 at 10:03 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Mon, May 13, 2013 at 10:01 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>> By adding:
>>
>>     PREFERRED_VERSION_linux-yocto := "3.8%"
>
> Yep. This is what I was about to recommend, but did you apply Khem's patches, or
> use his contrib branch ?

His contrib branch:

Build Configuration:
BB_VERSION        = "1.19.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "openSUSE-project-12.3"
TARGET_SYS        = "mips64-poky-linux"
MACHINE           = "qemumips64"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20130514"
TUNE_FEATURES     = "n64 bigendian fpu-hard"
TARGET_FPU        = ""
meta-yocto        = "master:a9f5bf0ed398bf9cb861feaa8b6fefd8645b1d09"
meta              = "kraj/qemumips64:b0592ab08273e17cb1511384ad189281f88c8b03"


Are there patches to apply too?

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

On Mon, May 13, 2013 at 10:18 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> On Mon, May 13, 2013 at 10:03 PM, Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
>> On Mon, May 13, 2013 at 10:01 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>>> By adding:
>>>
>>>     PREFERRED_VERSION_linux-yocto := "3.8%"
>>
>> Yep. This is what I was about to recommend, but did you apply Khem's patches, or
>> use his contrib branch ?
>
> His contrib branch:
>
> Build Configuration:
> BB_VERSION        = "1.19.0"
> BUILD_SYS         = "x86_64-linux"
> NATIVELSBSTRING   = "openSUSE-project-12.3"
> TARGET_SYS        = "mips64-poky-linux"
> MACHINE           = "qemumips64"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.3+snapshot-20130514"
> TUNE_FEATURES     = "n64 bigendian fpu-hard"
> TARGET_FPU        = ""
> meta-yocto        = "master:a9f5bf0ed398bf9cb861feaa8b6fefd8645b1d09"
> meta              = "kraj/qemumips64:b0592ab08273e17cb1511384ad189281f88c8b03"
>
>
> Are there patches to apply too?

The four patch series that you just replied to :) That's all you need on top of
oe-core master.

Bruce



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/4] Add qemumips64 machine support

[Khem Raj]

can you try this 

add

SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac"

to linux-yocto_3.8.bb

and rebuild the kernel and see if that boots

On May 13, 2013, at 7:18 PM, Trevor Woerner <twoerner@gmail.com> wrote:

> On Mon, May 13, 2013 at 10:03 PM, Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
>> On Mon, May 13, 2013 at 10:01 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>>> By adding:
>>> 
>>>    PREFERRED_VERSION_linux-yocto := "3.8%"
>> 
>> Yep. This is what I was about to recommend, but did you apply Khem's patches, or
>> use his contrib branch ?
> 
> His contrib branch:
> 
> Build Configuration:
> BB_VERSION        = "1.19.0"
> BUILD_SYS         = "x86_64-linux"
> NATIVELSBSTRING   = "openSUSE-project-12.3"
> TARGET_SYS        = "mips64-poky-linux"
> MACHINE           = "qemumips64"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.3+snapshot-20130514"
> TUNE_FEATURES     = "n64 bigendian fpu-hard"
> TARGET_FPU        = ""
> meta-yocto        = "master:a9f5bf0ed398bf9cb861feaa8b6fefd8645b1d09"
> meta              = "kraj/qemumips64:b0592ab08273e17cb1511384ad189281f88c8b03"
> 
> 
> Are there patches to apply too?

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Khem Raj wrote:

> can you try this
>
> add
>
> SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac"
>
> to linux-yocto_3.8.bb
>
> and rebuild the kernel and see if that boots

  does that apply to me as well?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Khem Raj wrote:

> can you try this
>
> add
>
> SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac"
>
> to linux-yocto_3.8.bb
>
> and rebuild the kernel and see if that boots

  ok, that gives me a successful boot (tried it twice, success both
times) but i'm now at a boot prompt:

  qemumips64 login:

that's not accepting any keyboard input.  tried a couple more times,
same result -- boot to login prompt, but no keyboard input. thoughts?

rday

p.s.  i can ping the VM (192.168.7.2) but can't ssh into it, FWIW.

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

On Tue, May 14, 2013 at 4:28 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Mon, 13 May 2013, Khem Raj wrote:
>
>> can you try this
>>
>> add
>>
>> SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac"
>>
>> to linux-yocto_3.8.bb
>>
>> and rebuild the kernel and see if that boots
>
>   ok, that gives me a successful boot (tried it twice, success both
> times) but i'm now at a boot prompt:
>
>   qemumips64 login:
>
> that's not accepting any keyboard input.  tried a couple more times,
> same result -- boot to login prompt, but no keyboard input. thoughts?

I'm going to switch to an oe-core only, clean build today. The commit that Khem
referenced was my change where we prototyped this work .. and I fixed the boot.
But I'm still able to boot here, so I was unaware that my -stable
updates managed
to break my own fix :)

Stay tuned, but for now, I'd suggest waiting to hear back from me.
I'll bisect and
fix it again if it (re)broke.

Bruce

>
> rday
>
> p.s.  i can ping the VM (192.168.7.2) but can't ssh into it, FWIW.
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Tue, 14 May 2013, Bruce Ashfield wrote:

> On Tue, May 14, 2013 at 4:28 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > On Mon, 13 May 2013, Khem Raj wrote:
> >
> >> can you try this
> >>
> >> add
> >>
> >> SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac"
> >>
> >> to linux-yocto_3.8.bb
> >>
> >> and rebuild the kernel and see if that boots
> >
> >   ok, that gives me a successful boot (tried it twice, success both
> > times) but i'm now at a boot prompt:
> >
> >   qemumips64 login:
> >
> > that's not accepting any keyboard input.  tried a couple more times,
> > same result -- boot to login prompt, but no keyboard input. thoughts?
>
> I'm going to switch to an oe-core only, clean build today. The
> commit that Khem referenced was my change where we prototyped this
> work .. and I fixed the boot. But I'm still able to boot here, so I
> was unaware that my -stable updates managed to break my own fix :)
>
> Stay tuned, but for now, I'd suggest waiting to hear back from me...

  i will be sitting here, waiting on tenterhooks for someone to
explain to me what "tenterhooks" are.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

On Tue, May 14, 2013 at 8:25 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Tue, 14 May 2013, Bruce Ashfield wrote:
>
>> On Tue, May 14, 2013 at 4:28 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>> > On Mon, 13 May 2013, Khem Raj wrote:
>> >
>> >> can you try this
>> >>
>> >> add
>> >>
>> >> SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac"
>> >>
>> >> to linux-yocto_3.8.bb
>> >>
>> >> and rebuild the kernel and see if that boots
>> >
>> >   ok, that gives me a successful boot (tried it twice, success both
>> > times) but i'm now at a boot prompt:
>> >
>> >   qemumips64 login:
>> >
>> > that's not accepting any keyboard input.  tried a couple more times,
>> > same result -- boot to login prompt, but no keyboard input. thoughts?
>>
>> I'm going to switch to an oe-core only, clean build today. The
>> commit that Khem referenced was my change where we prototyped this
>> work .. and I fixed the boot. But I'm still able to boot here, so I
>> was unaware that my -stable updates managed to break my own fix :)
>>
>> Stay tuned, but for now, I'd suggest waiting to hear back from me...
>
>   i will be sitting here, waiting on tenterhooks for someone to
> explain to me what "tenterhooks" are.

:) and the "good" news, is that I finally managed to get a boot to fail
locally. I'm not bisecting and debugging the problem. I've fixed this
before, so I don't expect it will take too long.

I see that Saul picked up the support and plumbing for this, so if that
merges, I'll send incremental updates to the SRCREVs. I'll ignore
any high priority bugzilla entries on principle, since this is still baking
and we just want to get the plumbing in place :)

Cheers,

Bruce

>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

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

What really confuses me about the attempts I was making is that in
my local.conf file I have explicitly asked for kernel version 3.8.11:

    PREFERRED_VERSION_linux-yocto := "3.8.11%"

When I watch the build messages fly by I see that linux-yocto_3.8.11
is being built.

In my work directory there is a directory called:


tmp/work/qemumips64-poky-linux/linux-yocto/3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_bbefde394205a1b317eae31942bfc13afce0b0ac-r4.1/

but when I got into the


tmp/work/qemumips64-poky-linux/linux-yocto/3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_bbefde394205a1b317eae31942bfc13afce0b0ac-r4.1/linux

directory and have a look at the Makefile, I see:

     VERSION = 3
     PATCHLEVEL = 8
     SUBLEVEL = 4
     EXTRAVERSION =
     NAME = Unicycling Gorilla

and when I boot the image the kernel banner says:

    Linux version 3.8.4-yocto-standard (trevor@zzz) (gcc version 4.7.2
(GCC) ) #1 PREEMPT Tue May 14 11:10:07 EDT 2013

Can anyone explain the discrepancy?

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

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

On Wed, May 15, 2013 at 1:22 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> What really confuses me about the attempts I was making is that in
> my local.conf file I have explicitly asked for kernel version 3.8.11:
>
>     PREFERRED_VERSION_linux-yocto := "3.8.11%"
>
> When I watch the build messages fly by I see that linux-yocto_3.8.11
> is being built.
>
> In my work directory there is a directory called:
>
>
> tmp/work/qemumips64-poky-linux/linux-yocto/3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_bbefde394205a1b317eae31942bfc13afce0b0ac-r4.1/
>
> but when I got into the
>
>
> tmp/work/qemumips64-poky-linux/linux-yocto/3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_bbefde394205a1b317eae31942bfc13afce0b0ac-r4.1/linux
>
> directory and have a look at the Makefile, I see:
>
>      VERSION = 3
>      PATCHLEVEL = 8
>      SUBLEVEL = 4
>      EXTRAVERSION =
>      NAME = Unicycling Gorilla
>
> and when I boot the image the kernel banner says:
>
>     Linux version 3.8.4-yocto-standard (trevor@zzz) (gcc version 4.7.2 (GCC)
> ) #1 PREEMPT Tue May 14 11:10:07 EDT 2013
>
> Can anyone explain the discrepancy?

You set the SRCREV that Khem sent. That was my 3.8.4. commit. The version
number in the directories is coming coming from the PV of the package, which you
didn't tweak.

Bruce


--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

On Wed, May 15, 2013 at 1:24 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> You set the SRCREV that Khem sent. That was my 3.8.4. commit. The version
> number in the directories is coming coming from the PV of the package, which you
> didn't tweak.

Ahh... yes. Thank you. Makes perfect sense now :-)

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

On Wed, May 15, 2013 at 1:58 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> On Wed, May 15, 2013 at 1:24 PM, Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
>> You set the SRCREV that Khem sent. That was my 3.8.4. commit. The version
>> number in the directories is coming coming from the PV of the package, which you
>> didn't tweak.
>
> Ahh... yes. Thank you. Makes perfect sense now :-)

qemumips64 login: root
root@qemumips64:~# uname -a
Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Wed May 15 16:43:43
EDT 2013 mips64 GNU/Linux

diff --git a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
index b79fa4e..d458212 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
@@ -5,6 +5,7 @@ KBRANCH = "${KBRANCH_DEFAULT}"

 SRCREV_machine_qemuarm ?= "8fb1a478c9a05362e2e4e62fc30f5ef5d6c21f49"
 SRCREV_machine_qemumips  ?= "b8870f2b11f4c948ae90a19886335fa8b7fca487"
+SRCREV_machine_qemumips64  ?= "49041e56a3c4ff552bf9f8195809b8040e2e2723"
 SRCREV_machine_qemuppc ?= "e4c12f12e61a29b6605c4fcbcfd6dbe18bd7b4e4"
 SRCREV_machine_qemux86 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"
 SRCREV_machine_qemux86-64 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"

-----------

Try a rebuild with that, works cleanly for me in oe-core. When I
enabled the board,
I neglected to pull in my SRCREV update.

Cheers,

Bruce

--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Wed, 15 May 2013, Bruce Ashfield wrote:

> On Wed, May 15, 2013 at 1:58 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> > On Wed, May 15, 2013 at 1:24 PM, Bruce Ashfield
> > <bruce.ashfield@gmail.com> wrote:
> >> You set the SRCREV that Khem sent. That was my 3.8.4. commit. The version
> >> number in the directories is coming coming from the PV of the package, which you
> >> didn't tweak.
> >
> > Ahh... yes. Thank you. Makes perfect sense now :-)
>
> qemumips64 login: root
> root@qemumips64:~# uname -a
> Linux qemumips64 3.8.11-yocto-standard #1 PREEMPT Wed May 15 16:43:43
> EDT 2013 mips64 GNU/Linux
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
> b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
> index b79fa4e..d458212 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
> @@ -5,6 +5,7 @@ KBRANCH = "${KBRANCH_DEFAULT}"
>
>  SRCREV_machine_qemuarm ?= "8fb1a478c9a05362e2e4e62fc30f5ef5d6c21f49"
>  SRCREV_machine_qemumips  ?= "b8870f2b11f4c948ae90a19886335fa8b7fca487"
> +SRCREV_machine_qemumips64  ?= "49041e56a3c4ff552bf9f8195809b8040e2e2723"
>  SRCREV_machine_qemuppc ?= "e4c12f12e61a29b6605c4fcbcfd6dbe18bd7b4e4"
>  SRCREV_machine_qemux86 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"
>  SRCREV_machine_qemux86-64 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"

  so just to be painfully clear, if i have current oe-core and
openembedded-core-contrib repoes, i need make only the above change in
the latter to get a working qemumips64 build that will boot to the
command line and let me log in?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

On Wed, May 15, 2013 at 5:58 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Wed, 15 May 2013, Bruce Ashfield wrote:
>> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
>> b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
>> index b79fa4e..d458212 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
>> @@ -5,6 +5,7 @@ KBRANCH = "${KBRANCH_DEFAULT}"
>>
>>  SRCREV_machine_qemuarm ?= "8fb1a478c9a05362e2e4e62fc30f5ef5d6c21f49"
>>  SRCREV_machine_qemumips  ?= "b8870f2b11f4c948ae90a19886335fa8b7fca487"
>> +SRCREV_machine_qemumips64  ?= "49041e56a3c4ff552bf9f8195809b8040e2e2723"
>>  SRCREV_machine_qemuppc ?= "e4c12f12e61a29b6605c4fcbcfd6dbe18bd7b4e4"
>>  SRCREV_machine_qemux86 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"
>>  SRCREV_machine_qemux86-64 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"
>
>   so just to be painfully clear, if i have current oe-core and
> openembedded-core-contrib repoes, i need make only the above change in
> the latter to get a working qemumips64 build that will boot to the
> command line and let me log in?

I just built and ran it using plain meta-poky/meta and
meta-poky/meta-yocto (applying the above change to meta-poky/meta/...,
and using a very recent pull to master) and am quite happy to report
that it works for me (as I understand it Saul pushed the various parts
required for the toolchain earlier today). The linux kernel banner,
sources, and "uname -a" are all linux-yocto_3.8.11 and I can log in
using the qemu SDL interface.

Now I just have to remove the kernel version preference line in my
config and verify that works okay too.

Does this mean we now have something that can work on the EdgeRouter Lite?

Re: [PATCH 0/4] Add qemumips64 machine support

[Khem Raj]

On May 15, 2013, at 3:33 PM, Trevor Woerner <twoerner@gmail.com> wrote:

> Does this mean we now have something that can work on the EdgeRouter Lite?

well you have to have a kernel for that platform. If you have working kernel everything else will ditto work

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Wed, 15 May 2013, Khem Raj wrote:

>
> On May 15, 2013, at 3:33 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>
> > Does this mean we now have something that can work on the EdgeRouter Lite?
>
> well you have to have a kernel for that platform. If you have
> working kernel everything else will ditto work

  whoo hoo.  ok, with current oe-core and current
openembedded-core-contrib with the following patch from bruce:

--- a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
@@ -5,6 +5,7 @@ KBRANCH = "${KBRANCH_DEFAULT}"

 SRCREV_machine_qemuarm ?= "8fb1a478c9a05362e2e4e62fc30f5ef5d6c21f49"
 SRCREV_machine_qemumips  ?= "b8870f2b11f4c948ae90a19886335fa8b7fca487"
+SRCREV_machine_qemumips64  ?= "49041e56a3c4ff552bf9f8195809b8040e2e2723"
 SRCREV_machine_qemuppc ?= "e4c12f12e61a29b6605c4fcbcfd6dbe18bd7b4e4"
 SRCREV_machine_qemux86 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"
 SRCREV_machine_qemux86-64 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"

  i have a qemumips64 build that boots to the command line and accepts
input and I CAN LOG IN!!!!!!!!!!!!!!!

  awesome. it's martini time.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Bruce Ashfield]

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

On Wednesday, May 15, 2013, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Wed, 15 May 2013, Khem Raj wrote:
>
>>
>> On May 15, 2013, at 3:33 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>>
>> > Does this mean we now have something that can work on the EdgeRouter
Lite?
>>
>> well you have to have a kernel for that platform. If you have
>> working kernel everything else will ditto work
>
>   whoo hoo.  ok, with current oe-core and current
> openembedded-core-contrib with the following patch from bruce:
>
> --- a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
> @@ -5,6 +5,7 @@ KBRANCH = "${KBRANCH_DEFAULT}"
>
>  SRCREV_machine_qemuarm ?= "8fb1a478c9a05362e2e4e62fc30f5ef5d6c21f49"
>  SRCREV_machine_qemumips  ?= "b8870f2b11f4c948ae90a19886335fa8b7fca487"
> +SRCREV_machine_qemumips64  ?= "49041e56a3c4ff552bf9f8195809b8040e2e2723"
>  SRCREV_machine_qemuppc ?= "e4c12f12e61a29b6605c4fcbcfd6dbe18bd7b4e4"
>  SRCREV_machine_qemux86 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"
>  SRCREV_machine_qemux86-64 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"
>
>   i have a qemumips64 build that boots to the command line and accepts
> input and I CAN LOG IN!!!!!!!!!!!!!!!

Thanks for the confirmation everyone. I'll send the real patch later
tonight (I have one other small tweak to add)

Bruce


>
>   awesome. it's martini time.
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
>

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

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

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

  just FYI, did a fresh build for qemumips64 from updated oe-core
layer alone, and it seems to work fine. i think it's a keeper.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: [PATCH 0/4] Add qemumips64 machine support

[Khem Raj]

On May 18, 2013, at 5:50 AM, "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:

> 
>  just FYI, did a fresh build for qemumips64 from updated oe-core
> layer alone, and it seems to work fine. i think it's a keeper.

thanks. Now expecting people to build world with qemumips64 and report issues.

Re: [PATCH 0/4] Add qemumips64 machine support

[Andrea Adami]

On Sat, May 18, 2013 at 6:14 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
> On May 18, 2013, at 5:50 AM, "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>
>>
>>  just FYI, did a fresh build for qemumips64 from updated oe-core
>> layer alone, and it seems to work fine. i think it's a keeper.
>
> thanks. Now expecting people to build world with qemumips64 and report issues.

Well, I can already say that klibc (meta-initramfs layer) fails to
compile. Help much appreciated upstream.

Regards
Andrea


> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 0/4] Add qemumips64 machine support

[Trevor Woerner]

On Tue, May 14, 2013 at 4:28 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Mon, 13 May 2013, Khem Raj wrote:
>> can you try this
>>
>> add
>>
>> SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac"
>>
>> to linux-yocto_3.8.bb
>>
>> and rebuild the kernel and see if that boots
>
>   ok, that gives me a successful boot (tried it twice, success both
> times) but i'm now at a boot prompt:
>
>   qemumips64 login:
>
> that's not accepting any keyboard input.  tried a couple more times,
> same result -- boot to login prompt, but no keyboard input. thoughts?

Me too. If I use the "serial" option on the "runqemu" cmdline I can
log in via the serial console. There was a time when I would get an
unresponsive qemumips console (via SDL) but could log in on console...
3? or 4? That isn't the case with qemumips64.

By the way, my build is still wanting to use linux-yocto_3.4.43.

What's interesting is: without the change described by Khem above if I put:

    PREFERRED_VERSION_linux-yocto := "3.8%"

in my local.conf I would get 3.8.11. When I add the change as
described above, this line in local.conf gives me linux-yocto_3.8.4!


With Khem's suggestion above:
- linux-yocto_3.8.4 boots but the SDL console doesn't accept input
- linux-yocto_3.4.43 doesn't fully boot (as before)


> p.s.  i can ping the VM (192.168.7.2) but can't ssh into it, FWIW.

I don't have any issue ssh'ing into the VM (with the 3.8.4 kernel)
when I add "ssh-server-openssh" to "EXTRA_IMAGE_FEATURES".

Re: [PATCH 0/4] Add qemumips64 machine support

[Robert P. J. Day]

On Mon, 13 May 2013, Khem Raj wrote:

> can you try this
>
> add
>
> SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac"
>
> to linux-yocto_3.8.bb
>
> and rebuild the kernel and see if that boots

  i've updated my results here:

http://www.crashcourse.ca/wiki/index.php/Adding_MIPS64_QEMU_machine

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================