SchOS/kernel/drivers/gpu
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz ff0acfc913 gfx: a framebuffer at physical zero is not a framebuffer
Booting with a virtio-gpu as the *only* display reboot-looped. Not a hang, not
a panic: the firmware came back round to the boot menu, started the loader
again, and did it again, for ever, with nothing to say why.

virtio-gpu has no linear aperture, so OVMF's virtio GOP implements Blt and
nothing else. On a machine with one and nothing else, the firmware reports a
width and a height and a FrameBufferBase of **zero**:

    schos: framebuffer 0x0000000000000000 0x500x0x320

Two places took that at face value.

**kmain() tested `if (bi.ptr && ...)` with bi.ptr already run through P2V()**,
and P2V(0) is KERNBASE, which is not zero. So the guard could not fail -- and
its own comment, three lines above, said "drawing into address zero is a worse
failure than staying quiet". The intent was exactly right and the test could
never enforce it. It reads the physical value first now and tests that.

**vga_fb_init() attached the scanout regardless**, one layer down, so fixing
kmain alone just moved the same write.

Either one had gfx_clear() write four megabytes over physical 0: the real-mode
IVT, the BIOS data area, the AP trampoline at 0x7000, the early page tables.
Hence a reset with no output -- there was nothing left to run.

Both refuse now, and the refusal says what it is:

    vga: firmware reported a 1280x800 display with no framebuffer address;
         no graphical console

A machine with no usable linear framebuffer gets no graphical console. That is
the truth about it, and the serial line still has everything.

**It still does not reach a shell on such a machine**, and that is recorded
rather than implied: the console path assumes a framebuffer -- vt_init()
reports a terminal of `0 by 0` cells -- and that path has never been exercised.
What this fixes is a machine that destroyed low memory and reset; what it does
not do is make a headless boot work. Supported remains stdvga, with virtio-gpu
optional beside it, which is what docs/architecture/graphics.md already said.

Both supported configurations verified: stdvga alone and stdvga with
virtio-gpu, one boot each, no traps, socktest and memfdtest green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-22 14:58:21 +02:00
..
vga gfx: a framebuffer at physical zero is not a framebuffer 2026-09-22 14:58:21 +02:00
virtio_gpu boot: one line when it works, all of it when it does not 2026-09-14 21:19:50 +02:00