Hi,
Ok folks, here is a experimental patch series for a legacy free boot
framebuffer. If you want play with it I recommend getting the bits from
https://www.kraxel.org/cgit/qemu/log/?h=sirius/ramfb
because they come with an updated seabios and a new vgabios rom.
The boot framebuffer is expected to be configured by the firmware, so it
uses fw_cfg as interface. Initialization goes as follows:
(1) Check whenever etc/ramfb is present.
(2) Allocate framebuffer from RAM.
(3) Fill struct RAMFBCfg, write it to etc/ramfb.
Done. You can write stuff to the framebuffer now, and it should appear
automagically on the screen.
Note that this isn't very efficient because it does a full display
update on each refresh. No dirty tracking. Dirty tracking would have
to be active for the whole ram slot, so that wouldn't be very efficient
either. So it is *really* intended to be only active for a short time
at boot, before the guest loaded the drivers for the real display
hardware.
seavgabios is able to emulate vga text mode on top of a framebuffer, for
coreboot native graphics initialialization. Which works fine for
everything which writes text using the vgabios interface (basically
everyhing which works with sgabios).
So I hacked that up to work with ramfb. Right now it's proof-of-concept
code with too much cut+paste, so it will clearly need a bunch of
cleanups if this approach turns out to be workable. Look here:
https://www.kraxe.org/cgit/seabios/log/?h=ramfb
So, how to play?
There is ramfb-testdev. Standalone device, for testing purposes. Also
listens on vga ports and logs any access, so we can see the bad boys ;)
Use "qemu -vga none -device ramfb-testdev".
There is virtio-ramfb. Simlar to virtio-vga, but using ramfb instead of
adding vga compatibility. Shows how you can wire up ramfb support to
some display device. Unlike virtio-vga it should work fine on arm. Use
"qemu -vga none -device virtio-ramfb" for this one.
What works?
Boot loaders all use vgabios calls for text mode, so they show up just
fine. Also ipxe, seabios itself of course. So you can boot up your
linux guest. vesafb works too.
What doesn't work?
vgacon (direct vga hardware access).
Windows (bios mode). Boot logo shows up just fine. But at some point
windows does lots of vga register accesses (even though it sets the
video mode via vesa bios interface) and appears to be unhappy that
things don't work as expected because there is no actual vga hardware.
Future plans:
Try use that as vgpu boot display. Requires solving that windows issue
somehow, otherwise it's going to be a non-starter.
Trick László into writing a UEFI driver for that. Linux will use efifb
not vgacon then, and hopefully Windows doesn't try access vga registers
either.
Comments?
Hints on the windows issue anyone?
enjoy,
Gerd
Gerd Hoffmann (4):
[testing] update bios, add vgabios-ramfb
ramfb: simple boot framebuffer living in guest ram
add virtio-ramfb
add ramfb-testdev
include/hw/display/ramfb.h | 8 +++
hw/display/ramfb-testdev.c | 87 ++++++++++++++++++++++++++
hw/display/ramfb.c | 94 ++++++++++++++++++++++++++++
hw/display/virtio-ramfb.c | 149 +++++++++++++++++++++++++++++++++++++++++++++
hw/display/Makefile.objs | 5 +-
pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes
pc-bios/vgabios-ramfb.bin | Bin 0 -> 28160 bytes
7 files changed, 342 insertions(+), 1 deletion(-)
create mode 100644 include/hw/display/ramfb.h
create mode 100644 hw/display/ramfb-testdev.c
create mode 100644 hw/display/ramfb.c
create mode 100644 hw/display/virtio-ramfb.c
create mode 100644 pc-bios/vgabios-ramfb.bin
--
2.9.3
