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.