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

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

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