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

[Oz Tiram <oz@shift-computing.de>]

[-- Attachment #1: Type: text/plain, Size: 8719 bytes --]

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.


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

[-- Attachment #2: Type: text/html, Size: 15118 bytes --]