blob: ca9ed5c90b6680ba22bc566863fc64b60b0bc9c6 (
plain) (
blame)
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
|
kernel: 0.599
boot: 0.583
device: 0.570
architecture: 0.516
performance: 0.500
graphic: 0.491
files: 0.482
semantic: 0.446
socket: 0.426
arm: 0.425
permissions: 0.408
mistranslation: 0.313
peripherals: 0.302
network: 0.278
user-level: 0.275
PID: 0.265
register: 0.260
ppc: 0.256
vnc: 0.222
virtual: 0.207
VMM: 0.181
risc-v: 0.166
debug: 0.166
hypervisor: 0.143
x86: 0.123
TCG: 0.111
KVM: 0.088
i386: 0.088
assembly: 0.073
qemu arm no longer able to boot RPI Kernels
Since RPi Kernel 1.20170427, qemu is no longer able to emulate the Rasberry Pi, as the linux kernel is complaining about timing issues.
Old kernel output - https://pastebin.com/wvkneNNF
New kernel output - https://pastebin.com/QTwgCkV2
Note that the actual error is caused by the kernel being unable to get the timing source for the mmc (Line 160), which causes an unable-to-mount-root panic. There are other issues with the serial port returning an invalid speed, which displays a divide-by-zero error, which is PROBABLY a symptom of the same root cause.
This is simple to replicate - The last working kernel is available here:
https://github.com/raspberrypi/firmware/tree/1.20170405/boot
Download kernel7 and the dtb, and try to boot with (for example)
qemu-system-aarch64 -M raspi2 -kernel kernel7.img -dtb bcm2709-rpi-2-b.dtb -serial stdio -sd noobs.img -append "root=/dev/mmcblk0p2 init=/bin/bash"
This works, and boots successfully.
However, if you replace the kernel7.img and dtb with ones taken from https://github.com/raspberrypi/firmware/tree/1.20170427/boot it will NOT boot because of various clock timing issues (as in the second paste)
Isn't this likely due to the newer kernel accessing hardware we are not emulating properly?
On 19 October 2018 at 12:59, Alex Bennée <email address hidden> wrote:
> Isn't this likely due to the newer kernel accessing hardware we are not
> emulating properly?
Yes, it will be the missing cprman emulation. There was another
bug/thread on this recently.
thanks
-- PMM
latest series posted:
https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00191.html
Should be now fixed by commits 74de7145fd6..83ad4695478 (CPRMAN model added).
Released with QEMU v5.2.0.
|