Skip to contentSkip to conversation

Add qemumips64 machine support

PATCH In review Khem Raj 5 participants 62 messages May 13, 2013 – May 18, 2013

lore
Share & tools
lore

Khem Raj

author
#0 lore raw

cover Add qemumips64 machine support

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
Signature · 1 line
1.8.2.1
author
#1 lore raw

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

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 <[email protected]>
---
 scripts/runqemu-gen-tapdevs | 6 +++---
 scripts/runqemu-ifup        | 6 +++---
 scripts/runqemu-internal    | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)
scripts/runqemu-gen-tapdevs +3 -3
index f5be30a..d3b27be 100755
@@ -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
scripts/runqemu-ifup +3 -3
index 0926faf..8948153 100755
@@ -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
scripts/runqemu-internal +3 -3
index 3bd0a09..3c5282d 100755
@@ -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
Signature · 1 line
1.8.2.1
author
#2 lore raw

PATCH 2/4 linux-yocto: add qemumips64 compatibility

From: Bruce Ashfield <[email protected]>

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 <[email protected]>
Signed-off-by Khem Raj <[email protected]>
---
 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(-)
meta/recipes-kernel/linux/linux-yocto-dev.bb +1 -1
index fdea085..598c82c 100644
@@ -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"
meta/recipes-kernel/linux/linux-yocto_3.8.bb +1 -1
index 2fcaddd..b79fa4e 100644
@@ -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"
Signature · 1 line
1.8.2.1
author
#3 lore raw

PATCH 3/4 binutils: Add broadcom XLP support

In reply to Khem Raj
Signed-off-by Khem Raj <[email protected]>
---
 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
meta/recipes-devtools/binutils/binutils-2.23.2.inc +1 -0
index ddbe522..07bc7e0 100644
@@ -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 = "\
meta/recipes-devtools/binutils/binutils-2.23.2/binutils-xlp-support.patch new file +398 -0

398 lines not on this page · raw message

Signature · 1 line
1.8.2.1
author
#4 lore raw

PATCH 4/4 machine/qemumips64: Add machine definition

In reply to Khem Raj
Signed-off-by Khem Raj <[email protected]>
---
 meta/conf/machine/qemumips64.conf | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 meta/conf/machine/qemumips64.conf
meta/conf/machine/qemumips64.conf new file +13 -0
new file mode 100644
index 0000000..b2c7998
@@ -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"
Signature · 1 line
1.8.2.1
#5 lore raw
In reply to Khem Raj
Quoted 3 lines · 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

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).

author
#6 lore raw
Quoted 6 lines · Trevor Woerner
Quoted 3 lines · 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

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 ?

Quoted 73 lines

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>

#7 lore raw
Quoted 4 lines · Khem Raj

On May 13, 2013, at 9:45 AM, Trevor Woerner <[email protected]> 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 [email protected]
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:
[email protected]
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
author
#8 lore raw
Quoted 12 lines · Trevor Woerner

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
        ...
Quoted 10 lines
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

Quoted 3 lines
Code: 4080c802  4080c803  4080c800 <4080c801> 03c0e82d  dfbe0008  03e00008  67bd0010  00000000 
---[ end trace 340dd7de1cdea432 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
#9 lore raw
Quoted 1 line · Khem Raj

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).

#10 lore raw
In reply to Trevor Woerner
Quoted 87 lines · Trevor Woerner
Quoted 4 lines · Khem Raj

On May 13, 2013, at 9:45 AM, Trevor Woerner <[email protected]> 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 [email protected]
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:
[email protected]
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
Quoted 4 lines
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

Quoted 6 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
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"

#11 lore raw

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?

#12 lore raw
Quoted 6 lines · 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.

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#13 lore raw
Quoted 5 lines · Robert P. J. Day

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 \
          "
Quoted 5 lines

* 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.

#14 lore raw
Quoted 10 lines · Trevor Woerner
Quoted 5 lines · Robert P. J. Day

  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:

Quoted 8 lines

     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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#15 lore raw
In reply to Trevor Woerner
Quoted 21 lines · Trevor Woerner
Quoted 5 lines · Robert P. J. Day

  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 \
          "

Quoted 7 lines
Quoted 5 lines

* 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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#16 lore raw
Quoted 29 lines · Robert P. J. Day
Quoted 27 lines · Trevor Woerner
Quoted 5 lines · Robert P. J. Day

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 \
          "
Quoted 5 lines

* 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 ...

Quoted 8 lines
Quoted 1 line

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

Quoted 5 lines

rday

--

Quoted 7 lines

========================================================================
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"

#17 lore raw
Quoted 9 lines · Bruce Ashfield
Quoted 7 lines · Robert P. J. Day

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

