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

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

[Mario Limonciello]

On 11/1/26 17:31, Arnaud BERTRAND wrote:
> Hi Mario, Alex,
> 
> I have two dGPUs : a Radeon RX 6800
> XT and a Radeon RX 6800. They both report the same PCI identity
> 1002:73bf and each has a different VBIOS.
> I hit the same VFCT bus-number mismatch on 7.2.10, but with a different
> outcome: on my machine the device-identity fallback actively breaks the 
> second
> dGPU.
> I patched my kernel to remove the fallback, but I would like to have a 
> better solution for my use case.
> Would it be possible to apply the patch only to APUs ? That would keep 
> Oz's APU case working but a dGPU with a stale bus number would fall 
> through to its own ROM, which is the source that is
> guaranteed to match the card in the slot.
> I can provide more details if needed, I am out of my depth here.
> Thanks
> Arnaud

Can you please have a try with this patch series?

https://lore.kernel.org/linux-pci/20261027-vfct-regression-v4-0-0e7190e39c2c@amd.com/

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

[Mario Limonciello]

On 6/21/26 13:01, 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:

That's pretty odd to me.  Isn't this a BIOS bug?  Can you share more 
about why all of these are failing?

Does the UEFI GOP driver work?

> 
>    - The VFCT table is absent or contains only the discrete GPU entry
>      (e.g. when a custom ACPI override is present for the dGPU only).
>    - The VRAM BAR is unmapped at probe time.
>    - The ROM BAR is zero (PCI firmware did not assign it; observed even
>      with pci=realloc,assign-busses).
>    - No platform BIOS mapping exists.
> 
> The driver then prints "Unable to locate a BIOS ROM" and refuses to
> bind, leaving the APU completely unusable under Linux even though the
> hardware is functional.
> 
> 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 from the
> running hardware 

I thought you just said this didn't work.  How did you extract it?

> to be shipped as a firmware blob in /lib/firmware/ and
> makes the binding succeed without any change to the ACPI tables.
> 
> 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.
> 
> Signed-off-by: Oz Tiram <oz@shift-computing.de>
> ---
> v2: Validate the fetched firmware with check_atom_bios() before accepting
>      it, consistent with all other VBIOS discovery paths.  Save fw->size
>      before release_firmware() so it remains valid for the size check.
>      Release the buffer via amdgpu_bios_release() if validation fails.
> 
>   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;
>   

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

[Oz Tiram]

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

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

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

[Mario Limonciello]

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

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

[Oz Tiram]

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?

   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?

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

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

[Mario Limonciello]

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



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: 0001-drm-amdgpu-radeon-Fix-VFCT-bus-number-matching-with-.patch --]
[-- Type: text/x-patch, Size: 8107 bytes --]

From 42ac2fe3085cc3593523ac3e514bc36616078b4f Mon Sep 17 00:00:00 2001
From: Mario Limonciello <mario.limonciello@amd.com>
Date: Sun, 5 Jul 2026 15:48:05 -0500
Subject: [PATCH] drm/amdgpu/radeon: Fix VFCT bus number matching with soft
 filter

On systems where PCI bus renumbering occurs (e.g. pci=realloc,
resource conflicts), the runtime bus number may differ from the
BIOS POST bus number recorded in the VFCT table. This causes
amdgpu_acpi_vfct_bios() to fail finding the VBIOS even though
the correct device entry exists.

Introduce amdgpu_acpi_vfct_match() which treats the bus number
as a soft filter: vendor/device/function identity is the hard
requirement, while exact bus match is the preferred path. When
bus numbers disagree but device identity matches, accept the
VFCT entry and log a dev_notice for diagnostics.

Apply the same fix to radeon_acpi_vfct_bios().

While updating radeon, also modernize the error handling:
- Replace DRM_ERROR with dev_info/dev_notice
- Remove legacy goto out + acpi_put_table pattern (acpi_put_table
  was removed from the kernel)
- Use early return instead of goto for cleaner control flow

Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 48 +++++++++++++--
 drivers/gpu/drm/radeon/radeon_bios.c     | 78 +++++++++++++++++-------
 2 files changed, 99 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index 35d04e69aec0..fa730af5e979 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -370,6 +370,46 @@ static bool amdgpu_read_disabled_bios(struct amdgpu_device *adev)
 		false : amdgpu_asic_read_disabled_bios(adev);
 }
 
