Re: [PATCH v2] drm/amd/amdgpu: add firmware file fallback for APU VBIOS discovery

[Alex Deucher]

On Wed, Jul 8, 2026 at 2:03 PM Mario Limonciello
<mario.limonciello@xxxxxxx> wrote:
>
>
>
> On 7/8/26 13:02, Alex Deucher wrote:
> > On Wed, Jul 8, 2026 at 1:59 PM Mario Limonciello
> > <mario.limonciello@xxxxxxx> wrote:
> >>
> >>
> >>
> >> On 7/8/26 12:52, Oz Tiram wrote:
> >>> Hi Mario,
> >>>
> >>> Tested on 7.2-rc2 with your patch applied. The mismatch condition is
> >>> unchanged from 6.18.35:
> >>>
> >>>     amdgpu 0000:0b:00.0: VFCT bus number mismatch: table 106 != runtime 11,
> >>>         matching by device identity (vendor 0x1002 device 0x1900)
> >>>     amdgpu 0000:0b:00.0: Fetched VBIOS from VFCT
> >>>
> >>> Both GPUs initialise fully with your patch.
> >>>
> >>> I also tested 7.2-rc2 without pci=realloc,assign-busses to check whether
> >>> the pci/realloc changes fixed the dGPU probe failure. They did not -- the
> >>> dGPU still fails on 7.2-rc2:
> >>>
> >>>     amdgpu 0000:03:00.0: Fatal error during GPU init
> >>>     amdgpu 0000:03:00.0: probe with driver amdgpu failed with error -12
> >>>
> >>> Without the kernel argument the iGPU sits at its POST bus (0x6A), VFCT
> >>> matches directly, and it works fine -- but the dGPU is unusable.
> >>> pci=realloc,assign-busses remains necessary for this machine on 7.2-rc2,
> >>> which means the VFCT mismatch persists and your patch is still needed.
> >>>
> >>> Thank you for not giving up on me so quickly!
> >>> This is my first time working on such issue. It feels
> >>> daunting to modify kernel code.
> >>
> >> OK, in that case I will clean up and post the patches shortly.  You'll
> >> be able to use them for a workaround if everyone else is aligned.  The
> >> part I'm worried about with these is how they would interplay with a
> >> system with multiple of the same GPU.  But I don't believe we would be
> >> fetching VBIOS from VFCT in that case most likely?  Not sure.
> >
> > It's allowed by the spec.  A number of apple systems use VFCT for
> > multu-GPU systems with the same GPU.
>
> But then what happens with the bus numbers?  They all need to be on the
> same bus?

I'm not sure.  As far as I know, the VFCT is populated by the sbios
based on the locations at boot time.  We can ask the vbios team for
more details.

Alex


>
> >
> > Alex
> >
> >>
> >> We really shouldn't have to set pci=realloc,assign-busses on a design
> >> with all internal PCIe devices.  We should adjust resource allocation
> >> code for this case.
> >>
> >> So please start another another thread with the linux-pci mailing list
> >> on this issue, include a full dmesg showing what happens when you don't
> >> add the parameters and then what happens when you do (feel free to
> >> include/reference this patch in that thread too).
> >>
> >> If you want to use one, this is the kind of thing an LLM with access to
> >> a kernel checkout and both those dmesgs might be good at helping to
> >> propose a draft for a solution to the resource allocation code too.
> >>
> >> You can CC me on that linux-pci mailing list submission, and we'll see
> >> if we can come up with a better solution for you.
> >>
> >>>
> >>> Oz
> >>>
> >>>
> >>> On 7/8/26 18:39, Mario Limonciello wrote:
> >>>> On 7/8/26 11:35, Oz Tiram wrote:
> >>>>> Hi Mario,
> >>>>>
> >>>>> The GPU is internal. It's an AMD RADEON PRO W7800 48GB.
> >>>>> The kernel is built from gentoo-sources-6.18.35.
> >>>>>
> >>>>> I will test the latest sys-kernel/vanilla-sources (7.1.3) and let you
> >>>>> know.
> >>>>>
> >>>>> Best regards,
> >>>>
> >>>> Thanks. Can you please test 7.2-rc2?
> >>>>
> >>>> I'll clean up the workaround and propose it for review in parallel.
> >>>>
> >>>>>
> >>>>> Oz
> >>>>>
> >>>>> On 7/8/26 15:13, Mario Limonciello wrote:
> >>>>>>
> >>>>>> On 7/8/26 08:10, Oz Tiram wrote:
> >>>>>>> Hi Mario,
> >>>>>>>
> >>>>>>>   > If you drop that - does this notice still come up?
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> However, dropping the kernel argument is not an option on this
> >>>>>>> machine:
> >>>>>>> without it the discrete GPU (0x7449) fails to probe entirely:
> >>>>>>>
> >>>>>>>     amdgpu 0000:03:00.0: amdgpu: Fatal error during GPU init
> >>>>>>>     amdgpu 0000:03:00.0: probe with driver amdgpu failed with error -12
> >>>>>>>
> >>>>>>> The firmware BARs cannot be mapped without resource reallocation, so
> >>>>>>> pci=realloc,assign-busses is required for the dGPU, which in turn
> >>>>>>> reassigns
> >>>>>>> the iGPU to bus 0x0B and triggers the mismatch your patch resolves.
> >>>>>>
> >>>>>> Got it; thanks for clarifying.  I would like to dig a little bit
> >>>>>> futher into that though.  What kernel are you finding this behavior
> >>>>>> and can it still reproduce with 7.2-rc2 if it's older? There was a
> >>>>>> bunch of pci/realloc changes that happened in the last cycle that
> >>>>>> might have helped this.
> >>>>>>
> >>>>>> Also; is it an eGPU (external) or dGPU (internal)?
> >>>>>>
> >>>>>> If it's an dGPU IMO this is arguably a BIOS issue that not enough
> >>>>>> resources were applied in the first place.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Thank you,
> >>>>>>>
> >>>>>>> Oz
> >>>>>>>
> >>>>>>>
> >>>>>>> On 7/8/26 14:55, Mario Limonciello wrote:
> >>>>>>>> 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@xxxxxxxxxxxxxxxxxx>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> 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@xxxxxxxxxxxxxxxxxx>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>> 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;
> >>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
>