1 files changed, 71 insertions, 0 deletions
diff --git a/results/classifier/118/none/1797262 b/results/classifier/118/none/1797262
new file mode 100644
index 000000000..ca9ed5c90
--- /dev/null
+++ b/results/classifier/118/none/1797262
@@ -0,0 +1,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.
+