You are not logged in.

#1 2026-03-21 13:47:08

t4em
Member
From: Hafar al-Batin, Saudi Arabia.
Registered: 2026-03-09
Posts: 2

[Solved] AMD iGPU in HP ELITEBOOK G754 G6-7 falls back to llvm-pipe.

My laptop's GPU has been broken for a while. Every boot, the amdgpu driver would fail with "Unable to locate a BIOS ROM" and fall back to software rendering. Minecraft was running at about 15 fps. Not great.


The driver looks for the GPU's VBIOS — a small firmware image that tells it how to initialise the hardware. On this laptop, it looks for it in the legacy VGA shadow region at physical address 0xc0000. The problem is that region is completely blank on this machine. The BIOS never populated it. Reading it returns 0xffff, which is just empty flash. And to make it worse, the CPU marks that region read-only after boot, so you can't write to it either. Attempts to inject the VBIOS there at runtime are silently discarded — dd reports success, the data is gone.

There's a second problem on top of that. The PCI bus host bridge only exposes a 48 KB window for that region, but the ROM BAR claims 128 KB. The kernel detects the mismatch and refuses to map it at all, so the driver never even gets to read the blank data — it fails before that point.

I spent a while trying to write the VBIOS directly into VRAM at 0xe0000000, thinking the driver would pick it up from there. It wouldn't. The driver hits the ROM BAR check first and gives up before it ever tries VRAM. The injection was landing correctly and being verified — the data was genuinely there — but the driver never saw it.
The fix

The amdgpu driver supports one other path: an ACPI table called VFCT, which can carry a complete VBIOS image. On UEFI systems, the firmware provides this automatically. On this legacy BIOS machine it's absent, but the Linux kernel lets you inject custom ACPI tables via the initramfs.

I wrote a small Python script that builds a correctly structured VFCT binary from the ROM file — the right headers, the right GPU device ID, the correct ACPI checksum — and placed it in /etc/initcpio/acpi/. Then I added a single line to /etc/mkinitcpio.conf pointing at it, rebuilt the initramfs, and rebooted.

The driver found the VBIOS on the first boot. GPU initialised. Hardware rendering working.

Before the fix, Minecraft was being rendered entirely by the CPU through llvmpipe. It was technically playable in the sense that it ran, but 15 fps in anything larger than a superflat world made it miserable. After the fix, the Vega 8 takes over and it runs properly — comfortably above 60 fps with reasonable settings. It's not a powerful GPU but it's night and day compared to software rendering.



During debugging I was reloading the amdgpu driver live to test each attempt without rebooting. This only works under Wayland. Under X11, unloading amdgpu while Xorg is running freezes the display server instantly because Xorg holds a hard kernel-level lock on the DRM device. Under Wayland the compositor handles the device disappearing gracefully and reconnects when the driver comes back. With the final fix this doesn't matter — the GPU works on every cold boot regardless of display server.



** STEPs TO SOLVE
1- downloading the VBIOS rom
2- building the VCFT table with initramfs
3- Register it with mkinitcpio
5- verify w glxinfo | grep renderer


أقَلُّ صُدودي أنّني لكَ مُبْغِضٌ
وأيْسَرُ هَجْري أنني عنكَ راحل

Offline

Board footer

Powered by FluxBB