No, the notice does not appear without pci=realloc,assign-busses. The iGPU  stays at its POST bus (0x6A = 106), VFCT matches directly, and it fetches the VBIOS without any mismatch.                                                                                                                                           

Hi Oz,

On 7/8/26 07:36, Oz Tiram wrote:

Hi Mario,

Tested on a Morefine MNAS X1 AI Workstation (AMD Ryzen 7 Pro 8845HS / Radeon 780M iGPU) with pci=realloc,assign-busses.

The VFCT entry for the iGPU has PCIBus=106 (0x6A, recorded at POST) while the
runtime bus is 11 (0x0B). Your patch fires exactly as expected:

   amdgpu 0000:0b:00.0: amdgpu: VFCT bus number mismatch: table 106 != runtime 11,
       matching by device identity (vendor 0x1002 device 0x1900)
   amdgpu 0000:0b:00.0: amdgpu: Fetched VBIOS from VFCT

The iGPU initialises fully and drives the framebuffer.

One minor nit: the dev_notice format string ends with \\n (two characters) rather
than \n. The resulting kernel message has a literal "\n" at the end. Same issue
exists in the nearby "too short #2" dev_info -- not introduced by your patch, but
might be worth cleaning up.

Tested-by: Oz Tiram <oz@shift-computing.de>

Thanks for confirming.  Before I split up this patch and post it in smaller logical pieces can you confirm my proposed root cause is right that this issue happens because "pci=realloc,assign-busses" was on your kernel command line?

If you drop that - does this notice still come up?

Thanks,

On 7/6/26 02:56, Mario Limonciello wrote:

On 7/5/26 14:10, Oz Tiram wrote:

Hi Mario,

   To make sure I understand correctly: are you suggesting that the bus
   number in the VFCT was legitimate at BIOS POST time, and that
   pci=realloc,assign-busses is what changes it at runtime, causing the
   mismatch?

That's what it sounds like right now.  You can easily drop all the superfluous kernel command line optiosn and see.

   I'm not familiar enough with the PCI subsystem to know the right way to
   implement that — could you point me in the right direction?

Well there's a variety of ways to do it.  But how about we start here - if we make that specific busnr match optional and instead make a VID/DID match.

See if the attached patch helps.

   Oz

On 7/5/26 20:37, Mario Limonciello wrote:

On 7/5/26 05:04, Oz Tiram wrote:

APUs (e.g. AMD Radeon 780M / HawkPoint, PCI 1002:1900) have no
dedicated VBIOS ROM chip.  amdgpu_get_bios_apu() attempts four paths
before giving up:

   1. ACPI VFCT table
   2. VRAM BAR read
   3. ROM BAR read
   4. platform BIOS

On some systems all four fail.  The specific case motivating this patch
is a hybrid graphics machine (dGPU + APU) where:

   - The VFCT table contains the iGPU entry but with a stale PCIBus value
     from BIOS POST time (0x6A).  When the kernel boots with
     pci=realloc,assign-busses, PCI bus numbers are reassigned dynamically
     and the iGPU lands on bus 0x0B at runtime. amdgpu_acpi_vfct_bios()
     matches entries by bus number, so the entry is never found.
   - The VRAM BAR is unmapped at probe time.
   - The ROM BAR is zero (PCI firmware did not assign it).
   - No platform BIOS mapping exists.

The UEFI GOP driver initialises the iGPU successfully for early display,
confirming the hardware is functional.  The VBIOS image data embedded in
the VFCT is also valid; only the PCIBus metadata is wrong.

So the BIOS on this machine is actually totally fine; it's just when the kernel is booted to reassign busses there is a problem?

In that case; why not detect the kernel was booted this way and keep track of the original bus number when reassigned to avoid the issue?

The firmware
file can be extracted directly from the VFCT using dd:

   dd if=/sys/firmware/acpi/tables/VFCT bs=1 skip=$((0x68)) count=16896 \
      of=/lib/firmware/amdgpu/1002_1900.bin

(0x68 is the byte offset of the VBIOS image after the ACPI table header
and VFCT_IMAGE_HEADER; the image length 16896 comes from the ImageLength
field in VFCT_IMAGE_HEADER.)

The driver then prints "Unable to locate a BIOS ROM" and refuses to
bind, leaving the APU completely unusable under Linux.

Add a fifth fallback: request a firmware file named
"amdgpu/<vendor>_<device>.bin" (e.g. "amdgpu/1002_1900.bin") via
request_firmware().  This allows a VBIOS image extracted as above to be
placed in /lib/firmware/ and makes the binding succeed without patching
ACPI tables or BIOS.

The fallback is only reached if all existing paths have already failed,
so there is no regression risk for boards where VFCT or ROM BAR work.

What happens if the VBIOS changes in another way one boot to another? You might have some other stateful information that isn't updated.

The whole thing to me feels like a hack for a behavior we can control in the kernel when doing reassignments.

Signed-off-by: Oz Tiram <oz@shift-computing.de>
---
v2: Fix commit message: clarify that VFCT contains the iGPU entry but
     with a stale PCIBus from BIOS POST that mismatches the runtime bus
     number assigned by pci=realloc,assign-busses.  Explain that the VBIOS
     image data is valid and document the dd extraction command and byte
     offsets.  Note that the UEFI GOP driver initialises the iGPU
     successfully, confirming the hardware is functional.

  drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 23 +++++++++++++++++++ ++++
  1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c b/drivers/ gpu/ drm/amd/amdgpu/amdgpu_bios.c
index aa039e148a5e..86064c753b09 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -26,6 +26,7 @@
   *          Jerome Glisse
   */
  +#include <linux/firmware.h>
  #include "amdgpu.h"
  #include "atom.h"
  @@ -457,6 +458,28 @@ static bool amdgpu_get_bios_apu(struct amdgpu_device *adev)
          goto success;
      }
  +    {
+        const struct firmware *fw;
+        char fw_name[32];
+        size_t fw_size;
+
+        snprintf(fw_name, sizeof(fw_name), "amdgpu/%04x_%04x.bin",
+             adev->pdev->vendor, adev->pdev->device);
+        if (request_firmware(&fw, fw_name, adev->dev) == 0) {
+            adev->bios = kmemdup(fw->data, fw->size, GFP_KERNEL);
+            fw_size = fw->size;
+            release_firmware(fw);
+            if (!adev->bios || !check_atom_bios(adev, fw_size)) {
+                amdgpu_bios_release(adev);
+            } else {
+                adev->bios_size = fw_size;
+                dev_info(adev->dev, "Fetched VBIOS from firmware file %s\n",
+                     fw_name);
+                goto success;
+            }
+        }
+    }
+
      dev_err(adev->dev, "Unable to locate a BIOS ROM\n");
      return false;