All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oz Tiram <oz@shift-computing.de>
To: Mario Limonciello <mario.limonciello@amd.com>,
	amd-gfx@lists.freedesktop.org
Cc: alexander.deucher@amd.com, christian.koenig@amd.com,
	airlied@gmail.com, simona@ffwll.ch,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] drm/amd/amdgpu: add firmware file fallback for APU VBIOS discovery
Date: Sun, 5 Jul 2026 21:10:59 +0200	[thread overview]
Message-ID: <42e07bbb-9384-4871-a345-e0fd6c00a772@shift-computing.de> (raw)
In-Reply-To: <a8339282-e3ef-4a4f-a135-968f94855e76@amd.com>

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

  reply	other threads:[~2026-07-05 19:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-21 17:32 [PATCH] drm/amd/amdgpu: add firmware file fallback for APU VBIOS discovery Oz Tiram
2026-06-21 17:50 ` sashiko-bot
2026-06-21 18:01 ` Oz Tiram
2026-06-21 18:09   ` sashiko-bot
2026-06-26 17:42   ` Mario Limonciello
2026-06-26 19:38     ` Alex Deucher
2026-07-05 10:01     ` Oz Tiram
2026-07-05 10:04     ` [PATCH v2] " Oz Tiram
2026-07-05 10:14       ` sashiko-bot
2026-07-05 18:37       ` Mario Limonciello
2026-07-05 19:10         ` Oz Tiram [this message]
2026-07-06  0:56           ` Mario Limonciello
2026-07-08 12:36             ` Oz Tiram
2026-07-08 12:55               ` Mario Limonciello
2026-07-08 13:10                 ` Oz Tiram
2026-07-08 13:13                   ` Mario Limonciello
2026-07-08 16:35                     ` Oz Tiram
2026-07-08 16:39                       ` Mario Limonciello
2026-07-08 17:52                         ` Oz Tiram
2026-07-08 17:59                           ` Mario Limonciello
2026-07-08 18:02                             ` Alex Deucher
2026-07-08 18:03                               ` Mario Limonciello
2026-07-08 18:12                                 ` Alex Deucher
2026-07-08 17:53                         ` Oz Tiram
2026-07-05 10:15     ` [PATCH] " Oz Tiram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42e07bbb-9384-4871-a345-e0fd6c00a772@shift-computing.de \
    --to=oz@shift-computing.de \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=simona@ffwll.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.