$ runqemu qemumips64

??? any known issues or surprises?

Quoted 8 lines

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#18 lore raw
In reply to Bruce Ashfield
Quoted 8 lines · Bruce Ashfield

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#19 lore raw
Quoted 8 lines · Robert P. J. Day
Quoted 6 lines · Bruce Ashfield

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
Quoted 5 lines
Quoted 2 lines

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

Quoted 5 lines

rday

--

Quoted 7 lines

========================================================================
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"

#20 lore raw
Quoted 15 lines · Bruce Ashfield
Quoted 8 lines · Robert P. J. Day
Quoted 6 lines · Bruce Ashfield

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
Quoted 5 lines
Quoted 2 lines

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.

Quoted 7 lines

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 <[email protected]>
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 <[email protected]>

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

commit b0592ab08273e17cb1511384ad189281f88c8b03

Author: Khem Raj <[email protected]>
Date:   Tue Mar 26 18:01:56 2013 -0700

machine/qemumips64: Add machine definition

Signed-off-by Khem Raj <[email protected]>

commit 74e3eb74194baade027edc3f23985aa72ce055eb

Author: Khem Raj <[email protected]>
Date:   Tue Apr 16 19:17:03 2013 -0700

binutils: Add broadcom XLP support

Signed-off-by Khem Raj <[email protected]>

commit e4d9bfb01c5657a7f30597d83829375520d64627

Author: Bruce Ashfield <[email protected]>
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 <[email protected]>
Signed-off-by Khem Raj <[email protected]>

am i just not up to date somehow?

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#21 lore raw

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

#22 lore raw
Quoted 2 lines · Trevor Woerner

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#23 lore raw

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.

#24 lore raw
Quoted 14 lines · Trevor Woerner

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#25 lore raw
Quoted 20 lines · Robert P. J. Day
Quoted 1 line · Trevor Woerner

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

doing.

Quoted 6 lines

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

Quoted 5 lines

linux-libc-headers :3.8-r0

linux-libc-headers-yocto

:3.4+git-AUTOINC+a1cdb60720c452c3965eaec3ec2cd10f06261cc5_a1cdb60720c452c3965eaec3ec2cd10f06261cc5-r6

Quoted 1 line
Quoted 9 lines
Quoted 2 lines

linux-yocto

:3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_dd089cb5ba37ea14e8f90a884bf2a5be64ed817d-r4.1

Quoted 1 line

: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 :-)

#26 lore raw
Quoted 18 lines · Trevor Woerner

On Mon, May 13, 2013 at 5:30 PM, Robert P. J. Day <[email protected]> wrote:

Quoted 6 lines · Trevor Woerner

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      

Quoted 4 lines


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

Quoted 3 lines


linux-yocto

Quoted 8 lines

:3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_dd089cb5ba37ea14e8f90a884bf2a5be64ed817d-r4.1

Quoted 1 line

: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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#27 lore raw

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.

#29 lore raw
In reply to Bruce Ashfield
Quoted 15 lines · Bruce Ashfield
Quoted 8 lines · Robert P. J. Day
Quoted 6 lines · Bruce Ashfield

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
Quoted 5 lines
Quoted 2 lines

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.

Quoted 7 lines

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#30 lore raw
In reply to Bruce Ashfield
Quoted 15 lines · Bruce Ashfield
Quoted 8 lines · Robert P. J. Day
Quoted 6 lines · Bruce Ashfield

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
Quoted 5 lines
Quoted 2 lines

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.

Quoted 7 lines

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
author
#31 lore raw

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

Quoted 42 lines · Robert P. J. Day
Quoted 15 lines · Bruce Ashfield
Quoted 8 lines · Robert P. J. Day
Quoted 6 lines · Bruce Ashfield

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
Quoted 5 lines
Quoted 2 lines

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.

Quoted 7 lines

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                       http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#32 lore raw
Quoted 6 lines · 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

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#33 lore raw
In reply to Khem Raj
Quoted 6 lines · 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

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#34 lore raw
In reply to Khem Raj
Quoted 1 line · Khem Raj

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.

author
#35 lore raw
Quoted 6 lines · Trevor Woerner
Quoted 1 line · Khem Raj

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

angstrom??!

angstrom -> poky?

doesn't matter whatever your distro is.

Quoted 6 lines

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

#36 lore raw
In reply to Khem Raj
Quoted 6 lines · 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

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

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#37 lore raw

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()).

author
#38 lore raw

cool, keep tuned I might have narrowed it down

Quoted 7 lines · 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()).

#39 lore raw
In reply to Trevor Woerner
Quoted 3 lines · Trevor Woerner

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