+/**
+ * amdgpu_acpi_vfct_match() - Check if a VFCT entry matches the device
+ * @adev: AMDGPU device
+ * @vhdr: VFCT image header to check
+ *
+ * VFCT entries contain the PCI bus number as recorded during BIOS POST.
+ * On systems where the kernel renumbers PCI buses (e.g. pci=realloc or
+ * resource conflicts), the runtime bus number may differ from the POST
+ * value.  Match by device identity (vendor + device + function) and use
+ * the bus number as a preference: exact bus match is preferred, but when
+ * the bus numbers disagree we accept the entry if the device identity
+ * matches.
+ *
+ * Returns: 0 on match, -ENODEV on no match
+ */
+static int amdgpu_acpi_vfct_match(struct amdgpu_device *adev,
+				  VFCT_IMAGE_HEADER *vhdr)
+{
+	/* Vendor and device IDs must always match */
+	if (vhdr->VendorID != adev->pdev->vendor ||
+	    vhdr->DeviceID != adev->pdev->device)
+		return -ENODEV;
+
+	if (vhdr->PCIDevice != PCI_SLOT(adev->pdev->devfn) ||
+	    vhdr->PCIFunction != PCI_FUNC(adev->pdev->devfn))
+		return -ENODEV;
+
+	/* Exact bus number match - preferred */
+	if (vhdr->PCIBus == adev->pdev->bus->number)
+		return 0;
+
+	/* Bus mismatch but device identity matches (PCI renumbering case) */
+	dev_notice(adev->dev,
+		   "VFCT bus number mismatch: table %u != runtime %u, "
+		   "matching by device identity (vendor 0x%04x device 0x%04x)\\n",
+		   vhdr->PCIBus, adev->pdev->bus->number,
+		   adev->pdev->vendor, adev->pdev->device);
+	return 0;
+}
+
 #ifdef CONFIG_ACPI
 static bool amdgpu_acpi_vfct_bios(struct amdgpu_device *adev)
 {
@@ -406,11 +446,7 @@ static bool amdgpu_acpi_vfct_bios(struct amdgpu_device *adev)
 		}
 
 		if (vhdr->ImageLength &&
-		    vhdr->PCIBus == adev->pdev->bus->number &&
-		    vhdr->PCIDevice == PCI_SLOT(adev->pdev->devfn) &&
-		    vhdr->PCIFunction == PCI_FUNC(adev->pdev->devfn) &&
-		    vhdr->VendorID == adev->pdev->vendor &&
-		    vhdr->DeviceID == adev->pdev->device) {
+		    !amdgpu_acpi_vfct_match(adev, vhdr)) {
 			adev->bios = kmemdup(&vbios->VbiosContent,
 					     vhdr->ImageLength,
 					     GFP_KERNEL);
@@ -424,7 +460,7 @@ static bool amdgpu_acpi_vfct_bios(struct amdgpu_device *adev)
 		}
 	}
 
-	dev_info(adev->dev, "ACPI VFCT table present but broken (too short #2),skipping\n");
+	dev_info(adev->dev, "ACPI VFCT table present but broken (too short #2),skipping\\n");
 	return false;
 }
 #else
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
index 3a8c5199a0fe..5938a8ed6e73 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -596,21 +596,60 @@ static bool radeon_read_disabled_bios(struct radeon_device *rdev)
 		return legacy_read_disabled_bios(rdev);
 }
 
+/**
+ * radeon_acpi_vfct_match() - Check if a VFCT entry matches the device
+ * @rdev: Radeon device
+ * @vhdr: VFCT image header to check
+ *
+ * VFCT entries contain the PCI bus number as recorded during BIOS POST.
+ * On systems where the kernel renumbers PCI buses (e.g. pci=realloc or
+ * resource conflicts), the runtime bus number may differ from the POST
+ * value.  Match by device identity (vendor + device + function) and use
+ * the bus number as a preference: exact bus match is preferred, but when
+ * the bus numbers disagree we accept the entry if the device identity
+ * matches.
+ *
+ * Returns: 0 on match, -ENODEV on no match
+ */
+static int radeon_acpi_vfct_match(struct radeon_device *rdev,
+				  VFCT_IMAGE_HEADER *vhdr)
+{
+	/* Vendor and device IDs must always match */
+	if (vhdr->VendorID != rdev->pdev->vendor ||
+	    vhdr->DeviceID != rdev->pdev->device)
+		return -ENODEV;
+
+	if (vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
+	    vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn))
+		return -ENODEV;
+
+	/* Exact bus number match - preferred */
+	if (vhdr->PCIBus == rdev->pdev->bus->number)
+		return 0;
+
+	/* Bus mismatch but device identity matches (PCI renumbering case) */
+	dev_notice(&rdev->pdev->dev,
+		   "VFCT bus number mismatch: table %u != runtime %u, "
+		   "matching by device identity (vendor 0x%04x device 0x%04x)\n",
+		   vhdr->PCIBus, rdev->pdev->bus->number,
+		   rdev->pdev->vendor, rdev->pdev->device);
+	return 0;
+}
+
 #ifdef CONFIG_ACPI
 static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
 {
 	struct acpi_table_header *hdr;
 	acpi_size tbl_size;
 	UEFI_ACPI_VFCT *vfct;
-	unsigned offset;
-	bool r = false;
+	unsigned int offset;
 
 	if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
 		return false;
 	tbl_size = hdr->length;
 	if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
-		DRM_ERROR("ACPI VFCT table present but broken (too short #1)\n");
-		goto out;
+		dev_info(&rdev->pdev->dev, "ACPI VFCT table present but broken (too short #1),skipping\n");
+		return false;
 	}
 
 	vfct = (UEFI_ACPI_VFCT *)hdr;
