Issue
I'm trying to run a Yocto Raspberry Pi 2 build on qemu-system-arm
.
I got this far:
$ qemu-system-arm -version
QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.5)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
$ qemu-system-arm \
-M raspi2 \
-cpu arm1176 \
-dtb ./tmp/deploy/images/raspberrypi2/bcm2709-rpi-2-b.dtb \
-sd ./tmp/deploy/images/raspberrypi2/berrynux-image-raspberrypi2.rootfs.rpi-sdimg \
-m 1G \
-smp 1 \
-nographic \
-kernel ./kernel-qemu \
-append "rw earlyprintk loglevel=8 console=ttyS0 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" \
-serial mon:stdio
Execution hangs with:
WARNING:
Image format was not specified for
'./tmp/deploy/images/raspberrypi2/berrynux-image-raspberrypi2.rootfs.rpi-sdimg' and probing guessed raw.
Automatically detecting the format is dangerous for
raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
The kernel produced by meta-raspberrypi (kernel7.img) immediately breaks qemu with:
qemu-system-arm: Trying to execute code outside RAM or ROM at 0xe0833006
so i'm using kernel-qemu-4.4.34-jessie
instead (tried stretch and wheezy, same result - hang)
Not ever sure where to start debugging here, is this even attempting to boot? Can i hammer it to give me some useful output? Do i need a specially baked kernel, and if so, where do i get it from?
strace
didn't get me anywhere (or i don't know how to interpret the output):
...
openat(AT_FDCWD, "./kernel-qemu-4.4.34-jessie", O_RDONLY) = 11
lseek(11, 0, SEEK_END) = 3024048
mmap(NULL, 3026944, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4ed8106000
lseek(11, 0, SEEK_SET) = 0
read(11, "\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341"..., 3024048) = 3024048
close(11) = 0
access("./tmp/deploy/images/raspberrypi2/bcm2709-rpi-2-b.dtb", R_OK) = 0
openat(AT_FDCWD, "./tmp/deploy/images/raspberrypi2/bcm2709-rpi-2-b.dtb", O_RDONLY) = 11
lseek(11, 0, SEEK_END) = 16693
close(11) = 0
openat(AT_FDCWD, "./tmp/deploy/images/raspberrypi2/bcm2709-rpi-2-b.dtb", O_RDONLY) = 11
lseek(11, 0, SEEK_END) = 16693
lseek(11, 0, SEEK_SET) = 0
read(11, "\320\r\376\355\0\0A5\0\0\0H\0\0;0\0\0\0(\0\0\0\21\0\0\0\20\0\0\0\0"..., 16693) = 16693
close(11) = 0
futex(0x563f38608c3c, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x563f383d040c, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x563f384305cc, FUTEX_WAKE_PRIVATE, 2147483647) = 1
ppoll([{fd=0, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout)
futex(0x563f372cac00, FUTEX_WAKE_PRIVATE, 1) = 1
ppoll([{fd=0, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout)
ppoll([{fd=0, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout)
The POLLIN
event repeats indefinitely every second.
The SD card image boots just fine on real hardware Pi2.
EDIT
I copied over kernel7.img
and bcm2709-rpi-2-b.dtb
from the latest Raspbian Stretch image and i'm stil getting the same exact hang. I'm starting to think there's something screwy with my QEMU build - it's the stock Ubuntu 17.10 .deb package.
EDIT #2
Compiled qemu-2.12.0-rc2
from source, same deal. I must be doing something terribly wrong.
Solution
"Nothing happens" and "tried to execute from a bogus address" are often the result of either:
- misconfigured kernel (is this kernel definitely intended to boot on the raspi2 board, and not on something else?)
- something goes wrong in early boot before the kernel manages to produce output (though usually this causes a hang rather than a bad-address output)
For the latter, assuming this really is a raspi2 kernel, you might try using earlycon=pl011,0x3f201000 in your kernel append arguments. (The Linux kernel can produce earlycon output for the PL011 UART, but not for the raspi-specific 'mini UART'.)
I would suggest also dropping "-nographic" and "-serial mon:stdio" for the moment. Then you can use the graphical UI to check both UART outputs. (You can do this without using the GUI by redirecting them both correctly using two lots of -serial command line options, but then you have to figure out sensible places to send them; the GUI's simpler.) The first serial port will be the PL011, and the second the mini-UART, so if you only tell QEMU where to send the first serial port output and the guest is writing to the second, you'll never see it.
Answered By - Peter Maydell
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.