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

[Mario Limonciello <mario.limonciello@amd.com>]

On 7/8/26 13:02, Alex Deucher wrote:
> On Wed, Jul 8, 2026 at 1:59 PM Mario Limonciello
> <mario.limonciello@amd.com> 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?

> 
> 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@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;
>>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>