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

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

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.

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