@@ -622,37 +661,34 @@ static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
 
 		offset += sizeof(VFCT_IMAGE_HEADER);
 		if (offset > tbl_size) {
-			DRM_ERROR("ACPI VFCT image header truncated\n");
-			goto out;
+			dev_info(&rdev->pdev->dev, "ACPI VFCT image header truncated,skipping\n");
+			return false;
 		}
 
 		offset += vhdr->ImageLength;
 		if (offset > tbl_size) {
-			DRM_ERROR("ACPI VFCT image truncated\n");
-			goto out;
+			dev_info(&rdev->pdev->dev, "ACPI VFCT image truncated,skipping\n");
+			return false;
 		}
 
 		if (vhdr->ImageLength &&
-		    vhdr->PCIBus == rdev->pdev->bus->number &&
-		    vhdr->PCIDevice == PCI_SLOT(rdev->pdev->devfn) &&
-		    vhdr->PCIFunction == PCI_FUNC(rdev->pdev->devfn) &&
-		    vhdr->VendorID == rdev->pdev->vendor &&
-		    vhdr->DeviceID == rdev->pdev->device) {
+		    !radeon_acpi_vfct_match(rdev, vhdr)) {
 			rdev->bios = kmemdup(&vbios->VbiosContent,
 					     vhdr->ImageLength,
 					     GFP_KERNEL);
-			if (rdev->bios)
-				r = true;
 
-			goto out;
+			if (!rdev->bios ||
+			    rdev->bios[0] != 0x55 || rdev->bios[1] != 0xaa) {
+				kfree(rdev->bios);
+				rdev->bios = NULL;
+				return false;
+			}
+			return true;
 		}
 	}
 
-	DRM_ERROR("ACPI VFCT table present but broken (too short #2)\n");
-
-out:
-	acpi_put_table(hdr);
-	return r;
+	dev_info(&rdev->pdev->dev, "ACPI VFCT table present but broken (too short #2),skipping\n");
+	return false;
 }
 #else
 static inline bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
-- 
2.53.0

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

[Oz Tiram]

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>

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

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

[Mario Limonciello]

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

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

[Mario Limonciello]

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

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

[Oz Tiram]

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,

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

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

[Mario Limonciello]

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

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

[Oz Tiram]

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.

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

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

[Mario Limonciello]

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

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

[Alex Deucher]

On Wed, Jul 8, 2026 at 1:59 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> 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.

It's allowed by the spec.  A number of apple systems use VFCT for
multu-GPU systems with the same GPU.

Alex

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

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

[Mario Limonciello]

On 7/8/26 13:02, Alex Deucher wrote:
> On Wed, Jul 8, 2026 at 1:59 PM Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>>
>>
>> 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.
> 
> It's allowed by the spec.  A number of apple systems use VFCT for
> multu-GPU systems with the same GPU.

But then what happens with the bus numbers?  They all need to be on the 
same bus?

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

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

[Alex Deucher]

On Wed, Jul 8, 2026 at 2:03 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 7/8/26 13:02, Alex Deucher wrote:
> > On Wed, Jul 8, 2026 at 1:59 PM Mario Limonciello
> > <mario.limonciello@amd.com> wrote:
> >>
> >>
> >>
> >> 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.
> >
> > It's allowed by the spec.  A number of apple systems use VFCT for
> > multu-GPU systems with the same GPU.
>
> But then what happens with the bus numbers?  They all need to be on the
> same bus?

I'm not sure.  As far as I know, the VFCT is populated by the sbios
based on the locations at boot time.  We can ask the vbios team for
more details.

Alex


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