Quoted 4 lines

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"

#40 lore raw
Quoted 7 lines · Bruce Ashfield
Quoted 3 lines · Trevor Woerner

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?

#41 lore raw
Quoted 26 lines · Trevor Woerner
Quoted 7 lines · Bruce Ashfield
Quoted 3 lines · Trevor Woerner

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"
Quoted 1 line

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"

author
#42 lore raw
In reply to Trevor Woerner

can you try this

add

SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac"

to linux-yocto_3.8.bb

and rebuild the kernel and see if that boots

Quoted 27 lines · Trevor Woerner
Quoted 7 lines · Bruce Ashfield
Quoted 3 lines · Trevor Woerner

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?

#43 lore raw
Quoted 9 lines · 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

does that apply to me as well?

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#44 lore raw
In reply to Khem Raj
Quoted 9 lines · 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

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.

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#45 lore raw
Quoted 12 lines · Robert P. J. Day
Quoted 9 lines · 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

Quoted 7 lines

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

Quoted 7 lines

rday

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

--

Quoted 7 lines

========================================================================
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"

#46 lore raw
Quoted 21 lines · Bruce Ashfield
Quoted 12 lines · Robert P. J. Day
Quoted 9 lines · 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

Quoted 7 lines

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?

Quoted 6 lines

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#47 lore raw
Quoted 28 lines · Robert P. J. Day
Quoted 26 lines · Bruce Ashfield
Quoted 12 lines · Robert P. J. Day
Quoted 9 lines · 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

Quoted 7 lines

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 :)

Quoted 4 lines
Quoted 1 line

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

Quoted 5 lines

rday

--

Quoted 7 lines

========================================================================
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"

#48 lore raw

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?

#49 lore raw
Quoted 26 lines · Trevor Woerner

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

Quoted 6 lines

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"

#50 lore raw
Quoted 3 lines · Bruce Ashfield

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 :-)

#51 lore raw
Quoted 7 lines · Trevor Woerner
Quoted 3 lines · Bruce Ashfield

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
(quoted diff) +0 -0

b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
index b79fa4e..d458212 100644

meta/recipes-kernel/linux/linux-yocto_3.8.bb +1 -0
@@ -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"

#52 lore raw
Quoted 20 lines · Bruce Ashfield
Quoted 7 lines · Trevor Woerner
Quoted 3 lines · Bruce Ashfield

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
meta/recipes-kernel/linux/linux-yocto_3.8.bb +0 -0
index b79fa4e..d458212 100644

meta/recipes-kernel/linux/linux-yocto_3.8.bb KBRANCH = "${KBRANCH_DEFAULT}" · line 11

Quoted 7 lines
meta/recipes-kernel/linux/linux-yocto_3.8.bb +1 -0
@@ -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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#53 lore raw
Quoted 8 lines · Robert P. J. Day
Quoted 7 lines · Bruce Ashfield
meta/recipes-kernel/linux/linux-yocto_3.8.bb +0 -0
index b79fa4e..d458212 100644
@@ -5,6 +5,7 @@ KBRANCH = "${KBRANCH_DEFAULT}"
Quoted 11 lines

meta/recipes-kernel/linux/linux-yocto_3.8.bb KBRANCH = "${KBRANCH_DEFAULT}" · line 11

Quoted 6 lines
meta/recipes-kernel/linux/linux-yocto_3.8.bb +1 -0
 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?

author
#54 lore raw
Quoted 1 line · Trevor Woerner

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

#55 lore raw
Quoted 7 lines · Khem Raj
Quoted 1 line · Trevor Woerner

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:

meta/recipes-kernel/linux/linux-yocto_3.8.bb +1 -0
@@ -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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#56 lore raw
Quoted 6 lines · Robert P. J. Day
Quoted 4 lines · Khem Raj
Quoted 1 line · Trevor Woerner

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

Lite?

Quoted 18 lines
Quoted 3 lines

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:

meta/recipes-kernel/linux/linux-yocto_3.8.bb +1 -0
@@ -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"
Quoted 2 lines

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

Quoted 15 lines

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

========================================================================

Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
#57 lore raw
In reply to Bruce Ashfield

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

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
author
#58 lore raw
Quoted 3 lines · 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.

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

#59 lore raw
Quoted 8 lines · Khem Raj
Quoted 3 lines · 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.

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

Quoted 4 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#60 lore raw
In reply to Robert P. J. Day
Quoted 11 lines · Robert P. J. Day
Quoted 9 lines · 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

Quoted 7 lines

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)

Quoted 1 line

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".

#61 lore raw
In reply to Khem Raj
Quoted 9 lines · 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

i've updated my results here:

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

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

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