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

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

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