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: "Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"open list:DRM DRIVERS" <dri-devel@lists.freedesktop.org>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/amd/amdgpu: add firmware file fallback for APU VBIOS discovery
Date: Sun, 5 Jul 2026 12:15:56 +0200	[thread overview]
Message-ID: <3e2a862d-53b5-45b8-9c00-08d3e69b0508@shift-computing.de> (raw)
In-Reply-To: <716a31c5-0484-4ef9-b49e-b71310f92d86@amd.com>

Hi Mario,

Sorry for the slow response, I'm new to the kernel contribution process. 
Thanks for the review. v2 addresses your questions: -

The VFCT does contain the iGPU entry, but with a stale PCIBus value from 
BIOS POST time (0x6A). With pci=realloc,assign-busses the iGPU lands on 
bus 0x0B at runtime, so amdgpu_acpi_vfct_bios() never matches it

This is clarified in the commit message along with a note that the UEFI 
GOP driver initializes the iGPU successfully, confirming the hardware is 
functional.

The VBIOS image data in the VFCT is valid — only the PCIBus metadata is 
wrong.

The firmware file was extracted directly from the VFCT with dd, skipping 
past the ACPI header and VFCT_IMAGE_HEADER. The commit message now 
documents the exact command and byte offsets.

The patch follows.

Oz

On 6/26/26 19:42, Mario Limonciello wrote:
>
>
> 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;
>

      parent reply	other threads:[~2026-07-05 10:16 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
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     ` Oz Tiram [this message]

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=3e2a862d-53b5-45b8-9c00-08d3e69b0508@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.