1 files changed, 89 insertions, 0 deletions
diff --git a/results/classifier/118/all/1914535 b/results/classifier/118/all/1914535
new file mode 100644
index 000000000..72086ddc4
--- /dev/null
+++ b/results/classifier/118/all/1914535
@@ -0,0 +1,89 @@
+debug: 0.968
+peripherals: 0.965
+graphic: 0.964
+register: 0.958
+mistranslation: 0.956
+boot: 0.951
+kernel: 0.949
+files: 0.947
+vnc: 0.946
+architecture: 0.944
+semantic: 0.939
+socket: 0.937
+permissions: 0.930
+arm: 0.927
+network: 0.911
+device: 0.902
+ppc: 0.898
+PID: 0.896
+VMM: 0.868
+virtual: 0.864
+performance: 0.837
+assembly: 0.833
+x86: 0.825
+user-level: 0.820
+risc-v: 0.815
+TCG: 0.815
+hypervisor: 0.798
+i386: 0.763
+KVM: 0.543
+
+PL110 8-bit mode is not emulated correctly
+
+When the emulated pl110/pl111 is switched programmatically to 8-bit color depth mode, the display is drawn green and blue, but the real PL110 displays grayscale in 8-bit mode.
+
+The bug appears in qemu-system-arm version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u8) and qemu-system-arm version 5.2.50 (v5.2.0-1579-g99ae0cd90d).
+
+Do you have a test case (QEMU command line and all necessary image files) that demonstrates this, please ?
+
+
+Archive with all the demo files (kernel, disk image, dtb file, screenshot of the bug):
+https://avevad.ddns.net/storage/qbug.tar
+QEMU commandline:
+qemu-system-arm -serial stdio -M vexpress-a15 -dtb vexpress-v2p-ca15_a7.dtb -smp 4  -m 256M -kernel zImage_new  -append "console=ttyAMA0 root=/dev/mmcblk0p1 loglevel=9 vt.global_cursor_default=0 video=vfb:" -drive if=sd,format=raw,file=disk
+
+
+Lucky I looked at your screenshot, as half the repro instructions are only given in that!
+When the guest gets to a shell prompt, one needs to type:
+
+# fbset -depth 8
+# fbset
+# dd if=/dev/urandom of=/dev/fb0
+
+
+So, were you able to reproduce it?
+
+Anyway, on first investigation I'm not sure what QEMU's pl11x model is doing wrong. The 8-bit mode is a palette-based setup, where the guest must program in the RGB values it wants to use into the palatte registers as RGB555 data:
+ https://developer.arm.com/documentation/ddi0293/c/programmer-s-model/register-descriptions/256x16-bit-color-palette-registers?lang=en
+and if you add some debug printing to QEMU you can see the guest writing in 
+a variety of definitely-not-shades-of-grey values to the palette, so it's not surprising that it comes back as not-grey.
+
+I think
+https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/amba-clcd.c#L343
+is where the driver is writing to the palette and it definitely thinks the display is pseudocolor, not greyscale.
+
+
+So how can I manage it to display grayscale?
+
+On Mon, 22 Feb 2021 at 12:18, Vadim Averin <email address hidden> wrote:
+>
+> So how can I manage it to display grayscale?
+
+Programme the palette with exclusively shades of grey ?
+
+The question here really is: is QEMU behaving differently
+from the real vexpress-a15 hardware here? If it is, then where
+is the behaviour divergence coming from, given that it looks
+from the docs at least as if the QEMU implementation is doing
+what the docs say it should do. If QEMU isn't behaving
+differently from real hardware, then that's just a guest
+software problem.
+
+-- PMM
+
+
+Well... I don't have any ARM Versatile Express board. Also, documentation and manuals are not saying much about it
+
+I think unless you can either (a) show that QEMU is behaving differently from the real hardware or (b) point at what bit of the hardware documentation QEMU's implementation is not following, then this doesn't really sound like it's a bug in QEMU.
+
+