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

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

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