1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
graphic: 0.852
device: 0.810
instruction: 0.806
mistranslation: 0.802
other: 0.800
semantic: 0.783
assembly: 0.775
KVM: 0.758
vnc: 0.746
boot: 0.733
socket: 0.696
network: 0.683
qemu-system-arm hangs at start on OS X
Both from release 2.1.2 and built from a recent source, qemu-system-arm seems to hang on a mutex immediately after starting up, never getting to the point of actually booting.
I've tried qemu-system-mipsel with another image and it worked fine, so this seems to be specific to the ARM runtime. I've tried two different ARM kernels, and I also ran into this with QEMU 2.1.2 release, installed from a bottle using homebrew.
Host: Mac OS X 10.9.5 (Darwin Kernel Version 13.4.0)
QEMU version: built from HEAD@ab0302ee76
Build command: ./configure --enable-cocoa --target-list=arm-softmmu,mipsel-softmmu && make
Run command:
qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 256 -sd disk.img -net nic,macaddr=52:54:00:fa:ce:13 -kernel vmlinuz-3.2.0-4-vexpress -initrd initrd.gz -append "root=/dev/ram" -display vnc=localhost:17 -net user,hostfwd=tcp::5022-:22 -append "console=ttyS0"
I also tried this, with a different kernel & root:
qemu-system-arm -kernel zImage -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -hda rootfs-chromium.ext2 -append "root=/dev/sda"
Thread dump:
(lldb) thread list
Process 34364 stopped
* thread #1: tid = 0x135966, 0x00007fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
thread #2: tid = 0x13598b, 0x00007fff89f4ae6a libsystem_kernel.dylib`__workq_kernreturn + 10
thread #3: tid = 0x13598c, 0x00007fff89f4b662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager'
thread #7: tid = 0x1359b2, 0x00007fff89f4acc2 libsystem_kernel.dylib`__sigwait + 10
thread #9: tid = 0x1359c1, 0x00000001091bc5d9
thread #11: tid = 0x1359cc, 0x00007fff89f4a716 libsystem_kernel.dylib`__psynch_cvwait + 10
thread #12: tid = 0x1359da, 0x00007fff89f46a1a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.audio.IOThread.client'
-------
* thread #1: tid = 0x135966, 0x00007fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x00007fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10
frame #1: 0x00007fff8e05f779 libsystem_pthread.dylib`_pthread_mutex_lock + 372
frame #2: 0x000000010033e8e9 qemu-system-arm`qemu_mutex_lock(mutex=<unavailable>) + 25 at qemu-thread-posix.c:76
frame #3: 0x000000010002d742 qemu-system-arm`qemu_mutex_lock_iothread + 98 at cpus.c:1137
frame #4: 0x00000001002c84b5 qemu-system-arm`main_loop_wait [inlined] os_host_main_loop_wait(timeout=<unavailable>) + 191 at main-loop.c:242
frame #5: 0x00000001002c83f6 qemu-system-arm`main_loop_wait(nonblocking=<unavailable>) + 278 at main-loop.c:494
frame #6: 0x000000010014961a qemu-system-arm`qemu_main [inlined] main_loop + 73 at vl.c:1789
frame #7: 0x00000001001495d1 qemu-system-arm`qemu_main(argc=<unavailable>, argv=<unavailable>, envp=<unavailable>) + 17057 at vl.c:4353
frame #8: 0x000000010029b45e qemu-system-arm`-[QemuCocoaAppController startEmulationWithArgc:argv:](self=<unavailable>, _cmd=<unavailable>, argc=<unavailable>, argv=<unavailable>) + 30 at cocoa.m:897
Do these guest images and command lines work on Linux QEMU? (The most common cause of "nothing happens" is "wrong kernel for this board" or similar misconfiguration, where QEMU is correctly emulating a crashed guest that never made any output...)
Ah, good question! I found an image and instructions at http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu#Using_QEMU_without_libvirt that was a bit easier to work through, and sure enough, it works on Linux but not on OS X.
Linux precise64 3.2.0-37-generic:
vagrant@precise64:/opt/qemu-images/arm/fedora$ /home/vagrant/qemu-2.2.0/arm-softmmu/qemu-system-arm -M versatilepb -kernel zImage-qemu-versatile-3.0.8-4.fc17.armv5tel -hdc rootfs-f12 -append "root=0800 console=ttyAMA0" -nographic
audio: Could not init `oss' audio driver
Uncompressing Linux... done, booting the kernel.
Linux version 3.0.8 (jcapik@vega) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33.fa1)) #16 Wed Mar 28 15:07:56 CEST 2012
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177
CPU: VIVT data cache, VIVT instruction cache
Machine: ARM-Versatile PB
Memory policy: ECC disabled, Data cache writeback
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
...
-------------------------
OS X (just built QEMU 2.2.0 from source):
$ /Users/epall/bigcode/qemu/arm-softmmu/qemu-system-arm -M versatilepb -kernel zImage-qemu-versatile-3.0.8-4.fc17.armv5tel -hdc rootfs-f12 -append "root=0800 console=ttyAMA0" -nographic
Uncompressing Linux... done, booting the kernel.
That zImage works for me with QEMU commit ab0302ee76 on OSX 10.9.5 (at least it boots fine to the point of the kernel complaining it couldn't find the rootfs, because I didn't bother to build that.) I tested with the v2.2.0 tag and that works fine too.
Sanity check: use md5sum to check that the images you ended up with on OSX and Linux are actually the same and didn't get corrupted in download somehow. Otherwise I'm not sure what's going on.
Peter, the bug occurs when mounting the rootfs.
I can reproduce this bug too, with a kernel that works perfectly on QEMU on linux, windows and linux running on the same mac under vmware. In the case where I ran it under vmware on the mac the raspi kernel is the same file shared between the host os (os x) and the guest (linux) os.
Here's how I built QEMU on my brandy new mac
34 xcode-select --install
35 ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
38 brew doctor
47 brew install pkg-config
51 git checkout 2b7b4b3 Library/Formula/qemu.rb
53 $: brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb
54 brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb
55 brew install qemu --env=std --cc=gcc-4.2
56 cd
57 cd Desktop/qemu
here's what happens when I run it:
GSSLA40052111:Qemu jgallun$ cat pi.sh
#!/bin/sh
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2014-09-09-wheezy-raspbian.img
I've attached a screenshot of what happens when I boot this kernel on the mac.
The kernel I used in this example came from this website: http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/
> brew install qemu --env=std --cc=gcc-4.2
Aha. Don't do that, that's an ancient gcc. Use the system 'clang' (which configure should pick by default).
Thanks for the quick response. Being a total mac n00b I just followed the directions in the top google link for installing qemu on os x and I ended up where I did. I replaced the old version of the qemu formula in my brew library with the current one and re-installed and all is well, running qemu 2.2.0. Not that it matters, but the directions I followed have you checkout an old version of qemu (1.1.0) that won't compile with clang or a modern gcc, hence the ancient version of gcc
|