https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c1 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kernel-bugs@opensuse.org |tzimmermann@suse.com --- Comment #1 from Fabian Vogt --- Ping -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c3 --- Comment #3 from Fabian Vogt --- (In reply to Thomas Zimmermann from comment #2)

This uses virtio_gpu. I assume it runs in an emulator or virtual machine?

Correct. Other emulated hardware didn't work either (IIRC -vga std) -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c5 --- Comment #5 from Fabian Vogt --- (In reply to Thomas Zimmermann from comment #4)

(In reply to Fabian Vogt from comment #3)

...

(In reply to Thomas Zimmermann from comment #2)

...

This uses virtio_gpu. I assume it runs in an emulator or virtual machine?

Correct. Other emulated hardware didn't work either (IIRC -vga std)

VGA requires a VGA BIOS, which is x86 code.

If the firmware interface and GRUB have video output, GOP is present, so this shouldn't matter.

Under regular aarch64 systems (e.g., Rpi) the firmware's framebuffer is listed in the device tree. But there is no DT here; just UEFI.

I've installed MicroOS in Aarch64 qemu to test. The kernel config is correct. There is some support for graphics in the early boot stages (GRUB).

Does efifb need more than just EFI GOP availability? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c6 --- Comment #6 from Thomas Zimmermann --- Here are the results of my investigation so far. The kernel tries to acquire the UEFI boot framebuffer via find_gop() [1]. It fails for all available results at the pixel_format test at [2]. The firmware only supports the BitBlt() EFI call to read/write framebuffer data. It's a boot service, so it's gone after the kernel initialized. We cannot use it. I've tested with kernel's going back to v6.4. It's always reproducible. To fix this problem, we have modify qemu's OVMF firmware to provide a pixel format and a framebuffer to which we can memcpy(). AFAICT a pixel format of PIXEL_BIT_MASK [3] would do this. [1] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/go... [2] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/go... [3] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ef... -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c7 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Virtualization:Tools Assignee|tzimmermann@suse.com |virt-bugs@suse.de --- Comment #7 from Fabian Vogt --- That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/952b5cf94c8727b65e04d3d507c0134743be2...). virtio-vga is not available in qemu-system-aarch64 though. So a question for the virtualization team (qemu + ovmf): What's the right controller to use to get this to work? I guess ramfb might work but it's too limited to be usable in practice. -- You are receiving this mail because: You are on the CC list for the bug.